Closed radioproektor closed 1 year ago
I would suggest holding fire on that for a bit. The primaries and matrices given in the white paper don't quite match. It has been reported to the Resolve team.
Seems it was already fixed in datasheet: Initial Release 1.0.1 11/09/2020 Fixed incorrect matrix values
Nope, the matrices does not agree with the primaries.
Hi All,
thanks for all the heads up - i can add it in easily enough, but as mentioned, the primaries / white point and matrices don't seem to hook up over the green primary.
As they stand, I make the DaVinci-XYZ matrix:
0.70719678, 0.14259748, 0.100661666 0.27669074, 0.87047916,-0.147169904 -0.09989155,-0.13175725, 1.320706545
using the primaries and white point (D65) as published, and reversing things I make the primaries and white point:
Red 0.800,0.313 Green 0.1682,0.9877 Blue 0.079,-0.1155 White 0.3127,0.3290 (D65)
using the published matrix. In the white paper, the primaries are:
Red 0.800,0.313 Green 0.1618,0.9877 Blue 0.079,-0.1155 White 0.3127,0.3290 (D65)
the only difference being the X value of green. I'd say that looks to me like finger trouble, someone typing 0.1681 when they meant to put in 0.1618 for the matrix calculations.
In theory it could be that the matrix is right and they mistyped the primaries, but having had to track down that kind of typo, er, more than once ;-), and considering that the difference appears in exactly one coordinate of one primary, I'd say the primaries have been published as intended.
Having said that, if DaVinci has a duff matrix hard coded into it, they may well decide to fix the primaries to the matrix. I'd hope not, but Nick I think that you are right that I should give Blackmagic a chance to chose the preferred option before pushing an update to LUTCalc. To put it in perspective though, it looks to be a pretty small shift of greens in the X-axis.
I'm sure that someone will have picked up the typo (thank goodness they published the matrix to XYZ rather than ACES so no CAT to figure out) but in case it might be helpful, if any of you knows who to mention this suggestion to at Blackmagic, by all means do,
Ben
I have emailed Rohit and Peter on the Resolve team about this, but so far not had a response. I imagine the beta cycle is keeping them quite busy!
Inside Resolve 17, the CIE scope shows the Wide Gamut primaries with the green X value at .1682, which aligns with the quoted matrices.
The problem is the primaries as given in the White Paper:
Hi All,
thanks for that. It backs up what I suggested, but the point is, does Blackmagic decide that the interchanged decimal typo is in the published primary, or in the primary value they used in calculating the matrix?
Being a colourspace intended for intermediate calculation consistency rather than say a display standard, it doesn't really matter which way they choose, and if Resolve currently uses precalculated matrices based upon 0.1682 I think that they'll update the primary rather than the matrix, but it does need to be their choice.
Provisionally I'll add in the colourspace based upon the matrix primary value, as that is what would fit with Resolve, then, if they decide to go the other way, I can just change a couple of digits in LUTCalc,
Ben
I've just pushed DaVinci Intermediate colourspace code to the LUTCalc files here, plus an online 'testing' version:
http://cameramanben.github.io/LUTCalc/testing/
Just written the intermediate OETF code now, but looks to be coming out right (the 'range' should be 100%, but LUTCalc should be setting that correctly automatically)
I'm not inclined to update the main online version or Mac app just yet, pending Blackmagic being definitive around 0.1618 or 0.1682!
Ben
I attempt to generate 1D LUT DaVinci Intermediate to Amira709 and seems something is broken there yet. LUT gives black screen in Resolve 17 beta. It also gives error when i attempt to open it in other apps.
Hi radioproektor. Thanks for that and sorry for the slow reply.
Just tested myself, and you are quite right. As you mention, 1D from DaVinci Intermediate to something else is filling up with NaN values. I tried 3D without trouble. I'll take a look at this today - looks like its probably a typo error on my part. Ben
D'oh,
think I found it. Typo on a variable name in one function. I'll check it thoroughly and hopefully upload later today,
Ben
Please add support for DaVinci Resolve Wide Gamut Intermediate color space and gamma. Specs are here https://documents.blackmagicdesign.com/InformationNotes/DaVinci_Resolve_17_Wide_Gamut_Intermediate.pdf