Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DCDM Inverse ODT #7

Closed
antonmeleshkevich opened this issue Oct 6, 2021 · 3 comments
Closed

DCDM Inverse ODT #7

antonmeleshkevich opened this issue Oct 6, 2021 · 3 comments

Comments

@antonmeleshkevich
Copy link

Hi! Here is the example of what I was talking about.
Even with rec709 limited gamut, XYZ image can't be completely used as an input for DCDM. And even if a hard clip the input image far from 0 and 1 values.

I've used Rec709 curve because if I use power law gamma or just Linear, the image that goes into Inverse ODT doesn't contain colors that cause this artifact.

01

02

03

And here is what happens if I replace Inverse ODT and ODT by each other:
04

@jedypod
Copy link
Owner

jedypod commented Oct 7, 2021

Thanks Anton for the bug report! I get what you are talking about finally. I did some digging and found the issue. I was missing a clamp on LMS prior to the inverse tonescale.

I've pushed a fix here.

Test it out and let me know how it goes!

@antonmeleshkevich
Copy link
Author

it's fixed now, thanks!

But I have another one :) Not sure if this is a bug or an expected limitation though.

Here is the image (well, not the image but a vectorscope :) ) that has rec709 limited gamut in ACEScg after the first node.
2nd and 3rd nodes are OpenDRTs one after the other. The first one is ACEScg > DCDM ODT. And the second one is the same but Inverse. So even Rec709 gamut is compressed by inverse of DCDM that should preserve all the XYZ colors, if I get it right. Or at least to preserve AP1 colors I guess. Or at least P3? But it can't do it even with rec709 colors. All the colors are compressed after the Inverse, especially blue.

Screenshot 2021-10-08 013324

Screenshot 2021-10-08 013344

@jedypod
Copy link
Owner

jedypod commented Oct 9, 2021

Hey again and sorry for the delay in getting back to you about this.

The difference you are seeing there is from the gamut compression, which is applied only in the forward direction.

This setup is still being prototyped and tested, and I'm leaning towards removing it from the DRT and treating it as an LMT component instead.

Bigger picture, if you are looking for a display transform with a perfect inverse, OpenDRT is probably not a good fit. Because of the way it is designed there will be more differences in the inverse direction than per-channel approaches like rgbDT or ACES.

I'll close this because the DCDM inverse issue has been resolved, but feel free to report back if you see anything else suspicious! Thanks again for your help and testing.

@jedypod jedypod closed this as completed Oct 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants