EXR updated with D60 on the left and 32-bit float: Spectral_Cornell_Boxes_Standard_Human_Observer_D60.exr - Google Drive
Alternative variant using ISO 7589 Photographic Daylight: Spectral_Cornell_Boxes_Standard_Human_Observer.exr - Google Drive
Cheers,
Thomas
GDrive link doesn’t seem to be downloadable FYI
Sorry about that, seems like it changed as I updated the file…
EDIT: So it turns out that as I wrote from Nuke directly, it does not write in-place but on the side and then replace the image…
For smoothness reasons we would prefer to not have ‘if’ style adjustments as this can lead to problems with gradients and other transitions from one colour to the next. Ideally we will want to reformulate the compression to not need this.
for what it may be worth: Download just worked for me - 134,539 KB
I don’t know if this is already known. The out of gamut compression seems to add a tint to the image. Also the perceived brightness is impacted. I created a comparison image for all six limiting primaries and increased the vibrance in Photoshop to make the differences better visible:
I’m using Nuke Non-commercial which has some limitations. Maybe that’s relevant.
EDIT: I looked into the blink code and now I see that I need to choose limiting primaries with the same white point as the output color space. Then the output seems fine.
I’ve made another interesting observation:
I created two variants of DTCLs with the Nuke script for a manual DaVinci YRGB workflow:
Variant 1: Input primaries AP0 / Output primaries Rec.2020-D65
Variant 2: Input primaries Rec.2020-D65 / Output primaries Rec.2020-D65
Both DCTLs are expecting Linear as input and the output encoding is ST2084 (HDR).
In Davini Resolve I’m using the Color Space Transform for the conversion from Canon Log 3 / Rec.2020 to Linear / AP0 and Linear / Rec.2020. Tone Mapping is disabled.
Now I get two different results. Variant 1 (AP0 input primaries) has a tiny bit more magenta in the sky, which I don’t like.
Can I assume that input color space = output color space (and input white point = output white point) in the Nuke script is the most accurate?
Animated gif:
It’s for sure not related to what you demonstrate, but still:
If I recall it right (at least including version 17, last time I checked it), Canon logs in Color Space Transform aren’t correct. Worth comparing to ACES IDTs.
I’ve probably found the origin of these “kinks”.
This is diagnostic output of tonemappedJMh with M channel scaled down a little bit:
Eccentricity factor = Custom:
Eccentricity factor = None:
The eccentricity factor seems to result in some sort of misalignment in the chromaCompression() function. In this extreme example, it looks much better without it.
Re-rendered with more samples so there will be a lot less noise and I also did a variant with a Grasshopper 2 sensitivities, always interesting how those extremely saturated colours are not mapped properly with a 3x3 matrix.
Cheers,
Thomas
I haven’t been able to reproduce the same issue. Can you describe the steps you took, or even include the Nuke script you used.
Very interesting.
Do you have the sensitivities for a virtual Alexa?
I did this:
else if ( diagnosticMode == 12)
{
tonemappedJMh.y *= 0.8;
dstRGB = JMh_to_output_RGB(tonemappedJMh);
diagnostic = dstRGB;
}
The settings in the DRT_CAM6 node are:
I have some at work that I cannot share and there are some public ones but they are wrong, I could do a render with those, will dig them out.
I have been checking some testing with the hellwig model from this repo, I am not sure if this is the lastest version, so the results may vary.
At first glance it looks like the model itself is not invertible back to rgb, not even rec709, and even worse for larger gamuts . I think this model expects XYZ d65 right?
HellwigTest.nk (70.5 KB)
I might be wrong but this behavior doesn’t seem an implementation error , rather the model itself .
If there is any wrong assumptions from my side let me know.
I’d have to take a closer look at exactly what’s going on here.
But the version implemented in v035 roundtrips:
RGB → JMh → RGB
There was a PDF paper available publicly at one point which had the following graph in it…
Which with some digitising gave me these …
Don’t know if they are right or wrong, are missing any other filters that might include lenses, etc but
AlexaSpectral.xlsx (448.6 KB)
There are probably lots of faults in this data.
That would be this one, Harald is on it, so I’m assuming this is “legit”!
Leonhardt and Brendel - 2015 - Critical spectra in the color reproduction process.pdf (1.4 MB)
If you made a rendering though those spectral sensitivities, and then applied the appropriate matrix from this file it might not exactly match a current ALEXA, but should give a pretty reasonable approximation of the result of shooting a physical Cornell box lit with those LEDs with an original ALEXA Studio. That might be a more suitable cinema camera test image than the Grasshopper one.
Hi Thomas,
similar to the blender/cycles RGB balls example that I posted a while back, I took the two EXR files and passed them though the same „pipeline“ to see them in SDR & HDR:
For AgX I took a slight different route:
Here are the files on a google drive link (H.265 10-Bit): ACESCentral_SCB_comparisons - Google Drive
And YouTube uploads can be found here (direct uploads of ProRes 422HQ in UHD): ACES Central - ACES 2.0 CAM DRT Development - YouTube
