cameramanben / LUTCalc

Web App for generating 1D and 3D Lookup Tables (LUTs) for video cameras that shoot log gammas.
http://www.lutcalc.net
GNU General Public License v2.0
249 stars 51 forks source link

DaVinci Resolve Wide Gamut Intermediate color space and gamma support #17

Closed radioproektor closed 1 year ago

radioproektor commented 3 years ago

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

nick-shaw commented 3 years 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.

radioproektor commented 3 years ago

Seems it was already fixed in datasheet: Initial Release 1.0.1 11/09/2020 Fixed incorrect matrix values

KelSolaar commented 3 years ago

Nope, the matrices does not agree with the primaries.

cameramanben commented 3 years ago

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

nick-shaw commented 3 years ago

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!

RikshaDriver commented 3 years ago

Inside Resolve 17, the CIE scope shows the Wide Gamut primaries with the green X value at .1682, which aligns with the quoted matrices.

KelSolaar commented 3 years ago

The problem is the primaries as given in the White Paper:

image

cameramanben commented 3 years ago

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

cameramanben commented 3 years ago

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

radioproektor commented 3 years ago

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.

cameramanben commented 3 years ago

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

cameramanben commented 3 years ago

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