Camera response curve calibration (gamma)

[mkogoj...@gmail.com]

Hello.

For true HDR panoramas, I want to check my cameras' response curves.

I shot an xrite colour checker and graphed the numbers from optimizing in the exposure tab. The results (graphed values) diverged significantly in the darker end of the graph.

I do not trust that result and would like some help in finding a proper solution.

For example - there are Ra to Re parameters in the Emor method in "image parameters" part of Exposure tab; is there a way to know what those parameters are and how they can be graphed, or at least know what they mean? I did find the paper, but failed to find a helpful explanation of said variables.

--------------------more:

The photos were shot raw in 1 stop increments. DCraw was not found on my computer and I could not find a windows executable on the interned (has it been deprecated and replaced with libraw?) I want to convert CR2 files to linear tif with no adjustments, and do not trust Rawtherapee and darktable to make a linear conversion. Admittedly the files that I tested on were converted with AdobeCR so no improvement there, but at least I know what is going on there.

[T. Modes]

mkogoj...@gmail.com schrieb am Freitag, 19. Februar 2021 um 11:30:17 UTC+1:

For example - there are Ra to Re parameters in the Emor method in "image parameters" part of Exposure tab; is there a way to know what those parameters are and how they can be graphed, or at least know what they mean? I did find the paper, but failed to find a helpful explanation of said variables.

The parameters describe the camera response curve in the EMOR model. A graph of the curve is already provided in the edit image parameters in the context menu of the photo tab.

Hugins photometric optimizer is not so good at optimizing the camera curve and the exposure values at the same time. For extracting the true camera response curve there are other algorithms which are better suited.

[T. Modes]

mkogoj...@gmail.com schrieb am Freitag, 19. Februar 2021 um 11:30:17 UTC+1:

 I want to convert CR2 files to linear tif with no adjustments,

Wait, when you input linear images you should set the camera response curve to linear. Then the parameters Ra/../Re have no effect.

[mkogoj...@gmail.com]

Alright, I am happy there is a graph function in Hugin, thank you... but now this last message makes more sense, which I am not jubilant about. Allow me to explain -

I want to check if the photo stacks I am working with are linear or not.

Yes; raw files are supposed to be linear, but Hugin does not work with CR2, only tiff. If I convert the cr2 to tiff it will probably add a gamma curve, but I don't know if and how, and so I wish to check the result. If nothing else my camera's sensor might be doing something funky as well.

But if I can choose the type of image I have, then am I telling Hugin to (or not to) calculate the curve when stitching instead of only calculating the curve and returning the result.

In the attached picture green shift is seen in the cloud. To my knowledge this means that the gamma curve has been calculated badly. I wish to know what kind of a gamma curve images have after I converted them from raw.

pasteall.org/pic/3b53b009a65c4ba19d02dab9b458fb4a

"For extracting the true camera response curve there are other algorithms which are better suited."

Leaving aside that I don't know how to plug algorithms into Hugin, do you have any suggestions? I got HDRShop on academic license (which is supposed to be able to show you the calibrated response curve), but it either tells me 12 photos are not enough or it simply crashes when trying to generate the curve.

[T. Modes]

mkogoj...@gmail.com schrieb am Dienstag, 23. Februar 2021 um 21:53:38 UTC+1:

I want to check if the photo stacks I am working with are linear or not.

Yes; raw files are supposed to be linear, but Hugin does not work with CR2, only tiff. If I convert the cr2 to tiff it will probably add a gamma curve,

 I know at least dcraw, RawTherapee and darktable can output in linear color space without applying a gamma curve. What Adobe does I don't know.

 

In the attached picture green shift is seen in the cloud. To my knowledge this means that the gamma curve has been calculated badly.

Not sure about this. The response curve is applied to all color channels. When there is a color shift it is probably not related to the reponse curve. Maybe there is a problem with the white balance instead.

[David W. Jones]

On 2/25/21 7:49 AM, T. Modes wrote:
>
>
> mkogoj...@gmail.com schrieb am Dienstag, 23. Februar 2021 um 21:53:38 UTC+1:
>
> I want to check if the photo stacks I am working with are linear or not.
> Yes; raw files are supposed to be linear, but Hugin does not work
> with CR2, only tiff. If I convert the cr2 to tiff it will probably
> add a gamma curve,
>
>  I know at least dcraw, RawTherapee and darktable can output in linear
> color space without applying a gamma curve. What Adobe does I don't know.

Hmm, if you opt for linear color, does color space matter?

Also, I learned something when I changed cameras. I changed from a
camera whose sensor shot 15-bit per channel (each color) to one that I
understand shoots different bit depths per channel. What impact would
that have on "linear" color space?

> In the attached picture green shift is seen in the cloud. To my
> knowledge this means that the gamma curve has been calculated badly.
>
> Not sure about this. The response curve is applied to all color
> channels. When there is a color shift it is probably not related to the

> response curve. Maybe there is a problem with the white balance instead.

What happens if the sensor's response curve varies for each color channel?

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

[mkogoj...@gmail.com]

" I know at least /.../ darktable can output in linear color space without applying a gamma curve "

Okay, so part of the solution is to go into Darktable and disable the base curve. This worked, though it's too bad it adds another step to the workflow. Choosing darktable option from hugin import doesn't give any options to specify, like styles that could be used to define linear settings with... does it work well for you? I'd try it but for now it just crashes.

"The response curve is applied to all color channels. /.../ Maybe there is a problem with the white balance instead."

Camera manufacturers add subtle changes to the RGB output channels in-camera. It's mostly done to keep a cohesive look to their cameras, like a modern photorapher may use a certain LUT they like so all of their work looks the same. Normally raw files are immune to this because there is no  in-camera processing going on, but point here is to check for inconsistencies. It could be anything  - sensor age or wear.

"Hmm, if you opt for linear color, does color space matter?"

Technically those are two different things. A colour space can be whichever coordinate system you can describe within the limits of human visual ability (400-700nm), while linearity is having a constant step "distance" within that coordinate system. I imagine.

"What impact would [15bit colour depth] that have on "linear" color space?"

More colours between full black (0,0,0) and full white (1,1,1). If the system is new or very uncommon it could cause demosaicing problems, but that is a different topic.

[David W. Jones]

I do HDR shots and processing. The tone mapping processes themselves
tend to produce halos and shadows around parts of images in my experience.

On 2/26/21 11:27 PM, mkogoj...@gmail.com wrote:
> " I know at least /.../ darktable can output in linear color space
> without applying a gamma curve "
> Okay, so part of the solution is to go into Darktable and disable the
> base curve. This worked, though it's too bad it adds another step to the
> workflow. Choosing darktable option from hugin import doesn't give any
> options to specify, like styles that could be used to define linear
> settings with... does it work well for you? I'd try it but for now it
> just crashes.

Good luck with Darktable. I've never been able to figure out its user
interface. I use RawTherapee to process my RAW files.

I'm pretty sure all programs that process RAW files have a way to set
and save preferences, so I'd think you could set a preference to not
apply a color space?

> "The response curve is applied to all color channels. /.../ Maybe there
> is a problem with the white balance instead."
> Camera manufacturers add subtle changes to the RGB output channels
> in-camera. It's mostly done to keep a cohesive look to their cameras,
> like a modern photorapher may use a certain LUT they like so all of
> their work looks the same. Normally raw files are immune to this because
> there is no  in-camera processing going on, but point here is to check
> for inconsistencies. It could be anything  - sensor age or wear.

Camera manufacturers could also be compensating for issues in the
sensors themselves.

I've also seen sensor tests (I think at DXOMark?) indicating that
sensors' color response (in bit depth) changes over the ISO range.
Generally, the higher the ISO, the lower the bit depth.

I always shoot at 100ISO, so I don't know what impact shooting at higher
ISOs might have.

> "Hmm, if you opt for linear color, does color space matter?"
> Technically those are two different things. A colour space can be
> whichever coordinate system you can describe within the limits of human
> visual ability (400-700nm), while linearity is having a constant step
> "distance" within that coordinate system. I imagine.

I tend to think of linearity as an absolute number recording the
sensor's response to whatever light frequencies it's sensitive to. For
instance, some digital camera sensors are sensitive to the infrared
ranges used by some autonomous/assisted car systems, and their sensors
have been damaged by such cars' laser-generated beams.

Color space, yeah, that's different.

> "What impact would [15bit colour depth] that have on "linear" color space?"
> More colours between full black (0,0,0) and full white (1,1,1). If the
> system is new or very uncommon it could cause demosaicing problems, but
> that is a different topic.

Color depth is just the intensity range as detected by the particular
sensor. Some sensors aren't an even color depth across the three colors.
Some cameras truncate their sensor readings before recording them as a
RAW file. My old camera's sensor recorded 16-bit color but cut off the
high bit in the RAW file. I think some other cameras use 15-bit sensors
but truncate the colors down to 12-bit when recording. I think it's a
function of how much noise removal the camera manufacturer wants in
their camera?

[mkogoj...@gmail.com]

The result:

Darktable gives the option to disable gamma correction, called "base curve."

As stated before - automatic conversion from Hugin was never successful so I opted to convert by hand.

I took a series of shots of a colour checker and exported tifs from DT with the base curve ON, OFF, and added one batch exported with default from Adobe.

These images were then processed with the Average filter to get the average colour of each image and compared side by side. Using an eyedropper I checked the RGB values of each averaged square and copied the values into a spreadsheet, then graphed it out.

This showed a slighter deviation than I expected in the gamma corrected graph, and deviations between RGB values even within the linear graph - again, since all images are averages of the same scene under virtually equal lighting conditions (10 second difference in sunlight) all the values should change equally.

Regardless, at this point I am content saying that the method works, albeit with limited precision, and I will have to produce more images to test the scene precisely.