I have been going through some of the articles on your website, and I think the penny has finally dropped! Well maybe…
I will attempt to explain what I couldn’t understand partly because there is a fair bit of erroneous info, which may help others and may help explain what I am trying to do.
What I could not understand was how sRGB, adobeRGB, ProfotoRGB or any RGB colorspace could have a wider gammut or a different gammut if it was using the same numbers.
For example if I used 4bits per colour, I get 4096 colours, putting aside the fact I might not be able to see all 4096 and they may have different gammas corrections applied. Those numbers are fixed, so I couldn’t get my head around 4bit adobeRGB having a different gammut than say 4bit sRGB.
Until the penny dropped that the definition of the colours used to make to create the colour is in fact different.
or put another way the “chromaticity” of the primaries is different, or they are using a different Red, Greens, and Blue to mix with.
So in my case when I said I have a linear RGB file, which is what you get when ask Vuescan or Silverfast for a “Raw” file. Is actually a file were the “chromatic primaries” are the same as used in sRGB but without any of the normal gamma encoding applied. i,e, the intensities stored in the file are those actual measured using the sRGB “chromatic primaries” instead of being gamma encoded as they would normally be.
Or simply I had bog standard sRGB file, with the gamma encoding removed.
It’s now my guess that selecting
Color Management --> no profile
is expect linear encoded values, but with some other value used for the “chromatic primaries”, which is the reason for the funny colours.
Anyway back to what I am trying to do:
So far I have a able to apply the following equation
using imagemagick, using both RGB and LAB colorspaces for a film scans of colour and black and white negatives.
In the equation Jn represents the intensity measured on the film scan Yp represent the gamma of the photographic paper, typically 1.8, Yc represent the gamma used in the colorspace used to store the file, and K represents the exposure or gain applied.
It seems to work…
However K is destructive, in that the optimal value of K will in many cases result in some clipping.
Which is why I want to incorporate RT somewhere in the process, not just at the end. I course I am not sure yet how do that, and perhaps it’s impossible to do it outside of RT. But that’s were I am.
I hope this babble makes sense.