What do we lose processing TIFF?

Processing
1

What do we actually lose if instead of processing from a RAW file we have a >= 16 bit losslessly compressed TIFF (or JXL for that matter)?

Looking at the darktable pixelpipe, before the demosaic we have (and im assuming that dt is doing almost everything (if not everything) that can be done before demosaic before demosaic):

  • raw black/white point
  • white balance
  • highlight reconstruction
  • raw chromatic aberrations
  • hot pixels
  • raw denoise

of those the only one that (at least for me) is used as part of the processing of an image is white balance. The rest of them are either something specific to the sensor that i dont need to touch or if they need to be touched they could perfectly be applied for the generation of that tiff (or needs to be applied)

The other thing that we lose is obviously the choice of demosaic algorithm

But if its lossless and high bit depth, then, am i wrong in thinking we dont lose any editing flexibility after demosaic? Also making sure that on the export to tiff we are not clipping any data that wasnt already clipped, which i guess could happen if we are applying a basic white balance.

What about color profiles? does applying a color profile change the data in the file or only it points to a way to interpret the data thats there? I do know that when exporting out of gamut colors are moved into gamut, but as i understand it this is an extra step separate from the color profile and could, potentially be skipped (although i dont see a skip option for it in dt)
Regardless it would probably be best to export to a color profile larger than the camera one. linear rec2020 maybe.

A couple of use cases:
Lets say we have a monochromatic sensor and trichrome a scene with filters. since there no white balance to take care in those RAWs and no demosaic, by aplying the rest of strictly needed processing, exporting those and then combining them into different channels of a single image and doing the actual editing in that result; we didnt lose Absolutely Nothing (?)
Rather than doing as much processing as we can on the separate raws.

And stitched photos. In this case if they are color images we do lose like i said the choice of demosaic algo, and maybe something regarding white balance; but other than that, did we lose anything?

The more info that can be supplied the better, links for further reading, etc. And please dont be afraid to get technical, in fact i prefer it, but still i may ask for clarifications if something goes over my head

Thanks in advance for the answers :smiley:

2 Likes
2

Nice question! And, nicely dissected.

Regarding color profile, the thing you need to do is make sure whatever you export to TIFF is accompanied by the color profile that represents the image data. If you do nothing to convert the camera data to some other colorspace, the camera profile should accompany it. Using any other profile than that one implies you converted the camera data to that profile. And, that would be ā€˜lossā€™.

IMHO, the minimum essential operations on raw data to make a TIFF for further processing are:

  • black/white point: Stretches the data for two reasons: 1) on the black side gets rid of the sensor bias that keeps it from recording black as zero, and 2) on the white side, gets white out of that 12- or 14-bit limit of sensor recording to the 16-bit top of integer data.
  • white balance: Shifts the camera-recorded color for two reasons: 1) the color temperature(s) of the scene lights, and 2) bias built into the sensorā€™s bayer array.
  • demosaic: thereā€™s no convention for non-RGB pixels that most downstream software would understand.
  • color profile assignment: If youā€™re shipping camera data in its original spectral response, you need to include the corresponding camera color profile.

Everything else, to my bear-of-little-brain thinking, is lagniappe. Now, things like hot pixels and raw-based denoise are just the domain of raw processing programs, so might as well do them there. And, no tone curve shenanigans, just scene-linear data like the camera captured it.

FWIWā€¦

1 Like
3

Oh, just saw this sentenceā€¦ If you plot your cameraā€™s profile in terms of chromaticity, youā€™ll find the triangle is a lot larger than any of the defined colorspaces. Thing is, you canā€™t think of that camera triangle as a ā€˜colorspaceā€™ like the others, itā€™s actually an arbitrary bound that puts the cameraā€™s bayer red, green, and blue bandpasses in the proper positions to down-convert the data to a destination gamut. The licensed color scientists call the camera matrices ā€œcompromise matricesā€ for that reason.

4 Likes
4

so what im hearing is that choosing a color space does indeed change the recorded data in the outputfile

ill have to look into availability of camera profiles, but the most obvious answer without investigating is that they are readily available if dt ships them.

but the question does arise: how does this affect a monochromatic sensor? would it need no color space at all?

5

ā€œchoosingā€ a color space has two interpretations: 1) assigning a color space to an image, or 2) actually transforming an image from one colorspace to another.

You really only want to do #1 with a camera profile to a raw image. From there, you want to do #2 to convert the image from one space to another. There are some folk who show how to assign a non-corresponding color space to an image to get a different look, but to me thatā€™s just a stupid pet-trick that confuses things more than anything.

Most raw processors store camera color information internally; most of those use the dcraw adobe_coeff table from the source code as a basis. That makes it harder to manually assign the colorspace definition to an image. Thinking on it, may just be easier to export from the raw processor in Rec2020 or ProPhoto, converted at the export. I have my own software that would do the assignment, but I donā€™t recommend it :laughing:

6

For monochromatic sensors all you really need to know is black and white point.

Besides possibly clipping there, a linear 16-bit TIFF is basically lossless.

1 Like
7

would you share it? interested in looking at the inner workings

8

just to reiterate then: since applying a color space seems soft obligatory, it doesnt matter which we choose, could be SRGB and we wouldnt lose anything (?)

this would make sense since all the mono information is in the single pixel value for its intensity
but on the other hand i understand icc also say whats white and such
so im still unsure about the answer

9

What does ā€œapplyingā€ a color space mean? It might mean:

  • assigning a color space, which means declaring the color space of an image. So this sets metadata without changing pixel values.

  • converting from one color space to another. This changes metadata and also changes pixel values.

A color space specifies the primaries of the color channels, and the transfer curve. If your image is linear, then the transfer ā€œcurveā€ is an identity, a straight line, so assigning a sRGB color space would not be correct.

2 Likes
10

https://github.com/butcherg/rawproc

1 Like
11

this is extremely confusing
i dont understand how both can be true, coz if the second is true then the first one is going to always make the img wrong unless it was already wrong in the first place and it had either no color space assigned or the wrong one

about this i think i understand; meaning that there are color spaces for editing and others for displaying
(and the log color spaces are for recording the scene(?))

12

I wrote this about 6 years ago, might be of help:

1 Like
13

Iā€™m not sure 100% from your comments which part you are confused about but an analogy one could use to think about it might be thinking of the end result similar to using unit expression/conversionsā€¦

If you think in terms of inches and cm for example

1 inch = 2.54 cm
1 cm = .39 inches
If the units assigned were colorspaces the representation or expression of a value ā€œ1ā€ is a different quantity for different units and thus for color it would result in a different color.

If instead you do a conversion to

1in = 2.54 cm the value now changes (is converted) from 1 to 2.54, but you have the same physical amount. If units was equal to colorspaces here there would be no change in color as you have done and ā€œequivalentā€ conversion between unitsā€¦

Maybe this is not helpful at all so ignore this if the terminology and application is clear and you are asking something different

14

this is extremely confusing
i dont understand how both can be true, coz ā€¦

How both of what can be true? If you mean my comment then:

Assigning a colorspace is appropriate when the image doesnā€™t has an assigned colorspace, for example because the image file does not contain an embedded ICC color profile. When there is no profile, image viewers and editors will assume the image is encoded as sRGB. So the purpose of assigning a colorspace is to ensure that viewers and editors will display and edit the image correctly. If we assign an incorrect profile, then viewers and editors will get things wrong. If the assigned colorspace is wrong, we can assign the correct one.

Converting is for when an image is encoded as one colorspace, but we want a different colorspace. For example, perhaps the image is encoded as Rec2020 and we want an sRGB version to show on the web.

Elle Stone has created many ICC profiles, and some of those are for linear encodings. See her descriptions at Elle Stone's well-behaved ICC profiles and code and the profiles can be downloaded from elles_icc_profiles/profiles at master Ā· ellelstone/elles_icc_profiles Ā· GitHub . The profiles named *-g10.icc are for linear encodings, gamma=1.0.

That page of Elleā€™s is well worth reading, and re-reading. And so are her other pages. Iā€™m a big fan.

2 Likes
15

ah this is lovely, thanks so much!

thats precisely it, what i found confusing is the assigning and converting both being possible; and i see i wasnt far from understanding tho, just assigning will either break or fix the image; but how much of a common use case is it? the image should have the profile or its broken. Nice to be able to just assign it for when its needed tho.
Well, anyway, i think i understand now

Another question comes up tho. So if the color profile is in the metadata, all the data for a proper viewing of the image is in the image itself? you wouldnt need to have the icc file separate?

doesnt surprise me that this thread turns into a color profile thread since theres so much i dont understand about them
thans for redirecting me t elles page too, had a look at it a month or so ago, understood basically nothing, now i understand a bit more. who knows maybe in a couple more months ill understand most

16

Ah, the confusion is in how the raw data arrives in the raw processor - in most cases, sans camera color matrix. The only format I know that allows it is DNG, putting the burden on the camera to include it in the raw metadata. I think there are a couple of other cameras, someone with that knowledge is welcome to pipe up.

So, ā€˜assignā€™ is generally needed to associate the raw data with its corresponding color matrix. After that, itā€™s all ā€˜convertā€™, using the matrix associated with the data as the input to the transform. After the transform, that matrix is replaced with the transformā€™s output matrix.

In most raw processors, there are at least two transforms going on: 1) camera ā†’ working profile, for processing, then, working profile ā†’ export and working profile ā†’ display, when each is needed.

This is the synopsis of the article I linked earlier.

17

Ahhhh, i see. this answers this

Thanks!

1 Like