Why is image monochrome in lighttable but colour in darkroom ?

Software darktable
#1

A couple of weeks ago I messed about with my Fuji X-T30 camera so that it appeared to create images in mono (I now have no precise memory of what I did). Now, under Windows one image on the film roll shows in monochrome in lighttable but in colour when viewed in darkroom. The rest of the filmroll appears in colour in lighttable. Under Linux it shows in colour in either both lighttable and darkroom (and, yes, the image and xmp files are identical at the binary level for the 2 OSes).

What causes this behaviour (aside from operator error, that is)?

Strangely, under Windows, when viewed using the Photos app. this one image initially appears in mono (I presume from the embedded thumbnail) and after a second or so it displays at a different size and rotation, in full colour (presumably using the raw data). The whole film roll appears in mono when viewed with Faststone under windows or with XnView under Linux.

#2

That depends on your settings. Default is that for a new, unedited image, dt shows the embedded jpeg preview (faster than a default development). So if you set your camera to monochrome, that embedded preview will be b&w. But, the raw data are still in colour, as you seem to know already, reading your post.
So, when you start processing (i.e. enter darkroom mode), you get a colour image.

If you get a colour preview under Linux, you may want to check your settings there: “Settings” → Lighttable and then the first entry under “thumbnails”…

1 Like
#3

Ah, yes. Thanks for this clear explanation - I understand it now (*). And yes, my settings were ‘mutually exclusive’ between Windows and Linux - one set to ‘never’, the other to ‘always’.

I have now recalled enough to realise that I had set the film simulation on the camera to ‘Acros’ and have demonstrated your explanation by trying it again.

What did catch my attention though is that this camera setting is not documented in the image information panel in dt, nor on any external programme I tried: (Exiv2, Exiftool, PhotoME and so on). The closest I could get to ‘seeing’ this setting, based on the image data, is the ‘saturation’ setting under "Maker’ in the EXifTool GUI. This setting carried the value ‘Acros’. Not being able to readily see, from the image data, that there was a non-standard film simulation setting on the camera made if quite difficult (jn the absence of your explanation) to figure out what was going on.

(*) premature claim; further comment to be posted after more testing.

#4

Exiftool can create a formatted output (table) :

exiftool -H -G -a -w! .exif basename.ext

creates a text file basename.exif for your image file basename.ext including all tags (including Maker tags).

#5

My 2nd round of ‘not-understanding’ arose from the observation that only 1 image on the entire film roll was displayed in mono in lighttable under my preferences settings. Having read the manual again, I now understand why: "Once an image has been processed in the darkroom, thumbnails will always be generated from raw data "

And indeed as soon as I performed the simplest edit on this one image its thumbnail was displayed in colour in lighttable. So, this time, I think my understanding is better.

#6

Indeed it does, so thanks for this information. However, from the impressive amount of data that is generated I still cannot explicitly see an entry which has
words to the effect of “film simulation setting: Acros”. I can’t say I really understand the entry for 'saturation under ‘Maker Notes’.

20220403_Back-Lit-Beech_2429.txt (12.4 KB)

#7

There’s another wrinkle: the file generated by exiftool will generate a file with all known tags.

But the makernote section is not documented at all by the camera makers (*), so there’s no guarantee that all parts of it are well understood: understanding that section is a lot of “trial and error”. If the part containing the film simulation settings is not understood, it won’t be reported in any legible way (you might get a numeric dump). And a lot of stuff is there as a numeric code (and not clear text), which doesn’t help

That poor documentation of part of a raw file’s metadata is also the reason that writing to a raw file is not recommended…

(*) That’s why the raw developer from the camera maker can do a few tricks programs like dt can’t do: the maker’s program has access to all the metadata, and to the algorithms the camera uses.