Getting organizized – A database for carbon transfer tissues

When it comes to workplace organization, I’m pretty schizophrenic. My desk is generally a mess, and open any cupboard in my darkroom only to find its contents in disarray. On the other hand, I can get carried away trying to properly organize things – to the point of being ridiculous! This blog is about the latter: a database system for keeping track of carbon tissue variants.

Let’s get the apparent typo in the thread title out of the way, first: it’s not a typo. It’s a reference to the “one of these days, I’m gonna organizized” quote from Taxi Driver. There’s much to love about that movie (and a couple of things to have some serious ethical doubts about as well – these aren’t the 1970s anymore!), not in the least its photography. The impressionistic New York street shots that appear throughout the movie are just pure eye candy. Anyway!

One of the things often emphasized when people ask about some technical aspect of photography, is the importance of keeping notes. Admittedly, I often don’t do this, and when I do, it’s usually on pieces of scrap paper, inconsistently in the margins of test strips or prints, or in some other way that is bound to get lost or impossible to make sense of as briefly as a few days later. But with my recent struggle with highlights in DAS carbon, I just couldn’t get away with that haphazard approach any longer. I needed some kind of a system to keep track of all the tests I was doing.

The main purpose of this system was to be able to remember how exactly any particular carbon tissue was made. In particular, I wanted to record the exact ingredients I used, and in which quantities, along with any relevant information in terms of processing and outcomes. Hopefully, that way, I would be able to spot patterns in the problems I was facing.

So I tried a simple Excel spreadsheet. Which worked well enough, since it’s straightforward to use. Here’s a little sample of what that looks like – it’s just to get a feeling for the kind and amount of data and how it was (not…) organized:

Note a couple of things in the above screenshot, which depicts one particular tissue formulation:

  • Each tissue formulation has a unique identifier. In the example above, it’s “XLPD4”. This code is unique to the tissue recipe (not to an individual tissue or batch of glop), and it’s quasi-descriptive. XLPD4 is the fourth variant of a tissue using Kremer XSL black (hence the X and the 4), it has a low pigment load (LP) and it’s DAS-sensitized (D).
  • We’re already at line 625-ish, and with each formula taking something like 10 lines, this means there are dozens of recipes on that single sheet. And that’s just the black & white sheet – I’ve got a separate sheet for color glops/tissues.
  • I express the ingredient ratios as percentages. The gelatin is expressed as the weight/volume percentage in the liquid glop, so a 10% gelatin would be 10g gelatin per 100ml glop volume. The other ingredients are expressed as a weight/weight percentage relative to the dry gelatin content. So a 4% DAS content would be 4% the weight of the gelatin in the glop. For instance, a 10% gelatin and 4% DAS glop would be 10g gelatin per 100ml and 0.4g DAS per 100ml (4% of 10g gelatin is 0.4g after all).
  • There’s a volume setting (in the snapshot above, it’s “500” for a glop volume of 500ml) which is used to automatically calculate the dry weight of all the ingredients for that particular batch of glop. Hey, it’s Excel, so let it handle the pocket calculator tasks as well!

If you think about this for a while, especially from an information management perspective (some aspects of my university education are just really hard to shake off), you notice that there are some opportunities for improvement. There’s quite a bit of copy-pasting involved in adding a new glop recipe. A spreadsheet is perhaps not the ideal way to navigate dozens of recipes. In terms of data management, there’s a massive amount of redundancy, which makes maintenance and integrity of the database inherently tricky. At some point, I just couldn’t ignore the fact that this would work a lot better as a proper relational database. So that’s what I made.

In the 1990s, I would have used something like FileMaker or later Microsoft Access – or a plethora of other systems, because desktop database systems were never exactly in short supply. These days, I prefer open source if possible, so I tried the obvious option of LibreOffice Base, which is basically an Access clone. As some other clones of Microsoft and Adobe software, it’s surprisingly functional, but not quite as convenient to use as the real thing. I lost a lot of time on silly layout issues when trying to create input forms. After an hour of messing about, I decided to do it the old-fashioned way. Also time-consuming, but ultimately more flexible.

Enter the powerful, tried and tested combination of MySQL (or rather, MariaDB) and PHP. Although this is a bit of a nuts-and-bolts approach, with limited user-friendliness (I use phpMyAdmin and Notepad++, so not much WYSYWIG going on here), it’s at least an approach I’m familiar with from projects I did previously and that gives robust results that are not very independent on the client platform used. I.e., depending on where I host the database system, I can access it from any device with a web browser. For now, it resides on my local network and it’s not accessible through the Internet, due to a lack of necessity for web access.

In terms of the data model, my experiments with the ‘database’ in Excel gave me some ideas on this. There are many ways to section the data into distinct entities, and to an extent this is also a matter of taste. I opted for a fairly atomic approach that results in a relatively large number of tables, but consequently also a lot of flexibility. Turns out that Base comes in handy, still, because it can be used to construct a reasonable relational model from the live MariaDB database!

I’ll highlight a few choices I made in the data model.

Central is the ‘glops’ table. I assumed that a glop would essentially consist of one kind of gelatin, and it might have sugar and/or glycerin as adjuvants. Each glop I might mix any number of times, and that’s what the ‘mixdates’ table records: the date and amount of a glop mix.

Furthermore, a glop might be associated with one or more colorants, dispersants (for dry pigments) and sensitizers. For the sensitizers, I only discern DAS so far, but I keep an eye on possible further experiments with ferric salts this way.

Note that I speak of colorants, which I do because I distinguish between colors (the visual aspect), pigments (the compound that creates the color) and the colorant (the package that contains the pigment). Sometimes, this package (the colorant) is nothing more than the pigment itself, which is the case when I use dry pigments. In these instances, I use a dispersant to bind the pigment with water so that it mixes evenly in the glop. In other instances, the colorant package already has dispersants worked into it, which is the case when using paints (watercolor, gouache, acrylic), color pastes (such as those of Kremer or The Wet Print), Indian inks or Kremer’s XSL ‘just-add-water’ pigments.

There’s also a ‘brands’ table that links to several other ingredients to record the brand/maker of each ingredient.

I’ve made a very basic PHP frontend to manage the most common tasks: mainly adding and modifying glop recipes. Other tasks I currently still do with phpMyAdmin, but I might automate them a little further in the future – I’m sure there will be some rainy days later this year that lend themselves to this kind of mind-numbing (but also somewhat Zen-like) work.

Presently, the new glop view that is analogous to the Excel screenshot I showed earlier looks like this:

This is for the same “XLPD4” glop/tissue, and it also shows the different dates I mixed this particular recipe and the amounts I made.

For keeping track of the actual tissues, I use a simple system of small stickers (masking tape, in fact) that I write the glop code on:

This way, I can easily keep track of different tissues, and this makes sense when you have many tissues on hand, of different formulations. Especially if tissues linger for longer times, unused, which is something that DAS carbon allows. Unused, sensitized tissue remains stable for quite a long time, after all.

The database system is also convenient because it’s inherently well-suited to navigating through a lot of data. I’ve not even started to properly unlock this potential, but to given an example, I implemented a simple feature that lists all pigments I’ve been using so far:

I can click each pigment and then find which colorants it’s used in, and also which glop/tissue recipes it has ended up in. This is for instance the list for Pbk7 (a.k.a. ‘lamp black’):

(list continues with a couple dozen more tissues)

Admittedly, this thing fits in the whole “just because I can” category of silly things to do. Or, a bit more generously, it’s a bit of an overengineered solution to a marginal problem. But I’m still quite happy with it, and the project has planted the seed of another idea I want to pursue one of these days. That one may be relevant to other people out there as well, but I want to think it through a little, and I’ll need to block some time to get it started. To be continued, one day!

Leave a Reply

Your email address will not be published. Required fields are marked *