No, raw values are typically 12-bit or 14-bit, as @ggbutcher nicely explained (how useful the last bit or two is, is another story).
It depends on your idea of “preserve this range”. In typical use, the range is easily not preserved - even if you just apply an input profile and a typical s-shaped tone curve, you’re already significantly boosting values and likely pushing parts of the image past the right end of the histogram.
It’s easy to see with sample images. Here’s a sunset in RawTherapee:
So if the detector only delivers 12 or 14 bits/channel it is even less obvious that you get losses!
Of course, the range need not be preserved by operations like tone curves and others. But as I said, if one does all the image processing in 32bit floating point arithmetic and when done, scale everything back to the range covered by 16 bits, there cannot be any losses. If there are, something was done wrong, to my opinion . Or do we have different definitions of “losses”? For me, unsaturated data are lost, if you drive them into numerical saturation either at the lower or the upper end.
If it would be the case that one cannot avoid losses during reduction of CCD-data (there is no difference to CMOS in this case) , it would not be possible to use CCDs for quantitative work in astronomy.
One “data loss” process occurs because of quantization, reducing the results of a computation to a certain number of bits. This always occurs, whether the result is 8-bit integer or 32-bit float (which has 24 bits of precision, IIRC). More bits in the result reduces the effect.
Quantization means that two values that were different in the input may become the same value in the output. This is a form of data loss, aka “information loss”.
Yes, this might also be called a rounding error. But with 65535 values available and 256 discernible this is only a theoretical issue.
As far as I see this could only happen, if the tone curve rises above 1 somewhere, which I have never seen. It will not happen with a standard s-shaped curve, which brightens dark pixels and reduces bright pixels in intensity, or the other way around – unless I misunderstand the tone curves.
I’m not at the computer where I can dig up an example, but there are certain of the demosaic routines in librtprocess that will push certain channels/pixels well past both 0.0 on the low end or 1.0 on the high end, as high as 6.0 in one case.
Since I separated out my individual raw processing options in rawproc-development (0.9, to be released Real Soon Now…), I’ve seen how camera sensor saturation can bollox up the data to require very aggressive clipping for display. When the pixels pile up at sensor saturation, not only do they lose definition but in application of white balance they separate, and the clipping required to make the blown highlights “not magenta” is to clip to the lowest pile…
So, for now I’ve moved my chase for an effective ETTR strategy to one of ETPHAAC: Expose To Preserve Highlights At Any Cost. Accordingly, my new camera has a special matrix metering mode that, instead of averaging to middle gray, it “shifts left” to keep resolvable highlights. Still trying to tease out specifics of its behavior, but it clearly works on the JPEG-origin histogram. Not ETTR, but it does prevent sensor saturation.
Back to @Jossie’s inquiry, I think there are two places where clipping is to be considered: 1) exposure relative to sensor saturation, and 2) truncation to whatever display white after munging the data in post-processing. For #2, one can surely re-scale their data to fit the bounds just prior to saving or displaying, but for high-dynamic-range scenes, that scaling has to be done with care to keep some semblance of the original scene’s tone and color. My software test image has an in-scene light source; I haven’t found a curve yet that will prevent me having to clip out the brightest parts of the light source. And I think that’s okay; danged light was pretty bright, to my recollection…
To my understanding, all that counts as regards to tone and colour are the relative levels in an image, which is preserved by the scaling, if done correctly. As an example, such a scaling occurs when as a final step you go from a 16bit TIF to a 8bit JPG. You scale from 0…65535 to 0…255.
I think your success in doing so will depend on the dynamic range of the scene vice the dynamic range of your camera. You’ve prompted an experiment in that regard: I have in my possession Nikon D50, D7000, and Z6, with progressively wider DR. I’ll find a high-DR scene and take the same picture with each camera, ETTR. Then, I’ll post-process to 1) make three images all pegged to the max data at display white, and 2) three images all tone-curved to make similar shadow pull-up. Since I procured each successive camera for it’s improvement in this specific regard I think I know where this will go, but I’ve never really done a comparative assessment. Might take a few days, done somewhere interleaved with major yard work…
Listen to @Claes. Also read Elle’s articles (see their updated dates because they may be out-of-date in relation to GIMP).
It isn’t just about rounding. When you make decisions such as scaling (arithmetic) and value remapping, you are changing the way values relate to one another and where they lie. This irreversibly alters the tone, colours and dynamic range, etc., and introduces abstractions and distortions of all sorts. That is why we have such a thing as scene-referred editing and display, which still sacrifices data integrity but strives to do so in a minimal way. Then we have demosaicing and white balancing, and the preceding steps. Of course, this discussion is way beyond the question of file formats.
Of course, this discussion is way beyond the question of file formats.
You are right, lets bring it back to the main topic. As an alternative to TIFF you could use EXR as file format. That is able to save 32 bit float and at least darktable and GIMP support that.
No, it’s a very practical issue when talking about a file format for preserving data, especially when data from that file will be further manipulated. Remember that human vision is more sensitive to changes in low light than in bright light, so more bits need to be assigned to dark values than to light values, but when you want to manipulate the data further, then what is now bright may become dark, so you need precision all along the dynamic range. If you want to capture and store a scene with minimal loss, where there are dark things and extremely bright things, that’s a problem when working on a linear 16-bit scale. That’s why log scales and floating-point formats such as OpenEXR (or flavors of TIFF) exist.
You’re increasing values whenever the tone curve goes above the linear diagonal. Which every practical tone curve does.
This conversation is about using an intermediate format that works for the human, and not the human working for the format.
Here you are talking about the Weber-Fechner-law. The use of gamma-corrected data is one aspect of this (see Poynton 2012, page 316).
Sure, but you were talking about pushing values beyond the white point. This only happens if the tone curve is above 1.
I would say that the claimed “data losses” are part of the topic.
How could this happen? De-mosaicing in its first instance is an interpolation and as such will not push data values far out – except if you include hot / cold pixels in the interpolation process, which should not happen if they are mapped during the dark subtraction.
Yes, you are absolutely correct. But this is what we call image processing. It is not necessarily leading to a loss of information. That is all I wanted to point out. If it is not reversible has to be discussed for each operation. One operation, that definitely is not exactly reversible is the gamma-correction, because at the bright end it gives the same output values for different input values. The question I see remaining is what one understands on “data integrity”? E.g. demosaicing should not through pixel values far outside the input data range.
I find this discussion here very interesting and have learned a few new things .
But I also have the feeling that we are getting lost in the details. The maximum information a camera gives us is contained in the RAW file. This should always be archived so that if necessary, one can go back to the complete information it contains. Already with demosaicing, a considerable part of the original information is lost. Therefore, in my opinion, image processing should at best be done with a RAW editor and a non-destructive workflow as far as possible without changing the file format. Only when it is absolutely necessary to change the format, e.g. to continue working with another image editor, a format change should be done. Also, one should always keep working directly from the original data to the desired result. If one later wants to follow another line, in my opinion, one should start again with the original RAW data. An intermediate storage format as a basis for different edits, doesn’t make a lot of sense in my view.
Why should that be? Which considerable information is lost? Of course you change the numbers (by flatfielding, dark subtraction, vignietting correction, …). After demosaicing you have a factor of 3 more pixels (if you use a Bayer matrix). So in some sense you gain information and most likely you do have changed the original R,G,B values by interpolation! I would not call this a loss of information. The issue is the question, if information available in the Raw-file is destroyed, e.g. by (numerically) saturating a pixel, which was not saturated before. I do not see this must be happening.
There are different algorithms around for demosaicing and new ones might get developed in the future. Depending on the image at hand and of your goals in processing this particular image, some algorithms do better than others. But once applied, one can not reverse the demosaicing. There is even the possiblity to generate a higher resolution black & white image from the unmosaiced data. Starting from a standard image file this is no longer possible.
@Thomas_Do
All true. But by demosaicing no information is lost, on the contrary, information is added. The raw file by itself is useless. But in the processed file you can read off colours and brightness values.
Demosaicing is not the best example. Let me take flatfielding instead to demonstrate, what I understand by loosing information.
These graphs show pixel values along a line in the image. Top left is the raw, bottom left the flatfield.
In the raw image, the left peak is lower than the right peak. In the flatfielded image, the reverse is the case. The latter is the true information. So the raw image does not contain by itself the correct information.
If you do the processing in 8 bit arithmetic, you get the result at lower right, which has clipped pixels to the left. However, If you process the image in e.g 32bit floating and then scale this image to the range 0 … 255 you recover in 8 bit space, the correct relative intensity distribution and no data are lost:
In principle, one can replace “flatfielding” by any other image processing step. This was the only point I wanted to make.
Dunno. I recently incorporated the librtprocess library into rawproc, because it has a rich suite of demosaic routines. In my tests of the new tool that exposes them, I was surprised to find one of the algorithms (I think it was ‘amaze’, still haven’t had the opportunity to confirm) resulted in min and max values significantly below and very significantly above the 0.0-1.0 limits I use for eventual scaling to display black/white. The test image had sensor saturation clipping, so that might have something to do with it. My knowledge of demosaic math extends to implementation of ‘half’, which isn’t real math but simply drag-and-drop of adjacent values. @heckflosse, the smartest demosaic person I know, may have insight…
All this talk of clipping is why I still revert to a manually-scooched spline curve for my scaling if a simple black/white point scaling doesn’t look good enough. I know if I leave the 0,0 and 255,255* points alone, my spline will converge on those two points and not drag values out of my target display range.
*My curve tool uses a 0-255 range that is scaled to 0.0-1.0 for application to the internal image
Actually, it’s more appropriate to consider it like this: measured information is supplemented with asserted information. The essential semantics of ‘demosaic’ don’t imply information loss, but the by-product of a particular algorithm might cause it…
. Or do we have different definitions of “losses”? For me, unsaturated data are lost, if you drive them into numerical saturation either at the lower or the upper end.
.
and most likely you do have changed the original R,G,B values by interpolation! I would not call this a loss of information. The issue is the question, if information available in the Raw-file is destroyed, e.g. by (numerically) saturating a pixel, which was not saturated before. I do not see this must be happening.
