@elle DCI-P3 is relative wide gamut compared to sRGB IIRC so working on wide gamut monitors is possible, I don’t think there are a lot of OCIO configs out there with AdobeRGB display/view but it should be possible to make those. Also with the help of different views[2] it should be possible to proof and with a false color view it should be possible to show out of gamut colors. Now of course setting this all up is quite a bit harder then setting up an ICC workflow (which again show that OCIO was developed for studio work, you have a small group set this all up and the rest just use it)
[1] And then for people who know what they are doing they can set the OCIO environment variable to override this default (and in that case of course disable the ICC output transform if people know how to do this they should know how to get a profile in a OCIO config)
[2] Pretty sure this is how they check if a print to film (since there are still theaters with only a film projector not a digital one) will look good.
@dutch_wolf - your reply to my concerns is helpful.
@anon11264400 - I don’t know whether you intend to hurt my feelings with your rather nasty way of responding to just about everything I say. But your way of speaking is personally hurtful and doesn’t contribute anything positive to the discussion. You seem like an educated and articulate person. Try to find a neutral way to address what people say.
Nowhere in this entire thread has there been a hint of what you suggested regarding limitations of a potential gamut to sRGB. Your statement was essentially non-sequitur.
Okay, doing a little reading while dialed into a soul-sucking teleconference, if displayCal can generate a LUT for the calibration that transforms from a specified colorspace (NOT CIE XYZ) to the calibration colorspace, that file could be used in the colorspace definition for the display in the ocio.config file.
I would like to see if I understand correctly the first step, i.e. how to generate a scene-referred image with photofow, using a single RAW file.
The steps that I would suggest for this are the following:
open the RAW file
adjust the exposure as needed, to set the “0.18” gray point in the good place
select the “standard” matrix camera profile, select a linear output colorspace, and do not clip the output values:
The “standard” matrix profile is “neutral”, in the sense that it provides correct and natural colors without any specific “look”
export the resulting image to 32-bit floating point TIFF, again selecting a linear output profile:
Optionally, if the lens is supported it is also possible to correct for the lens vignetting directly on the linear pixel values in the cameral colorspace:
@gez@anon11264400 - is this reasoning correct, or am I missing something?
I think that the colorspace gamut has to match the reference colorspace gamut in the OCIO.config file, or match a “to-reference” transform.
The TIFF used for input in @gez’s Blender demo produced using dcraw has sRGB primaries assigned, and the corresponding data, per the man page. That would work with Rec709-referenced OCIO configs, as the color primaries in both specifications are the same.
That’s correct, although as we already discussed is not mandatory for every case.
We propose sticking to rec.709 primaries at least for these first tests for the sake of simplicity, as it will allow trying existing OCIO configs (like Filmic Blender) without further modifications.
Otherwise, a different configuration should be created (either changing the reference to rec.2020 or producing a transform for linear rec.2020 to the existing rec.709 reference) which adds an extra layer of complexity that is better to leave aside for the moment, until everything else is properly understood.
It looks ok, yes. Just keep in mind that if the ubounded gamut thing is involved, you’d want to mark that checkbox for clipping negatives.
Does the raw developer use libraw?
On the other hand, the black compensation on save seems something you don’t want activated.
Regarding the lens correction, theoretically I think it’s fine, but you’ll have to make sure that the operation is designed for scene-referred RGB and won’t mess with your light ratios.
I have processed the IT8 target image as outlined above, saving the result in linear Rec.709. The result matches very closely what you obtained with
dcraw -T -4 -w -q 3 -n 100
there is just a slight difference which is probably due to a small difference in the saturation points that are assumed when normalizing the RAW values.
My TIFF (together with your original TIFF from dcraw) can be downloaded from here: Filebin | ibhc7xtz1dz4dssw
No, it is based on RawSpeed (same as for Darktable).
The vignetting correction is applied to linear pixel values in the camera colorspace, before any ICC conversion, which I’m pretty sure is the correct procedure (and the one expected by the LensFun code).
