- This topic has 39 replies, 3 voices, and was last updated 6 years, 10 months ago by
.
-
Posts
-
These sentences look contradictory to me.
That makes no sense.
EDIT: I just saw that you wrote “Why not have at least an option to not map 0 to 0 and 255 to 255, but instead use the calibrated and interpolated values?”, but I read it as “Why not have at least an option to
notmap 0 to 0 and 255 to 255, but instead use the calibrated and interpolated values?”. See below for my answer to your actual question.Why not map them to values from monitor profile instead?
That would mean input 255 would no longer be 255 on the output side, thus violating current video standards.
I will try to find out where this particular one comes from, but there are other examples, and they go unnoticed simply because they are being watched on non-wide-gamut displays.
I think there are probably not many professionally created videos with such encoding issues. The examples I’ve seen were things like screencasts and the like.
Why not map them to values from monitor profile instead?
That would mean input 255 would no longer be 255 on the output side, thus violating current video standards.
I think we are talking about different things.
MadVR doesn’t use 255 for control/timing information, and there shouldn’t be a requirement to pass it unchanged. So, it relies on 3D LUT to provide all the calculation needed for color mappings.
If there is a video with limited range, there shouldn’t be values 0 or 255. But if it has these values, should they be interpreted as some timing values? I think no, they should be either discarded or mapped to correct values.
That’s why I don’t understand the requirement for mapping 255 to 255 for this particular use case.If there is a video with limited range, there shouldn’t be values 0 or 255. But if it has these values, should they be interpreted as some timing values? I think no, they should be either discarded or mapped to correct values.
Feel free to talk to Graeme about this.
Ok, just a little clarification – can 3dlut file for madVR be created by Argyll or I still need DisplayCAL?
Ok, just a little clarification – can 3dlut file for madVR be created by Argyll or I still need DisplayCAL?
Depends if you want a GUI for it or are fine with using commandline tools.
Command-line is enough. I just didn’t look much into Argyll – hence the question.
I’ve already mentioned what I saw in logs:
collink.exe
-v
-qh
-G
-iaw
-r65
-n
-3m
-et
-Et
-b
-IB:0.0:2.4
-a
“PA302W.cal”
Rec709.icm
“PA302W.icm”
BT.709.icmWhat else is required?
It’s good that the results will be the same.
You told me to contact Argyll author. Though I understand it might be even more difficult to describe my suggestion there.Graeme has made a change in the latest development snapshot of ArgyllCMS to no longer pass sync through by default. I’ve updated the snapshot thread download links.
