For the life of me, I cannot clarify my mind about how gamma correction/expansion is managed in libraw/dcraw and in general in a color management chain. Or maybe, I have an idea that has to be confirmed/rejected.

I assume human eyes introduce a gamma compression of about 0.45 and that this is canceled out by the viewer who observe an lcd screen with the same law.

When a raw file is opened everything is linear. DcRaw by default seems to gamma compress by 0.45 only if the output file is going to be saved in 8 bit format. If the 16 bit option is given than the file is no gamma corrected.

I don't understand where inverse gamma is applied, to return in a linear realm ( the gamma monitor should be canceled out by the profiling software).

What puzzles me is that taking the raw values (in linear realm, no call of gamma_curve()) and putting them on the screen using the wxwidgets graphic library, the result is too dark indicating that somewhere the library compensates with a 2.2 gamma ... but there 's no evidence of that in the documentation!

My take is that every graphic viewer/library always inserts a 2.2 gamma expansion when dealing with 8 bit files. if the file is 16 bit encoded then the viewer should not include gamma correction.... but the embedded profile seems to include a 2.2 gamma coefficent.... how is this dealt?

Then there is another "unclear" point: in convert_to_rgb() I see another call to gamma_curve(). I don't understand what it does and, speaking of this method, it is unclear how it works : Mode=2 seems to be the normal mode which gamma expands/contracts the curve[] table. But what about mode 0 and mode 1?

Thank you very much for your help!!

Roberto