View Single Post
Old 6th June 2011, 20:29   #7999  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
I don't understand why it wouldn't result in proper color correction. Can you explain?
You would probably be better off asking yesgrey. I seem to remember being told that setting the input levels correctly were needed for yCMS gamut/gamma corrections to be accurate.

Quote:
Originally Posted by madshi View Post
No, according to yesgrey it's not clipped anymore since yCMS v1.6.
I misspoke. Input RGB_Video wouldn't be clipped, but WTW/BTB would be compressed to limited-range levels when passed through the 3dlut with RGB_Video output. In other words if you fed 0-255 video to a RGB_Video -> RGB_Video, 0-255 would be compressed by the 3dlut to 16-235, get processed as 16-235, and output as 16-235.

Quote:
Originally Posted by madshi View Post
If the 3dlut were the only place where conversions are done then you would be right. But the source data is already converted by shader math before sending it to the 3dlut. If the shader math correctly converts any source format to yRGB with a pure power curve of 2.2, then the 3dlut should be able to properly process the data further. I don't really see the problem?
So madVR is treating all videos as a 2.2 power-curve (which is a reasonable guess, but isn't necessarily correct)? The problem would be if you wanted your videos to be linearized with the assumption they were something other than a 2.2 power-curve, like a REC709 curve or some other arbitrary gamma which is unique to the source.


Quote:
Originally Posted by madshi View Post
It would ill not be accurate if you fed the videos into the 3dlut without modification. But that's not what happens.
Then what does happen? madVR linearizes REC601 with a REC601 curve, REC709 with a REC709 curve, PAL with a PAL curve and then coverts to a gamma of 2.2? If that is really what you are doing, that gamma of 2.2 intermediary gamma should be configurable when used with a 3dlut.


Quote:
Originally Posted by madshi View Post
What purpose does that have? Setting the input_transfer_function to 2.35 is a lie because the source doesn't really have that transfer function, or am I wrong? Isn't that even invalid yCMS usage?
I don't believe so, yesgrey seemed to think it was a valid use-case of the option. janos666 was using the input_transfer_function to describe his display rather than the transfer function of the video.


Quote:
Originally Posted by madshi View Post
External 3dlut support is not only for manually created yCMS 3dluts. There might be other external tools which create 3dlut files, too. We've intentionally made the 3dlut format open source and free.
If that is the reason you left it in, so be it. There would be little incentive to anybody else to implement an application for creating 3dlut files for madVR with the input format requirements being so limited. Sure the gamut adaption could be different, but you've cut out madVR's ability to use 90% of the 3dlut functionality in 0.62+. I still don't like that you are limiting the usefulness and flexibility of the 3dlut compared to shaders.


Quote:
Originally Posted by madshi View Post
No. It's like this:

(1) chroma upsampling
(2) YCbCr -> RGB conversion
(3) gamma adjustments and gamut conversion
(4) scaling
(5) PC levels stretching, if needed
(6) dithering


(1) chroma upsampling
(2) YCbCr -> RGB conversion
(3) gamma adjustments and gamut conversion
(4) 3dlut
(5) scaling
(6) PC levels stretching, if needed
(7) dithering

The only real difference is that the gamma adjustments and gamut conversion either convert to the display target, or to the 3dlut input spec.
Thanks for this. I'm still a bit confused how madVR is dealing with 16-235 input vs 0-255 input. Can you explain? How does madVR processing of 16-235 YUV input differ from 0-255 YUV input? How does madVR processing of 16-235 RGB input differ from 0-255 RGB input?

From what you've said so far madVR converts everything to 16-235 levels, so madVR should never be fed 0-255 data as input?

Quote:
Originally Posted by madshi View Post
Please check v0.63. Maybe you'll find it an improvement?
I'll take a look by tomorrow, I'm thinking I may just sleep on what you've said and the changes made. You've been helpful and informative, but all this back and forth is tiring me out, and I'm sure you as well. Hopefully your next set of replies will ease the last confusion for the time being. As of right now, I still can't help this lingering feeling that 0.62+ is a downgrade from 0.61 functionality wise (3dlut stuff). For my needs, does 0.62+ offer any advantage over 0.61 which are worth the loss of 3dlut flexibility? I'm still not sure yet. In the best of worlds, I would have liked madVR's old 3dlut behavior to coexist with the new, but I assume you removed it to reduce the code/settings complexity needed for two unique 3dlut/shader render paths.

Quote:
Originally Posted by yesgrey View Post
Nothing is clipped, as long as you maintain 16-235 on both input and output of 3DLUTs, like madshi is doing.

As long as madshi performs right the stretching from 0-255 to 16-235 (16-240), and back after the processing, considering that the sources are 8 bit and shader math is 32 bit FP, you will not have any precision loss, and only one 3DLUT would be enough.
Is that really true that conversion from 0-255 to 16-235 to 0-255 in 32 bit FP math is lossless? It seems like it would be lossy to some extent.

Quote:
Originally Posted by yesgrey View Post
You're missing one thing. The gamut correction from PAL/NTSC/HD to yRGB is performed on linear light. For that, madVR converts to linear light using each standard's transfer function. Then, it encodes the linear light again to gamma light to minimize quantization errors when accessing the 3DLUT. yRGB uses a pure power function 2.2 gamma curve, so, yCMS will get exactly the same linear light data as before. We created this intermediate color space (yRGB) just to allow
a simpler user experience, or else the users would need to use 6 3DLUT files.
Does madVR actually do this? If it does, this conversion to 2.2 still bothers me. I'll need to do some testing. If I'm not able to get madVR 0.62+ to produce a video which looks identical to 0.61 then something is wrong. Sleep first, then I'll test.

Quote:
Originally Posted by yesgrey View Post
Just to make it clearer, madVR's new processing chain should give the same results as the previous one when using yCMS and the Gamma_Curve command, so don't worry about it. I agree that the GUI might need some improvements, but the processing chain was thoroughly discussed by us before being implemented.
I don't use the Gamma_Curve command, which is why I am stressing about it. I've gotten to the point that I don't want anything to touch my gamma (except linearizing for gamut correction).

Last edited by cyberbeing; 6th June 2011 at 20:47. Reason: for yesgrey reply above
cyberbeing is offline   Reply With Quote