"raw black/white point" settings

I use Fuji cameras currently and have no problem using the default settings with the above process but I notice that whenever I try to process other makes of cameras, with the differing pixel layout, it becomes a fight to find the correct settings for both black and white.
For instance the last Play-Raw was really a problem on my system!! Why should that be?
The manual is short on information so I wonder if somebody can enlighten me further.

What do you mean “the above process”?

1 Like

In general, darktable should provide the correct values, you don’t have to change anything. These are technical settings (camera characteristics), not artistic/creative ones. If you find a camera whose raw black/white point is wrong, report a bug.

1 Like

What is the practical meaning of “white point” and “black point” with respect to raw data?

Assuming that the actual raw data has values between normalized 0 and 1 and assuming that those values can’t be messed with on the sensor chip - does that imply some sort of mapping e.g. to output levels thereby squeezing up the histogram?

e.g.

Pardon my ignorance of the software in question …

These are hard coded values in the metadata of the raw file that specify white and black…

This is from a random CR3 file and likely they are based on the SNR of the sensor…sometimes you can even have a value added in that is the upper limit of linearity of the sensor…

image

Thanks, I do recall Canon’s black level added during conversion of the raw data. Didn’t know about the white levels though.

I recalled this blog post…its a pretty good one…

Maybe share what you are trying to describe…the question as asked can only be the result of bad data for the camera its not likely but it can be that the values are off…you can check the exif data and see what DT is using and see if there is a mismatch…

think that I have nailed down what is happening on my system.
RB/WP is not reading/updating the camera data and is using information from prior images.
If I use the ‘O’ icon to reset to a default position, dt then correctly reads-in the image data.
As long as I continue reading-in data of a consistent type there is no problem but when I read from images with differing B/W values the problem shows its head.
I notice this when I try to open some, not all, images from this site and also some of my older pieces.
I am not sure if my use of Fuji cameras is playing a part in this.

Sure you don’t have any auto-applied module presets? Or using styles that include that module?

You are right Steven … don’t know how it got in there but there was a preset that was causing all the problem.
Thank you

1 Like

Glad you got it sorted. :slight_smile: It is sometimes the simplest (sort of!) things that can cause grief.

1 Like

I bet you had some images with the wrong values and so you created the preset to correct for that and then maybe made it auto without knowing or forgot about it…

Glad you got is sorted…

Have I misunderstood?
I thought the white point is found as an Exif value in the raw file as you indicate, yes, but that the black point is computed from the Optical Black field at the frame of the image (outside of effective frame actually used for images) possibly corrected by means of an exif value for the noise floor.

All I meant is to say the values come from the exif data and are not something that you monkey with…they are set by noise level and iso in some cases I think but…the key point was as I understand it to be they are values established by the camera manufacturer for that model of camera and in general if they are correctly matched in the software are not a parameter that you tweak or fiddle with image to image…

2 Likes

Not necessarily. There’s cameras.xml in the rawspeed library that darktable uses to decode most raw images. That also contains black and white points, for example the entry for the Canon EOS 300D has these values:

But should these not match the data in the raw file. This may be the way DT accesses that data ie not directly from the file but that’s a nuance of the software design is it not…

It may be a nuance, yes. If darktable always read the values from the Exif, a bug report (against those values in the XML) would not lead to a fix, though. I do not know under what circumstances one or another set of values is used. I assume there is a reason both for including it in the Exif data (the camera manufacturer should know the values), and also for rawspeed having its own (often per-ISO) data.

1 Like

I would suspect that maybe for older files its is not present in the meta data or they are not consistently read or maybe even at one time at all so it could be a combination of a historical need for such a file or a means to guarantee camera support for the files that you say you support and not relying on fetching the information from the files… but really I have no idea…

Well, I know from experience that the raw white point is not taken from the exif information (for at least some cameras): we had a discussion here a while back from which it appeared that for some cameras (Sony, like I use, and iirc some Canons) dt used a wrong raw white point. The exif had the correct value, so the workaround was easy (preset!). I think the same goes for the raw black point: both are taken from the cameras.xml provided with rawspeed.

So that’s a design nuance when the values in cameras.xml are correct, it’s a bug when they are not :stuck_out_tongue:

One issue that appeared with the exif data was that some makers put the correct values in the makernote section (which is not documented in any official way, contrary to the “normal” exif data).

5 Likes