gamut conversions through Avisynth ?

[leeperry]

D65 is not required for that
movies are mastered in D65/2.2/SMPTE-C or EBU...but well, whatever floats your boat. D50 is yellowish and D75 blueish...it kinda defeats the whole point of gamut conversion, innit?

[yesgrey]

Thanks Yesgrey !!! :thanks:
You're welcome.:)
But you also should thank other people, like Charles Poynton, JohnAd, tritical and madshi (listed by chronological order), who helped me achieving the current state.
:thanks:

[yesgrey]

movies are mastered in D65/2.2/SMPTE-C or EBU...but well, whatever floats your boat. D50 is yellowish and D75 blueish...it kinda defeats the whole point of gamut conversion, innit?
It would be preferable D65, but the Chromatic_Adaptation is exactly for compensating that...

[pbmtp]

Hi yesgrey,

Did you find anything about my issue ? Is it something miss configured ?

[leeperry]

It would be preferable D65, but the Chromatic_Adaptation is exactly for compensating that...
ahhhhh your LUT can also compensate for D75>D65? cool stuff :devil:
miss configured
did she win any pageant :confused:

[yesgrey]

Did you find anything about my issue ?
Please send me by e-mail the .reg file. The copy paste thing is not working...

[yesgrey]

ahhhhh your LUT can also compensate for D75>D65? cool stuff :devil:
ddcc already did that. With cr3dlut I improved it slightly because not running in real time allowed me to use the full Bradford transform to perform the chromatic adaptation, instead of the linear version of it; but it would always be better to use a display calibrated for the same illuminant (white point) as the source.;)

[leeperry]

it would always be better to use a display calibrated for the same illuminant (white point) as the source.;)
less banding?

[yesgrey]

less banding?
More accurate colors.

[pbmtp]

yesgrey you've got mail :)

[leeperry]

More accurate colors.
compared to what? how to measure the colors "accuracy"? ColorHCFR will give the RGBW coordinates and saturations, that's it.

BTW, if you could somehow allow us to import the ColorHCFR saturations within cr3dlut, that'd be really awesome...that's the Achilles' heel of gamut conversion at this point IMHO.

http://img141.imageshack.us/img141/7501/satu.png

[darkbasic]

ColorHCFR will give the RGBW coordinates
Please explain me because I can't understand and so I don't know which coordinates I need. Let's make an example with AdobeRGB!

According to the documenation,the primaries are at:

Red x=0.6400, y=0.3300
Green x=0.2100, y=0.7100
Blue x=0.1500, y=0.0600
White x=0.3127, y=0.3290 (the reference white is D65)


If I dump the wtpt, rXYZ, gXYZ and bXYZ tags form the profile I obtain:

C:\Argyll_V1.0.4\bin>iccdump.exe -v3 -t wtpt -t rXYZ -t gXYZ -t bXYZ AdobeRGB1998.icc
XYZArray:
No. elements = 1
0: 0.950455, 1.000000, 1.089050 [Lab 100.000000, -2.387320, -19.404505]
XYZArray:
No. elements = 1
0: 0.609741, 0.311111, 0.019470 [Lab 62.601347, 90.371212, 78.149349]
XYZArray:
No. elements = 1
0: 0.205276, 0.625671, 0.060867 [Lab 83.214105, -129.089932, 87.172524]
XYZArray:
No. elements = 1
0: 0.149185, 0.063217, 0.744568 [Lab 30.210038, 69.243738, -113.612302]

The tristimulus values (XYZ) of the "white point" (0.950455, 1.000000, 1.089050) are in the "AdobeRGB white" source (so D65, If I had chosen my monitor profile instead of AdobeRGB would be ~ D65).

In fact if I convert it from XYZ to xyY I obtain 0,312701 0,329001 0,999999 which is the value from the documentation, of course.


Now let's see rXYZ, gXYZ, bXYZ.
They are the XYZ values of the R, G, B primaries and they form a 3x3 matrix which converts the normalized RBG values to XYZ.

If the white of the device is D50 they are exactly the colorimetric coordinates of the primaries. If not, the colorimetric coordinates had to be chromatic adaptated, in fact ICC specifications want relative colorimetry, so the matrix have to port the device white to the PCS white (D50).

For rXYZ we have 0.609741, 0.311111, 0.019470. If we do chromatic adaptation (from D50 to D65) and then we convert from XYZ to xyY we obtain 0,640014 0,330001 0,297363 which is the value from the documentation.

So, what are the RGBW coordinates I need? XYZ or xyY? Chromatic adaptated or not?
Can you make and example for AdobeRGB so I can use use the spectrophotometer (which is not comatible with ColorHCFR) instead of the Eye-One Display v2 (which is not so good with extreme gamuts)?

[yesgrey]

Please explain me because I can't understand and so I don't know which coordinates I need. Let's make an example with AdobeRGB!

According to the documenation,the primaries are at:

Red x=0.6400, y=0.3300
Green x=0.2100, y=0.7100
Blue x=0.1500, y=0.0600
White x=0.3127, y=0.3290 (the reference white is D65)

So, what are the RGBW coordinates I need? XYZ or xyY?
Use only xy from the xyY. The chromatic adaptation is not needed, you only need to put the coordinates of the white point, and cr3dlut will perform the chromatic adaptation.

The values you'll need are like the above values. If your display is AdobeRGB, you don't need to specify the RGBW colors, simply select option 4, cr3dlut already knows the standard colors. You only need to specify them when they are not accurate relative to any standard.

[yesgrey]

I used the following patterns in ts files which are adaptation of AVSHD for being use with a video player. Here is the link http://kvcd.net/downloads/MIRES_1080P_POUR_MPCHC_V3.rar The ones I used were 100 % Color (folder ColorHCFR Fields\100% Color).

That's the problem.
These files were not created with the BT.709 transfer function, but with an aproximation of it, hence the good results you get with the PS (which uses the same approximated formula) vs the 3DLUT file, which was created with the exact BT.709 transfer function.
Here is the file for cr3dlut that will give you the same results as the PS script:
# Settings for creating a 3D LUT for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, PAL HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using PC Levels (Black: 0 and White: 255)
# using advanced parameters instead of 'x_Video_Format'

# Do not mess up with these settings
Chromatic_Adaptation 3 # same as PS
Out_Of_Gamut_Clipping 0 # same as PS
Input_Bit_Depth 8
Input_YCbCr_Full_Range 0 # Y: 16-235; CbCr: 16-240
Input_Gamma 9 1.0 0.0 0.45 0.0 # same as PS
Output_Bit_Depth 8
Output_YCbCr_Matrix 0 # RGB
#Output_YCbCr_Full_Range 1 # Ignored
Output_RGB_Black_White 0 255 # RGB: 0-255

# You can change the following settings
Input_YCbCr_Matrix 1 # BT.709
Input_Primaries 0 # BT.709

Output_Primaries 9 0.675 0.324 0.289 0.711 0.142 0.052 0.313 0.332 # custom primaries for video proj
Output_Gamma 9 1.0 0.0 0.45 0.0 # same as PS

Remember that official video material should be mastered using the exact standard curves.

You can compare the results using a tool like colorpic, so you can avoid turning on your projector and all the calibration stuff.;)

[pbmtp]

Hi yesgrey,

thanks for taking time investigating the problem, i am glad everything is working as expected in cr3dlut, i will try your input file and compared it with pixel shader to validate when i have some time to launch "all the calibration stuff" :). And i will switch back to cr3dlut + t3dlut.

Do you know if mp4 version of AVSHD files (http://www.avsforum.com/avs-vb/showthread.php?t=948496 ) suffer from the same problem ? If so maybe you could report the issue to the AVS HD thread so that it can be improved.

[darkbasic]

According to the documenation,the primaries are at:

Red x=0.6400, y=0.3300
Green x=0.2100, y=0.7100
Blue x=0.1500, y=0.0600
White x=0.3127, y=0.3290 (the reference white is D65)

The values you'll need are like the above values.

This is a problem, because those values are referred to an observer adaptated to the device white, while the values stored in the ICC tags are referred to an observer adaptated to D50.

From the ICC tags I can see my monitor's Red is x=0,675968 y=0,313882 which is _ABOUT_ x=0,671004 y=0,312852 referred to an observer adaptated to the device white. I told _ABOUT_ because I found those values with this (http://www.brucelindbloom.com/index.html?ColorCalculator.html) calculator (click on "Calc" and then on "Chromatic Adaptation Calculator") which doesn't let me choose the temperature in Kelvin but only D50/65/... and my monitor temperature is not exactly D65, but is 6439,1K (as you can see from the white point coordinates x=0,313635 y=0,330961).

[yesgrey]

And i will switch back to cr3dlut + t3dlut.
Remember that some of the settings are only for you to be able to get the same results as the PS cript. After that, you should use the recomended settings.

If so maybe you could report the issue to the AVS HD thread so that it can be improved.
Yes, I will take a look into it. Apparently, in the issues list on the first post, they already noted that something is not correct...;)

[yesgrey]

which is _ABOUT_ x=0,671004 y=0,312852 referred to an observer adaptated to the device white.
... and my monitor temperature is not exactly D65, but is 6439,1K (as you can see from the white point coordinates x=0,313635 y=0,330961).

Maybe I can find some time to include a calculator into cr3dlut... Until then, try using those coordinates and D65 coordinates and see the results.

[darkbasic]

How can I check which is the color space of a movie (BT 709, EBU, SMPTE-C...)? Is there an utility to check it?

[leeperry]

oh that's the easy part :)

SD: BT.601
HD: BT.709

european/russian/brazilian movies = EBU
USA/ASIAN: SMPTE-C

it's all explained in the OP I think ;)

[yesgrey]

european/russian/brazilian movies = EBU
USA/ASIAN: SMPTE-C
That would be for SD. For HD it's supposed to be BT.709 primaries.

[leeperry]

That would be for SD. For HD it's supposed to be BT.709 primaries.
I couldn't more disagree...movies are not mastered w/ BT.709 primaries.

We've discussed it many times, it's been discussed many times on AVS too..if you check the OP, the french CEO of the ISF has a list on his website and no movie on bluray whatsoever is ever mastered w/ BT.709 primaries :o

the HDTV gamut is used for demos, but not for movies...well at least for mastering studios that still master their stuff on CRT(99% of them?)

the CARS hero will always remain dark orangey in the movie, way to go! :D

[yesgrey]

I couldn't less disagree...movies are not mastered w/ BT.709 primaries.
According to some people that work in the area they use their displays gamut corrected to BT.709. Nobody knows for sure, there is not a 100% agreement on that. I only stated what the standards say, but I accept perfectly that in some cases they do not gamut correct their displays.;)

[leeperry]

that's the aforementioned thread: Question : Only for those that are 6500K/D65/REC709 calibrated ... - AVS Forum (http://www.avsforum.com/avs-vb/showthread.php?t=1038602)

it matches exactly what the ISF and Joe Kane say, movies on bluray are mastered in SMPTE-C on CRT :/

they get their CRT recalibrated on a weekly basis, and it goes off as SMPTE-C encoded in BT.709..

[yesgrey]

These files were not created with the BT.709 transfer function, but with an aproximation of it, hence the good results you get with the PS (which uses the same approximated formula) vs the 3DLUT file, which was created with the exact BT.709 transfer function.
Do you know if mp4 version of AVSHD files (http://www.avsforum.com/avs-vb/showthread.php?t=948496 ) suffer from the same problem ? If so maybe you could report the issue to the AVS HD thread so that it can be improved.
pbmtp,
I have looked into the files and the way they were created and there is not anything wrong with them.
I've thought a little more about it, and I think that the problem is only at the output gamma setting.
The displays usually have a gamma function that mimics a pure power curve, and the BT.709 gamma curve is not exactly like that.
It seems to me that the bad results you are getting are due to using an output gamma curve that does not fit correctly your display's gamma curve.
So, I would suggest that you also run your tests with:
Input_Gamma 1 # BT.709 gamma encoding
Output_Gamma 9 1.0 0.0 0.45 0.0 # same as PS

Let me know if it worked...

[pbmtp]

Hi yesgrey,

I will do some test next week and tell you what happened.

[Kazuya]

movies are mastered in D65/2.2/SMPTE-C or EBU...but well, whatever floats your boat. D50 is yellowish and D75 blueish...it kinda defeats the whole point of gamut conversion, innit?

Sorry I was'nt notified !

I didn't say D65 is useless, I say it is not necessary to have a perfect gamut on RGB points.
D65 only puts YCM at the right place.

Pbmtp : in my opinion, you have a problem on your display.

[pbmtp]

kaz, what could it be as when using the pixel shader script the CIE of my Z3000 is very close to be spot on with BT.709 ?

anyway i will try what yesgrey suggested next week and see what happens.

[Kazuya]

I don't understand your question.

It would be preferable D65, but the Chromatic_Adaptation is exactly for compensating that...

Yes, I noticed it when I measured greyscale with KMP ! :D

Is there a way to avoid it if for some reason we don't want a temperature correction ?


Well, Yesgrey, I have an other question for your colorimetric skills ! :p

I made some color patterns at only 20 IRE.
And, I was wondering how should be the gamut with this colors.
I used a 20IRE white pattern too.

Should the gamut be exactly the same than the CIE ?
Or should it be equaly narrow ?
Or whatelse ?

This is the measure on my Z4 :

http://img694.imageshack.us/img694/4351/clip.png

But maybe the Eye one is not enough sensitive to measure correctly those dark patterns ?
(probably the better explanation for the yellow position)

[yesgrey]

Is there a way to avoid it if for some reason we don't want a temperature correction ?
If you want to avoid the chromatic adaptation, setting it to 0 will disable it.

I made some color patterns at only 20 IRE.
And, I was wondering how should be the gamut with this colors.
I used a 20IRE white pattern too.

Should the gamut be exactly the same than the CIE ?
Or should it be equaly narrow ?
Or whatelse ?
Yes, The gamut should be exactly the same.

But maybe the Eye one is not enough sensitive to measure correctly those dark patterns ?
That's a possibility, because the sensors are less accurate at the low IRE levels, but I already noticed that the gamut correction is not working good at very low levels. I'm currently working on it to solve the problem, but probably I will simple disable the gamut correction at low levels, because our sensitivity to colors is not very high at those levels, and the low bit depth of the source (8bit) is a problem when working at those levels...

[Kazuya]

Ok, thanks ! :)
I will do more tests at different levels.

[yesgrey]

Test also without any gamut correction, that way you can have an idea of the accuracy of the meter at lower levels...

[Kazuya]

Yes, I forgot to do it on my Z4 but I do it on my LCD display :

http://img204.imageshack.us/img204/3699/clip12.png

I think the gamut conversion is working properly, even at 20IRE.
I watched Knowing yesterday, it was awesome colorimetricaly speaking, and I watched tonight an episode of Gossip Girl (DVD) and it was totally incredible ! :o Even in dark scenes.

[yesgrey]

I think the gamut conversion is working properly, even at 20IRE.
The problem is not the gamut conversion not working properly at low levels, it's the handling of out of gamut values at low levels, that could cause severe banding. I notice it some times, at very low levels. I'm currently investigating it to find the cause and how to solve it.

I watched Knowing yesterday, it was awesome colorimetricaly speaking, and I watched tonight an episode of Gossip Girl (DVD) and it was totally incredible ! :o Even in dark scenes.
Yes, I know what you're talking. After we start watching at accurate colorimetry, it's very hard to go back again...;)

[Kazuya]

I didn't notice severe banding at all, maybe depends of display ?
I will take a better look.

Well, yesterday I make gamut correction on a VW60 Sony blackpearl, with 334hours lamps.
This is what I obtained with shaders on MPC-HC, all patterns in MPC, even greyscale :

http://img17.imageshack.us/img17/272/clip19.png

The most interesting part is the gamut with 20% colors : it is narrow, but it looks great ! :o
Can I conclude the eye one is not so bad in low level colors ?
And that there's big differences between displays, like I suspected ?

[yesgrey]

I didn't notice severe banding at all, maybe depends of display ? I will take a better look.
With the shaders method there is no problem, only with the 3DLUT method, and if you change the gamma.
A good place to notice the banding is the start of the movie "Batman: The Dark Knight". At the beginning, when the logo of DC Comics appears, it will show severe banding around it.

Can I conclude the eye one is not so bad in low level colors ?
And that there's big differences between displays, like I suspected ?
From the images you posted that seems to be the most likely...

[Kazuya]

The 3Dlut method but where ? In madVR ?

[yesgrey]

The 3Dlut method but where ? In madVR ?
In madVR or t3dlut, the results are the same, so it should be a problem in the 3DLUT. I'm working on it...

[leeperry]

SD: BT.601
HD: BT.709

european/russian/brazilian movies = EBU
USA/ASIAN: SMPTE-C
apparently you can add Australia to the EBU list: http://www.indietalk.com/showthread.php?t=4240

and China too I think?

[pbmtp]

Hi yesgrey,

I finally had some time to make the measurement you asked me, all configuration file and HCFR chc can be found at the following location:
http://pbmtp.free.fr/3dlut-z3000/
On my Z3000, the clear winner is HD_PC_Z3000_PS.txt (same configuration for cr3dlut/rgb3dlut as the pixel shader). The corresponding HCFR chc file has all the possible measurement possible done, you can see that CIE is perfect and saturation are really as good as they can be.

Damien

[yesgrey]

Hi,
Great!
Thanks for posting the results. It's good to see that our work give such good results.:)

I suggest you to use Chromatic_Adaptation 2 with the PS, it should give you more accurate colors. The difference you are getting between HD_PC_Z3000_PS and HD_PC_Z3000_2, should be due to the different input gamma curves.

[Kazuya]

What is the difference between chromatic adaptation 2 and 3 ?

[yesgrey]

What is the difference between chromatic adaptation 2 and 3 ?

chromatic adaptation 2 is the preferred because it causes less errors. I only added 3 to be able to get with cr3dlut the same correction like the pixel shader method. We should always use 2. 1 and 3 are only for testing purpose.

If you want a more detailed description, read this (http://infoscience.epfl.ch/record/34077/files/FinlaysonS00.pdf). It explains the three methods implemented in cr3dlut, and also describes a fourth that, maybe one day, I will also add...

[Kazuya]

Ah ok, I was in 3 for chromatic adaptation, and didn't see anything wrong.
But I will put it at 2 and will see !
Thanks.

[leeperry]

chromatic adaptation 2 is the preferred because it causes less errors. I only added 3 to be able to get with cr3dlut the same correction like the pixel shader method. We should always use 2. 1 and 3 are only for testing purpose.
but only "3" works if the destination gamut is smaller, otherwise the green gamma is burned to death..and most DLP's have a lack of green in the first place, so you get a very greenish picture basically.

I know you're working on it as there seems to be a glitch in some part of the code, but "3" is mandatory on my DLP...please don't drop it in the next version :)

[yesgrey]

Ah ok, I was in 3 for chromatic adaptation, and didn't see anything wrong.
When the difference between the source and the output white points coordinates is small you should not notice any difference, but since it will take exactly the same time when watching your movies, I suggest setting it to 2.
Remember that this is not a 100% sure thing, because if you have read the article I linked above, you could see that this is just the results of several tests, so it's possible that some people prefer other settings.

but only "3" works if the destination gamut is smaller, otherwise the green gamma is burned to death..and most DLP's have a lack of green in the first place, so you get a very greenish picture basically.
From what I have tested previously, I thought that your problem was more due to the out of gamut clipping, than to the chromatic adaptation... Also, since you're color blind, I don't think that you would fit in the profile of the people used for when the chromatic adaptation algorythms were tested... but it's good to have you onboard, so we can make this work to all people.:)
Also, don't worry, usually I don't drop any features.;)

[leeperry]

ahhh don't give me the colorblind stuff again :D

I'm sure you can easily see that we got a problem w/ the green gamma in the sixth screenshot, and some of that code is in cr3dlut: http://forum.doom9.org/showpost.php?p=1292804&postcount=444

but indeed, it's got to do w/ the OOG...but the only way we could get the exact same colors as the PS script was through "Chromatic_Adaptation=3".

anyway, we already spoke about all this...the average guy will recalibrate his display every few weeks, and we don't use highly accurate spectrophotometers...and projectors MH lamps have fluctuating R/G/B levels, so all that stuff is slighty overkill IMVHO.

when you recalibrate on a weekly basis w/ a Minolta CS200 sensor(that's factory recalibrated every few months)...then yes, we can talk about this level of accuracy...but quite frankly ddcc and the PS script were going different ways(ddcc being more accurate), but even on test patterns screenshots you'd have a hard time identifying them in a DBT and tell whichever one is better(especially w/ a 16-235 SMPTE-C source).

[FoLLgoTT]

@yesgrey3
The primaries are defined by three coordinates in color space (usually xyY). Sometimes it is not sufficient to correct only x and y. It would be very cool if cr3dlut would support the luminance Y in the future.

[yesgrey]

The primaries are defined by three coordinates in color space (usually xyY).
Yes, I've already read that in several other places. I am considering looking into that so I could try to add it in a future version...
Thanks for the tip anyway.:)

[FoLLgoTT]

Yes, I've already read that in several other places. I am considering looking into that so I could try to add it in a future version...
Thanks for the tip anyway.:)

Great news. :)

Btw. a complete CMS with independent controls for all primaries and secondaries in RGB color space would be a killer application for the HTPC. Only the $5000 Lumagen Radiance (http://www.lumagen.com/docs/Tip0002_GamutCalibration.pdf) has implemented such a CMS. But now I'm only dreaming a bit. It is great what you have achieved with cr3dlut! :)

[Kamus]

I've got good results, but should they be better?
I'm using MadVR+cr3dlut, I'm wondering if I've done something wrong here:

http://i139.photobucket.com/albums/q296/Saintkamus14/gamut.jpg

Pic on the left is from the native gamut of my JVC RS1x projector using an eye one 2 LT, the one on the right is the corrected gamut, and while it's better i still get a delta E that's quite a bit off.
Green has a delta E of 11, 6.7 on red and 17 on blue with the 3dlut file enabled.
While these aren't horrible results, i'm obsessed. (and supposedly delta E needs to be about < 3 to be undetectable by people right?)

My HD_PC file looks like this:

# Example input file for cr3dlut v2.1 and up
#
# Settings for creating a 3D LUT for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, PAL HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using PC Levels (Black: 0 and White: 255)

# Set input bitdepth
Input_Bit_Depth 8

# Set source video format
Input_Video_Format HD YCbCr

# Set output bitdepth
Output_Bit_Depth 16

# Set display video format
Output_Video_Format HD RGB_PC

# set Output Primaries
Output_Primaries 9 0.651 0.348 0.294 0.697 0.140 0.043 0.312 0.330

BTW, i'm calibrated to D65 if it means anything, and gamma is at 2.2 (i simply used the eye one match 3 software to set the grayscale & gamma with very good results, or so says HCFR. Maybe the fact that i'm not using any gamma settings on the file has something to do with it? I figured that it was pointless since the projector is already at 2.2 gamma and i figured it shouldn't be related in the first place)

Also, I'm using "PC levels" since my ATi videocard is set to RGB limited and that takes care of the video levels. The color patterns i used are from the AVS HD disc. (http://www.avsforum.com/avs-vb/showthread.php?t=948496) by extracting the files and playing them trough MPCHC. (also used color facts test patterns to see if there was any significant difference in the native gamut, compared to using the files, and there wasn't)

Anyway, any tips on how i could make this more accurate? I'm overall pleased with the results, but if i can improve them even more, then all the better.

Thanks in advance for anyone that takes the time to reply, and Kudos to everyone involved in making HTPC a very viable and cheap solution.

[yesgrey]

I've got good results, but should they be better?
Try adding this line at the end of your cr3dlut setting file:
Output_Gamma 9 1.0 0.0 0.454 0.0
If it's not good enough or if you notice any banding at low levels, try adding this too:
Input_Gamma 9 1.0 0.0 0.454 0.0

[Kamus]

Thanks, that seems to have done the trick for blue and green almost to perfection (had to use both input and output, just the output messed with the levels it seems) red is somewhat off, but it's due to the fact that my bulb doesn't seem to be able to do a full red anyway.

[yesgrey]

Great.:)

[janos666]

I calibrated my PC monitor with this target values: WP - exact D65 ; Tonal response curve - x^2.22 ; White luminance - 140 cd/m^2 (Balck luminance - Min. Neutral)
My hardwares and softwares: Q6600@3600Mhz (FPS@450) ; Radeon HD 5850 1Gb with Cat 9.12hotfix ; Windows 7 x64
I installed the latest AviSynth 2.6 alpha and the latest MPC-HC (stable x86), and I have a recent SVN build of FFDShow (x86). I used the latest cr3dlut and t3dlut from this thread.
This is all the 3 lines I have in the AviSynt box (I move the # for SD movies...):
yv12toyuy2(itype=2, threads=4)
t3dlut("C:\Program Files (x86)\AviSynth 2.5\hd - pc.3dlut", threads=4, destcs=2)
#t3dlut("C:\Program Files (x86)\AviSynth 2.5\sd - pc.3dlut", threads=4, destcs=2)
And I created my HD - SD.t3dlut file with this settings:
# Set source video format
Input_Video_Format HD YCbCr
Input_Bit_Depth 8

# Set display video format
Output_Video_Format HD RGB_PC
Output_Bit_Depth 8

# Gamut and gamma correction - measured native coordinates
Output_Primaries 9 0.656725 0.329082 0.228974 0.690610 0.140753 0.086776 0.313918 0.328022

# Gamut and Gamma Correction settings
Chromatic_Adaptation 2
Out_Of_Gamut_Clipping 1
Output_Gamma 1

And I have some questions:
Is it normal that I had to reduce the Output_Bit_Depth to 8 bit? I had constant 75% CPU utilization and only 18-20 FPS under Blu-Ray playback with 16-bit (720p was ok). But I do not have a lot of free CPU time with 8-bit anyway. 1080p playback is smooth until I do not try to apply another filters like 720p->1080p resize with FFDShow (there is a reason why would I do that but that is offtopic...).

When I set the Output_Gamma to 9 1.0 0.0 0.45 0.0 then the image is too bright. The result looks exactly the same when I miss the Output Levels (16-235 signal for a 0-255 PC monitor). I think that the output level parameter is ignored when this parameter is used in a later line.
I do not know if the HDTV standard is x^2.22 or something else (like sRGB has an own tonal response curve -> I can calibrate my monitor with an sRGB curve but there is no Rec 709 preset...). Should I worry about it?

I try to use this file with madVR but it would not load my 3dlut files. The malfunction is another question but:
- madVR is internally limited to YV12 input - (I tested it with unchecked AviSynt and FFDShow output settings)
- I can use this renderer with the AviSynt script and I can see corrected colors.
- This would imply that t3dlut is sending a YV12 output for madRV. But this could not be right with destcs=2 settings (and RGB_PC generation settings). It should send an RGB32 output and nothing else. And madVR should accept only YV12. (I did not set up any other conversion and I unchecked every box in FFDShow's output tab, expect YV12.) Where is the trick? :confused:

Anyway, this is a very nice stuff. I tried the old PS script but it caused some wired violet instead of blue. (I have a wide gamut display with over-saturated red and neon-green, but it misses some of the Rec709 blue area. :( )

[yesgrey]

And I created my HD - SD.t3dlut file with this settings:
# Set source video format
Input_Video_Format HD YCbCr

You should change the line above for SD sources.
Use NTSC instead of HD for ntsc dvds.
Use PAL_DVD instead of HD for PAL dvds.
(Read the ReadMe for further details)

This is all the 3 lines I have in the AviSynt box (I move the # for SD movies...):
yv12toyuy2(itype=2, threads=4)
t3dlut("C:\Program Files (x86)\AviSynth 2.5\hd - pc.3dlut", threads=4, destcs=2)
#t3dlut("C:\Program Files (x86)\AviSynth 2.5\sd - pc.3dlut", threads=4, destcs=2)
Is it normal that I had to reduce the Output_Bit_Depth to 8 bit? I had constant 75% CPU utilization and only 18-20 FPS under Blu-Ray playback with 16-bit (720p was ok). But I do not have a lot of free CPU time with 8-bit anyway. 1080p playback is smooth until I do not try to apply another filters like 720p->1080p resize with FFDShow (there is a reason why would I do that but that is offtopic...).

When you use 16 bit output t3dlut dithers the output to 8 bit, hence the higher cpu load. If you have low cpu power available you have to stick with 8 bit output.
You can also try using ConvertYV12ToYUY2() instead of yv12toyuy2, because the later is slower.
Another option would be to use rgb3dlut, which is also faster than t3dlut, but only supports 8 bit output.

When I set the Output_Gamma to 9 1.0 0.0 0.45 0.0 then the image is too bright.
When you change the gamma curve, you have to correct the brightness level of your display, that's why it looks brighter. You have to decrease the display's brightness until you get the correct black level.

I do not know if the HDTV standard is x^2.22
HDTV is BT.709.

I try to use this file with madVR but it would not load my 3dlut files.
madVR only works with 16 bit output 3DLUT files.


- madVR is internally limited to YV12 input - (I tested it with unchecked AviSynt and FFDShow output settings)
- I can use this renderer with the AviSynt script and I can see corrected colors.
- This would imply that t3dlut is sending a YV12 output for madRV. But this could not be right with destcs=2 settings (and RGB_PC generation settings). It should send an RGB32 output and nothing else. And madVR should accept only YV12.

Correct

(I did not set up any other conversion and I unchecked every box in FFDShow's output tab, expect YV12.) Where is the trick?
That's the trick.;)
When you only check YV12 at ffdshow's output, ffdshow converts the RGB32 output from t3dlut to YV12, and feed it to madVR.

Summing up, you should try disabling the avisynth script, and simply create a 16 bit output 3DLUT file to use with madVR. This should give you better performance, and better image quality.

[janos666]

Thanks for the detailed reply but I have to honor it with more questions ans corrections for misunderstandings. :)

You should change the line above for SD sources.
(Read the ReadMe for further details)

I already read that. And I am sorry, it was my mistake. I want to write: "HD - PC.3dlut" and not "HD - SD.t3dlut". You can see that I talked about 1080p and 720p movies later. But I made both SD and HD files with PC levels.

If you have low cpu power available you have to stick with 8 bit output.

I can live with that. (I am not sure about this dithering anyway. It usually means "noise" for me, not quality, and I am irritable about noise. But movies does not contain figures with color gradients. It is not so easy to imagine it with random colors on a random picture. I did not compare the results visually, yet.)

My concrete question supposed to be: Is it normal if my Q6600 (which runs at 3600Mhz with FSB450) can not handle a Blu-Ray movie with 16-bit 3dlut? I did not see another posts about this kind of performance problems in this topic and I think it is not me who has the slowest CPU here. So, I assumed it could be some kind of compatibility problem which causes high CPU load on my system. (Like I should use a specific AviSynth/FFDShow/MCP-HC build and not the last one, ect.) There is no any other active background task.

When you change the gamma curve, you have to correct the brightness level of your display, that's why it looks brighter.

Oh. This is not a good news because I would not do that. And it does not sounds like a correct solution anyway!
I calibrated my display to 140cd/m^2 because this was the default value in the calibration software. I would keep this white luminance value because it feels good for everyday usage (document reading/editing, web browsing, ect.)
Is there an exact value in the ITU Rec BT.709 standard? I could not see that. It should be a varying number which considered by the user (this is a function of ambient light conditions, personal feeling, ect.)

I can not go below 120 cd/m^2 anyway, it won't help now. The white luminance value with factory default OSD settings was ~280 cd/m^2, nearly two times more than it is after the calibration. And black was black (and not gray) in the movies with 0-255 output level settings in FFDShow. (Of course without t3dlut. I started to deal with this after I bought my calibrator...)

I think that brightness has nothing to do with this.
The image looks exactly when I miss the PC-TV levels. (Like the program ignores the PC level settings when it uses custom gamma settings.)
Or do you mention about some software brightness control in the player? That would not be a nice thing anyway.

HDTV is BT.709
Yes. And I would ask question about that.
Does this standard have specific tonal response curve (like the sRGB standard)? Isn't it match with some x^y (like gamma 2.22), or sRGB curve? Is there any EyeOne compatible software which can calibrate to this target?

madVR only works with 16 bit output 3DLUT files.
I thought about that. But I tried to use madvr first. When it refused to load the 3dlut files I came here to learn about them. I found the t3dlut plugin and it was later when I figured it out that I have to reduce the bit depth for smooth Blu-Ray playback...
It is not well documented how to use 3dluts with madvr. I could see 3 kind of template file labeling: "HD_PC" ; "HD - PC" ; "template HD-PC". I do not know what would be the correct file name for 3dlut files and where should I place them. (It was tricky to figure out that here is no real madvr installer, it is only a shortcut to register the filter, no matter where it is located momentarily, blahhh -> I know the install directory now, I only mentioned that...)

ffdshow converts the RGB32 output from t3dlut to YV12

I thought about that but I could not imagine that it could be true. Softwares can be smart only when they confuse the user with that. :p
Here is another CPU eater...
Is it a lossless conversion or does it have deficit? (Not if I would like to keep with this.)

*** May be it will solve some of my other problems if I eliminate this conversion. (Like the brightness/gamma/TV-PC level shit...) :)

create a 16 bit output 3DLUT file to use with madVR
This would be my goal. But I have another problems with madvr. (But I can solve them when I will have more free CPU power, so...)


UPDATE: I corrected the FFDShow output settings to RGB32 only. I have less CPU load with 8-bit 3dluts, I will try to generate 16-bit one again.
But black areas are still "washed out" with Output_Gamma 9 1.0 0.0 0.45 0.0. (The monitor is still calibrated to x^2.22, 140cd/m^2)
And the first (full black) frame of a movie tell the truth: It looks exactly the same when I miss PC-TV levels. I can see a gray rectangular between two black rectangulars. (16:9 source on 16:10 display...)
UPDATE2: And no. I can not play 1080p Blu-Ray movies with 16-bit 3dluts.

UPDATE3: I could solve my problems with madrv. It works well now. (I had to disable something in FFDShow...)
MadVR gives me better result with 9 1.0 0.0 0.45 0.0 and PC output settings than t3dlut. But this is not perfect yet. (At least, it won't miss the output levels, so black is nearly black and not gray now.)
There is some strange (and intensive) noise on dark areas with custom gamma settings. (I could see something like this when I watched old SD rips with very low bitrates.) It is not correct. I can not see this noise without custom gamma settings, and black is perfectly black when I clear this line with output_gamma.

Should I try to recalibrate my display with L* or sRGB tonal response curve and use one of these presets in cr3dlut for output_gamma?

[yesgrey]

My concrete question supposed to be: Is it normal if my Q6600 (which runs at 3600Mhz with FSB450) can not handle a Blu-Ray movie with 16-bit 3dlut?
No. You have to be doing something wrong...

I calibrated my display to 140cd/m^2 because this was the default value in the calibration software. I would keep this white luminance value because it feels good for everyday usage (document reading/editing, web browsing, ect.)
When you change gamma, you change the black level. Unless you recalibrate your brightness level you will get bad black levels. Though, considering this is only for watching movies and for your day-to-day usage you will use a different gamma, it's better keeping the gamma untouched.;)

UPDATE3: I could solve my problems with madrv. It works well now. (I had to disable something in FFDShow...)
MadVR gives me better result with 9 1.0 0.0 0.45 0.0 and PC output settings than t3dlut. But this is not perfect yet. (At least, it won't miss the output levels, so black is nearly black and not gray now.)
There is some strange (and intensive) noise on dark areas with custom gamma settings. (I could see something like this when I watched old SD rips with very low bitrates.) It is not correct. I can not see this noise without custom gamma settings, and black is perfectly black when I clear this line with output_gamma.

Should I try to recalibrate my display with L* or sRGB tonal response curve and use one of these presets in cr3dlut for output_gamma?
No. That's a problem that I know for a while that I'm trying to find a solution, but I think it would not be possible.
The problem is not from using custom settings, the problem is when someone use an output gamma curve with a low level segment different from the input gamma curve. For now, just use as output gamma the same as input gamma or, if you want it, try this:
9 4.5 0.099 0.45 0.018
For different gamma values, just change the 0.45 value for any value between [0.4, 0.5]

Note 1: performance wise, you should disable the avisynth filter and resizing in ffdshow, and do it all with madVR.

Note 2: Due to your updates, I've not answered some of the other questions.

[janos666]

I calibrated my display with sRGB tonal response curve and I used this input file for "HD - PC.3dlut":

# Source video format
Input_Video_Format HD YCbCr
Input_Bit_Depth 8

# Display video format
Output_Video_Format HD RGB_PC
Output_Bit_Depth 16

# Gamut and Gamma Conversion - settings
Chromatic_Adaptation 2
Out_Of_Gamut_Clipping 0
Output_Gamma 0
Input_YCbCr_Full_Range 0
Output_RGB_Black_White 0 255

# Gamut conversion - measured native coordinates
Output_Primaries 9 0.658 0.328 0.230 0.691 0.141 0.087 0.313 0.328

It should be perfect but it is not. But I am close to see the source of the problem. I think that cr3dlut handles this PC-TV range thing incorrectly when it also does gamma correction.
I watched Pandorum (Blu-Ray disk) some days ago with t3dlut and VRM9 (8-bit RGB table without gamma correction) and I used it to test my settings with madVR today, because this movie has a lot of dark scenes.
I can see very odd things. Sometimes I can see a very dark scene where black is true black but every black area changes to noisy gray as soon as a little light source shows up on the screen. It can render true black but any little light will push it to gray. It is a noisy gray because the little differences (between dark and dark areas) are magnified. There is a very big jump between black and the darkest gray.
I guess YCrCb=RBG looks like this: 0=0 and 1=4, 2=8, 3=16, or 0=0, 1=16, 2=17, and so on. (And dithering may help to make it more noisy.)
I tried to change it but Out_Of_Gamut_Clipping has nothing to do with this problem. The Reducing of RGB White to 235 helped a bit, but the result was far from good. The Increasing of RGB Black wont help, and negative values won't make sense here...
So I removed this gamma setting for now. Dark scenes are more natural without it.
This gamut conversion helped a lot, a more accurate gamma won't make big difference (the Rec709 tonal response curve is not far from sRGB one). But I have to live with this knowledge that it is not perfect yet. :rolleyes:

SUPPLEMENT: Sorry, I already wrote this post when I noticed your answer.
No. That's a problem that I know for a while that I'm trying to find a solution, but I think it would not be possible.
Did You try to change the order between TV->PC and source_gamma>output_gamma conversion precess? May be gamma correction should be done first.

[yesgrey]

I think that cr3dlut handles this PC-TV range thing incorrectly when it also does gamma correction.

Did You tried to change the order between TV->PC and source_gamma>output_gamma conversion precess? May be gamma correction should be done first.
Thanks for trying to help, but that's not the problem.
Currently I think the problem is related to the bit depth.
At lower levels, the 8 bit bit depth is too low for the small changes.
If we don't change the gamma curve for the low level part, there is no problem, because all the fine gradation levels are kept, but when we change the low level part of the gamma function, there is a problem, because some of the low level detail is completely lost, because some values will be coded as the same output level instead of different ones, hence the blocky images in the dark areas.
I still don't know if this can be solved with the new clipping method I am working with, but I'm afraid that it's not.
So, for now, we should always use the same gamma function for input and output. If you want, you could try changing the gamma value, as I showed you in my previous post, but not the gamma function.

[janos666]

Currently I think the problem is related to the bit depth.
At lower levels, the 8 bit bit depth is too low for the small changes.


It is not hard to imagine as soon as we are in the same interval. But I thought that the extra 16 steps (between PC and TV levels) can span this limitation. So the steps between 16 and K (during this non linear gamma function is effective) can be stretched over this 0-K interval (which is approximately 1,5-2 times wider than the original interval. - It is my guess only, I did not calculated it...)
But ok, I stop giving advices because I can not reflect my thoughts in this language and I do not have experience with this kind of transformations...

[yesgrey]

But I thought that the extra 16 steps (between PC and TV levels) can span this limitation.
No, because I think the problem only happens when you are outputting PC levels. The bit depth seems to be too low to allow the conversion... but it also could be any problem with the clipping, so without further testing is not easy to know.

But ok, I stop giving advices because I can not reflect my thoughts in this language[/COLOR]
Ideas are always welcome, help me think of what might be the reason. It's also hard for me to reflect my thoughts in this language, so just try, like I do.;)

[janos666]

No, because I think the problem only happens when you are outputting PC levels. The bit depth seems to be too low to allow the conversion...

It sounds like a proof that problem is elsewhere. I also noticed that there are no noisy gray blocks with TV output levels. Of course, it is always too bright on my PC monitor and it never hits real black but the transition between gray levels is smooth. How can it loose so much detail when it is extended to a wider interval?
May be RGB values shouldn't be extended but simply reduced by 16 in this tricky 0-0.081 interval and the remained K;235 interval should be extended to fill the (K-16);255 interval. (In this case, gamma correction should done first in the original range.)


But I am not sure if this conversion is needed or not. I found this info when I searched on the web for HDTV transfer functions:

My understanding is that Rec709 is a camera transfer function, not a display transfer function. So while the gamma curves detailed above do define the input reference of a Rec709 image, those images are then presumed to be displayed at gamma 2.2

In my understanding this document from ICC confirms this statement: http://www.color.org/sRGB.xalter The most interesting paragraph is: sRGB and ITU-R BT.709 Compatibility
It supposes to clarify the confusions but this document isn't consistent anyway. :rolleyes:
Sometimes it says:
we can solve for the ideal target monitor gamma of 2.2
It is not always clear that it speaks about the whole sRGB standard or the sRGB color-space only.
sRGB color space provides a monitor definition that can be used independently from the ITU-R BT.709 standard while maintain compatibility
But sRGB and Rec 709 have the same primaries so their compatibility shouldn't be further clarified.
And gamma 2.2, again:
In summary, there has been some concern with the choice of a 2.2 CRT gamma with a 1.0 LUT gamma as opposed to a 1.571 (2.2/1.4) or a 1.294 (2.2/1.7) display gamma. We feel that there are many reasons to support a 2.2 CRT, including;
- PC's with 256+ colors
- HDTV
- [....many more...]

The biggest conflict in this document is that the same image cannot be perfect with both sRGB and Gamma 2.2 because they are close but different tonal response curves. And it doesn't mention any color management (with gamma correction...) for HD video playback on PC. This is your "innovation".

On the other hand there are another conflicts with calibration softwares:
HCFR knows the Rec 709 (and some other) standard color spaces but it uses a reference gamma (like x^2.2) and not complex tonal response curves.
I found some information about an X-Rite software which accepts user defined gamma functions with mathematical formulas, and someone made an XML with Rec709 formulas.
Cheaper and bundle calibration softwares do not care about the sRGB curve. So a lot of people calibrate their displays with x^2.2 and working happily (Yes, working, not just watching movies. There is very few people like us who buy a colorimeter to enjoy movies...)


In my experience Blu-Ray movies looked better with gamma 2.22 than they looks now with sRGB calibration. (I am speaking about monitor calibration here...)
I can see more details in dark areas now but the whole image was sharper and more coherent for me with x^2.22 tonal response. (It applies to movies and PDF documents as well.)

[IanB]

The classic cheat for this is like sRGB does it.

Have a small linear region at the black end then change to the gamma curve. i.e.Y=[16..235] => y=[0..219] being the zero based luma values

(y<10) ? (y*2) : ((y/219)**(1/2.2)-(10/219)**(1/2.2))/(1-(10/219)**(1/2.2))*((219-10*2)/219)+10*2

2.2 being the Gamma value
10 being the size of the linear region
2 being the linear region coefficient

Example lookup values :-
In Gam Lin/Gam
0 0 0
1 19 2
2 26 4
3 31 6
4 36 8
5 39 10
6 43 12
7 46 14
8 49 16
9 51 18
10 54 21
11 56 24
12 58 27
13 61 29
14 63 32
15 65 34
16 67 36
17 69 39
18 70 41
19 72 43
20 74 45
...
58 120 100
59 121 101
60 122 102
61 122 103
62 123 104
63 124 105
...
77 136 120
78 137 121
79 138 122
80 139 123
81 139 124
...
214 217 216
215 217 217
216 218 217
217 218 218
218 219 218
219 219 219

[htpc66]

I notice that the free program MonInfo from Entech provides chromaticity co-ordinates for xyz and white points.

Wonder if someone please guide on whether those co-ordinates could be used as input primaries to generate .3dlut files? If not, what would the relevance of those chromaticity co-ordinates given by MonInfo as far as color correction is concerned?

[yesgrey]

Wonder if someone please guide on whether those co-ordinates could be used as input primaries to generate .3dlut files?
I don't know if the chromaticity coordinates are accurate, but for using them is self-explanatory. The names are the same. Rx in moninfo is rx in cr3dlut, etc., so it's just copying the values to the cr3dlut settings file.

[janos666]

I decided to recalibrate my monitor. This time I wasn't lazy and checked back the results. I used the latest MPC-HC, FFDShow and MadVR builds without any post-process filters to measure the AVCDH video test palette with Color HCFR 2.1.
Here is the animated gif with 3 CIE diagrams: monitor's native, Out_Of_Gamut_Clipping 1 and 0: click (http://img12.tar.hu/janos666/img/76100716.gif)
It was worth to check this because I thought that the default clipping 1 setting is better. And I thought that it is a little more accurate. So, I can appreciate my friend's results with his U2410 in sRGB mode. (That display uses the results of the one time factory measures to do gamut conversion and that is more accurate than this software with fresh measures.).

[yesgrey]

So, I can appreciate my friend's results with his U2410 in sRGB mode. (That display uses the results of the one time factory measures to do gamut conversion and that is more accurate than this software with fresh measures.).
That's one of the reasons I've started the new project: this wasn't good enough, it has some limitations, and I want something a lot better.;)

[tritical]

I updated the 'rgb3dlut' function of ddcc to support 3DLUT format LUT files. Even though t3dlut has all of the functionality of rgb3dlut, it doesn't have assembly versions of some of the code paths making rgb3dlut preferable in some cases. I also updated ddcc to output 3DLUT format files, and fixed a small bug in t3dlut for yuy2 input with cplaceU=0/itypeU=1. All are available at the usual place.

I'm considering writing a standalone program that would create a full 256*256*256 entry LUT for use with rgb3dlut/t3dlut/madvr from a partial subset of mappings.

[leeperry]

I'm considering writing a standalone program that would create a full 256*256*256 entry LUT for use with rgb3dlut/t3dlut/madvr from a partial subset of mappings.
A simple GUI where you could input/load/save RGBW xy coordinates and choose the output gamut for direct use within mVR would be very nice indeed :cool:

[yesgrey]

We have started a project on sourceforge to host everything related to the 3DLUT (http://thr3dlut.sourceforge.net/) file format.

When madshi find the time he will start a new thread for discussing the compression of the 3DLUT files.

@tritical
If you also want to be part of the 3DLUT project admins let me know.

[yesgrey]

I've updated 3DLUT (http://thr3dlut.sourceforge.net/)'s sourceforge project by uploading the files to the "Download 3DLUT files" area.

Sorry for any trouble, but I'm new to this and previously only have put the files in the bazaar repository.

[yesgrey]

Updated 3DLUT (http://thr3dlut.sourceforge.net/)'s project: created license file.

[Yellow_]

Would ddcc & 3DLUT improve colourspace conversion from YV12 to RGB for DSLR video, h264 over AVS's usual ConvertTORGB()? Reading through the ReadMe for ddcc it appears there are more options for control? The Rec709 v EBU looks like something that may come into play or is DSLR h264 almost certainly Rec709?

[IanB]

AVS's usual ConvertTORGB() is a linear algebraic conversion. It offers 2 sets of colour coefficients Rec.601 and Rec.709 with either PC, [0..255], or TV, [16..235], levels scaling.

Ddcc and 3DLut offer arbitrary lookup table translation from each YUV value to a RGB value. A LUT can be generated to apply any linear or non-linear function you desire. The standard LUT generator programs offer a useful selection of standard conversions profiles. You could modify the source code to generate any conceivable LUT you desire. I seem to remember some discussion about csv files and Excel as a means to generate arbitrary LUT's.

[Yellow_]

I think ddcc also offers Bicubic conversion and others, as well a linear. I believe 2.6 (development) will have Bicubic as default?

Do you think there is any benefit in that respect, in pursuing different conversions in ddcc, just for the YV12 to RGB?

Thank you for the explaination, I'll read more on 3D LUTS.

[yesgrey]

Would ddcc & 3DLUT improve colourspace conversion from YV12 to RGB for DSLR video, h264 over AVS's usual ConvertTORGB()?
If you use 16 bit 3DLUTs with t3dlut() then the quality should be better, because t3dlut dithers them to 8 bit, and I think the YV12->RGB conversion on ConvertToRGB() is performed using only 8 bit (please correct me if I'm wrong). This would avoid any banding that might be created during the conversion.

[yesgrey]

Do you think there is any benefit in that respect, in pursuing different conversions in ddcc, just for the YV12 to RGB?
For that you should take a look into t3dlut, and should use it in combination with yv12toyuy2. The chroma upsampling benefits from using the bicubic, we've tested it. However, it's just on images with very saturated reds in very dark backgrounds, so it might not be worthy the extra processing time...

[Yellow_]

yesgrey, thanks for the reply, I will look into t3dlut further, it sounds encouraging.

Is there a point in the process where 16bit can be exported out rather than dither to 8bit and do that later after grading?

With regard to saturated reds, I was looking at an example of that last night in a shot of mine from a 550D, http://blendervse.wordpress.com/2010/09/03/video-import-update/, difference between Fast_Bilinear & bicubic conversion, red / magenta on black gives a rather rough edge, where as the white on black was much smoother.

I understand that the Canon DSLR's are a bit red and can be calibrated by the user adjusting manual white balance and picture style.

http://www.hurlbutvisuals.com/blog/2010/03/30/color-correction-put-your-best-foot-forward/

[yesgrey]

yesgrey, thanks for the reply, I will look into t3dlut further, it sounds encouraging.
Be aware that t3dlut is slower than rgb3dlut because is a more generic function, but if you want more quality, and the time is not a big issue, use it instead.

Is there a point in the process where 16bit can be exported out rather than dither to 8bit and do that later after grading?
No, because we are limited by Avisynth 8 bit processing. If/When Avisynth support 16 bit processing then it might be possible.

As it is now I only see two solutions for your problem:
(1) Try to do the grading in YV12 and then convert to RGB
or
(2) Try to create a 3DLUT that not only performs the YCbCr->RGB conversion but also performs the grading.

The (1) I don't know if are there any tools available for it, but I might be able to help you with (2) if you could specify a set of changes to each of RGB channels that applies to the entire video...

[Yellow_]

yesgrey, thanks for your time. I think the best to achieve presently for me is the assumed improved YV12 to RGB conversion, I'll try it out and see.

I don't think (1) & (2) are very useable for me but thanks for suggestions.

Wilbert has a plugin called Immaav which uses ImageMagick to read but also write out 8 & 16bit to image files.

http://forum.doom9.org/showthread.php?t=135928

There's hope maybe some way of writing 16bit out via a Q16 build of IM? Although he thinks it's maybe not possible again due to AVS 8bit processing.

Anyway, very interesting processing and just improving YV12 to RGB over normal ConvertToRGB is a definite plus. :-)

[Yellow_]

I've started to give this ago, but I'm unsure as to chroma placement, left or centre? Source is progressive mpeg2 HDV and h264 in the conversion from YV12 to YUY2.

When I read through the t3dlut manual I can't find under mandatory settings a full range YCbCr 0 - 255 only 16 - 235. I'm aware most stuff is authored in that range, like BluRay, DVD etc, however I'm hoping to try the process on HD & DV vid cam source. I deliberately expose right up to hard clipping point using the waveform and histogram to gauge expsore, to get the most into the 8bit.

I'm almost certain both the camera's I use capture full range, depending on conditions. Certainly using AVS ConvertToRGB(PC.709...) gives me usable data in the headroom, not so much down below. I assume my camera sources are YCbCr, I've always used YV12 in AVS before. :-)

[poisondeathray]

I'm not sure if this is correct, but when I fidded with it , I generated a 3DLUT file from yCMS first. It's in that 3DLUT file that you can specify whatever range, and the characteristics etc...

http://forum.doom9.org/showthread.php?t=154719

Then I used t3dlut's YV12toYUY2(), and then t2dlut() with the 3DLUT file to do the RGB conversion

A while back , maybe 20 pages or so tritcal posted some comparison screenshots between the standard ConvertToRGB() vs. the other sampling methods. There was also discussion of whether left, or center is preferred.

Perhaps I wasn't doing it correctly , but my limited testing - assuming I'm doing it correctly - (along with tritical's comments) have shown it not that beneficial over the standard avisynth method ... but of course if you come to some new understanding or findings please share :)

[Yellow_]

Yeah, that's where I'm at really. I've got the AVS script sorted for the conversion except to confirm chroma placement.

Used YV12ToYUY2 from t3dlut and dropped out with AVS's ConvertToRGB and saw no difference tested against AVS's ConvertToYUY2, but hoping the whole chain via the LUT may yield better results, is that how you tested it?

The whole process I'd imagine has got to be useful coming back from RGB too after grading to delivery codec.

I've used a HD-PC template for the 3DLUT file but can't find a mandatory full range HD or SD option, so not got very far. :-(

Don't really want to get into the 'only use these settings if you know what you're doing' section of the LUT generation process.

A lot of reading to do. :-)

[yesgrey]

I've used a HD-PC template for the 3DLUT file but can't find a mandatory full range HD or SD option, so not got very far.
All HD and SD (Blu-ray, HD DVD, DVD and broadcasts) are not full range, hence the absence of such a setting from the mandatory commands. In the rare cases where it is needed, you need to use an advanced command.

Don't really want to get into the 'only use these settings if you know what you're doing' section of the LUT generation process.
You can always ask for help to achieve what you need... ;)

In your case, just add this line at the bottom of your file:
Input_Range 0 255
If you also want to guaranty full-range on the output side (the mandatory only allows the selection for RGB. YCbCr is always standard) add:
Output_Range 0 255

[Yellow_]

yesgrey,

re Input_Range 0 255 & Output_Range 0 255, that's nice and simple. :-)

I did read through the custom settings but saw mention that mandatory would overide incomplete custom choices so sort of backed off using them for now until I can understand them more, if necessary.

My other query re post #582 was that the sources are h264 and mpeg2 hdv progressive, so not sure whether it should be left or centre chroma placement.

Looking forward to trying this all out later and thank you for your time.

[yesgrey]

I did read through the custom settings but saw mention that mandatory would overide incomplete custom choices
No, you misunderstood it. What it says is that if you only use some of the advanced commands you still need to include the mandatory command in the file. As long as you put any custom commands below the mandatory commands, they will override their part of the settings.
The mandatory commands are some kind of internal scripts with default values for all the commands available.;)

My other query re post #582 was that the sources are h264 and mpeg2 hdv progressive, so not sure whether it should be left or centre chroma placement.
For H.264 is left, but for mpeg2 I don't remember. Read on avisynth's doc, there is a description of the different positions and when they apply. The problem is that some cameras use a different kind of chroma placement, so try to see which applies to your case.

Read this (http://avisynth.org/mediawiki/Sampling), it's a good place to start...

[Yellow_]

Ok, I have success and I think improvement based on one test. :-) So far.

Using t3dlut I managed to raise the number of unique colours by 23680, above the AVS ConvertToYUY2 -> ConvertToRGB. :-)

That was with bicubic coefs and set at 0.0 & 0.0

Using the defaults 0.0 & 0.5 it raised the unique colours by 25946.

Is it a fair assumption that the more unique colours generated the more resistant to grading and banding?

I've added the output frames on the blog if interested.

http://blendervse.wordpress.com/2010/09/10/ycbcr-to-rgb-by-3d-lut-via-avisynth/

Based on the full 1440x1080 .png frames, although they are just an example, is there anything else that could be done to improve general image quality of mpeg2 / h264, subjective I know, for example dealing with the blockiness, as seen in the sky, adding discreet noise, remove grain / add grain etc.

[poisondeathray]

How valid is the gimp colorcube analysis? And what does it really indicate ?

Is having more unique colors necessarily better ? e.g. if , because of the changed interploation the pixels are shifted slightly, or maybe use left instead of center, that may lead to more "unique colors", but perhaps less accurate


Is it a fair assumption that the more unique colours generated the more resistant to grading and banding?


You should test it .

For example, in other programs, you can do some levels or curves manipulations and watch the histogram along with the graded picture. It will band up more (stair steps in the histogram) with 8-bit footage compared to 8-bit footage interpolated correctly to 10-bit footage . I'm sure you can try the same thing in blender . Some programs (e.g. nuke) can take 8-bit images and work in 32-bit float then dither down to 8-bit when exporting (or you can export 32bit or 16bit images as well) , I'm not that familiar with blender or how it works internally

I doubt it will make that much of a difference (at least in terms of banding) by using using different YV12=> 8bit RGB methods . I suspect there will be zero visible difference by using avisynth converttorgb() vs. t3dlut in terms of banding because you are limited by 8-bit RGB (2^8 =256 "shades" for each channel component)

[Yellow_]

Yes, I ask the same question, but for the time being I use it as a 'measurement', it's just a statistic and my feeling is that 'proof' is in the learning process which comes with manipulating the image source and seeing what it will and won't stand. :-) It does come across as if I'm trying to proof by colour count I know. :-)

[poisondeathray]

I couldn't find any more information on it (colorcube analysis), but I did start playing with it because of another thread you mentioned it in

Just "eyeballing" the png images at various zooms , it's not a big difference (slight shift) , but not even as big as the red on black letter images earlier in the thread

In terms of grading, and actually using the images in blender - I'm still interested in seeing what comes out of your tests , please keep sharing your findings :)

[Yellow_]

How valid is the gimp colorcube analysis? And what does it really indicate ?

Is having more unique colors necessarily better ? e.g. if , because of the changed interploation the pixels are shifted slightly, or maybe use left instead of center, that may lead to more "unique colors", but perhaps less accurate


Cross posts. :-)


You should test it .

For example, in other programs, you can do some levels or curves manipulations and watch the histogram along with the graded picture. It will band up more (stair steps in the histogram) with 8-bit footage compared to 8-bit footage interpolated correctly to 10-bit footage . I'm sure you can try the same thing in blender . Some programs (e.g. nuke) can take 8-bit images and work in 32-bit float then dither down to 8-bit when exporting (or you can export 32bit or 16bit images as well) , I'm not that familiar with blender or how it works internally

Blender works 32bit float internally and has basic colour management that is just sRGB and Linear at the moment, but next iteration will probably be 3D LUT based rather than hardcoded as it is now, also possible to export DPX (gamma encoded and log) and OpenEXR (multilayer , linear too). All image imports are converted to linear colour space and all compositing / lighting / rendering calculations are done in linear colour space. OpenCL is beginning to appear for the compositing pipeline as a GSOC project, so 3 way colour correct, curves etc hopefully soon to be GPU accelerated.

I doubt it will make that much of a difference (at least in terms of banding) by using using different YV12=> 8bit RGB methods . I suspect there will be zero visible difference by using avisynth converttorgb() vs. t3dlut in terms of banding because you are limited by 8-bit RGB (2^8 =256 "shades" for each channel component)

Yes, more tests needed and thanks for the encouragement. :-)

[Dogway]

There's something strange on some png's I exported from Final Cut, they look clearer on avisynth and the default Windows Viewer, than some other applications like Photoshop, or Nuke, being the latter the correct look.
I dont understand why this happens, its 1080pixels and I have a calibrated monitor with its profile.

1Mb Sendspace rar:
(I pack the image so no color conversion is made upon browser.)
http://www.sendspace.com/file/lwh4rl

Actually it looks just if I disabled proof->monitorRGB on photoshop thus ignoring my monitor profile.

[Dogway]

Someone please?

[cretindesalpes]

Your PNG has a gamma correction profile attached, which interpretation may vary, depending on the displaying application. Use TweakPNG (http://entropymine.com/jason/tweakpng/) to remove it manually. FFmpeg will also work fine for batch conversion.

[Dogway]

Didnt notice the answer, yes I found out there was a gamma issue, and by some heavy thinking decided to tweak gamma by 1.25 to accomplish the desired 2.2, (1.8*1.25=2.2). That makes my image clearer, and then it shows a more natural look with more tonal range and hue shifts. But as you suggested I just used TweakPNG and corrected the internal 0.555 gamma to 0.454 and what I get is the darker version. So now I dont know where my logic goes.

Or maybe the internal gamma correction of 0.555 is correct and the software showing the clearer version are doing the proper thing because they are profile aware(?), in which case I dont need to do anything?

[Yellow_]

@Dogway, what are you trying to achieve? or are you sorted now?

[Dogway]

Kind of. Im color grading that footage, just want to be sure Im working in the original/tonal range of the source.

What I have are a png sequence and a prores encoded video footage.

-The pngs at first glance are darker, only avisynth and the default windows image viewer read the built in 0.555 gamma correction thus clearing up the image.
-The video footage is already clear, I think because no yuv->rgb conversion was done.

So Im assuming the clearer version is the correct, and will work better with the yuv source because it has a wider tonal range to begin with. I already converted the video source to png (yuv->rgb) through avisynth and grading in Nuke with that. Just correct me if Im wrong.

[Yellow_]

Ok, I don't quite get it? Why gamma correction from FCP to png's?

Are you trying to linearize your png's, with a reverse gamma correction?

It's straightforward to export png's from ProRes with AVISynth using the latest QTSource plugin.

Your frame image looks like it's had the levels messed with, the histogram looks rough. It doesn't look like it's been cleanly converted from the original.

[Dogway]

Yes, that's what I did, exported from Prores to png in avisynth.
You're true, good idea the levels thing, yes, it looks tweaked. What further confirms the clearer version is the correct. Don't ask me why gamma correction from FCP to png, I don't use that program, so I just wanted to hint what the embedded 0.555 gamma thing on the png meant and choosing the right one to grade on Nuke.

[Yellow_]

@Dogway, I understand now. :-)

yesgrey, if you're still about, is it possible to use yCMS to create a LUT that does this, the way Cineform handles levels, quoted by Cineform:

"Downstream tools generally don't handle full range YUV well, so we take the 0-255 input, bump that to 10-bit 0-1023, then range correct to 64-940, compressing the results. So we made a standard range YUV without clipping, and without loss of codewords as we bumped to 10-bit first. This greatly simplifies YUV playback or HDSDI/HDMI devices."

I'm aware yCMS can do the work in 16bit, then dither down to 8bit and input and output levels can be specified. So is it possible to do the above at 16bit?

Also I find out that Canon DSLR video is BT601 not 709, so should I use YCbCr or HD or PAL or specify 601 for primaries and colour coefficients when going to RGB?

Cheers

[yesgrey]

"Downstream tools generally don't handle full range YUV well, so we take the 0-255 input, bump that to 10-bit 0-1023, then range correct to 64-940, compressing the results. So we made a standard range YUV without clipping, and without loss of codewords as we bumped to 10-bit first. This greatly simplifies YUV playback or HDSDI/HDMI devices."
yCMS already does better than that. It takes the 0-255 input, converts that to 64 bit fp 0.0-1.0, then range correct according to specified output bit depth, which could be 8bit or 16bit. If you use 16bit it would be better than the above.

I'm aware yCMS can do the work in 16bit, then dither down to 8bit and input and output levels can be specified. So is it possible to do the above at 16bit?
yCMS never uses dithering, because it only creates the 3DLUT file. Dithering should be used only when reducing the bit depth for the processed streams/images, not for the 3DLUT. What you're referring is the t3dlut working mode, and that I'm afraid could not be changed, because Avisynth is limited to 8 bit processing. So, it's not a yCMS limitation, but Avisynth's. However, by dithering from 16 bit to 8 bit the compression would not be a problem, only a slightly higher noise level on the images,

Also I find out that Canon DSLR video is BT601 not 709, so should I use YCbCr or HD or PAL or specify 601 for primaries and colour coefficients when going to RGB?
You should select PAL, if you're from PAL land, or NTSC, if you're from NTSC land.

[Yellow_]

yesgrey, thanks for the clarifications, my bad with regard to 8bit 16bit in yCMS, not dither but range correct, dithering in t3dlut.

Thanks for the tool, it's excellent.

[yesgrey]

not dither but range correct
Yes, you can do range correct in yCMS. I decided to use only values between 0-255 to simplify the interface, because it's easier to think that we will convert 0-255 -> 16-235. However, the accurate range values are calculated internally. So, if you select 16-235 as output, but you're using a 16 bit bit-depth, the real output range values would be 4096-60160.

[Yellow_]

Just to clarify.

For doing 601 full range PAL to 8bit RGB:

Input_Format PAL YCbCr 8
Output_Format PAL RGB_PC 16

Gives me a LUT suitable for taking 0 - 255 and 'squashing' into 16 - 235 out

Substituting 'PAL' for 'HD' would give me a LUT suitable for the same but with for example HDV video camera sources?

Adding the line 'Output_Range 0 255' to either would give me full range output in either PAL or HD?

Is it as simple as that, no other parameters?

[yesgrey]

For doing 601 full range PAL to 8bit RGB:

Input_Format PAL YCbCr 8
Output_Format PAL RGB_PC 16

Gives me a LUT suitable for taking 0 - 255 and 'squashing' into 16 - 235 out
No.

When using the mandatory commands (Input/Output_Format) YCbCr is always considered to be within the standard range:
Y: 16-235
CbCr: 16-240

For full range you should add the line:
Input_Range 0 255

And for 'squashing' to 16-235 you should add this other line:
Output_Range 16 235

Substituting 'PAL' for 'HD' would give me a LUT suitable for the same but with for example HDV video camera sources?
Only if the 3DLUT's are meant to 'squash' the sources and keep the video format. If you will use them for watching the files then you should set as output format your display's video standard, and not the same as the source.

[Yellow_]

Thanks again yesgrey.

Considering that the Canon DSLR is BT601 but HD. Then really I should use the transfer function to 709 as well when going to an intermediate file for editing and reencoding?

Just thinking about final playback, aiming for widest compatibility with playback devices, should I really be encoding HD size material with 709, I assume that's what players will expect, or is 601/709 flagged in the encoding added by the encoder, say with x264.

I've read players are renowned for doing there own thing, but as best practice, 709?

[yesgrey]

Considering that the Canon DSLR is BT601 but HD. Then really I should use the transfer function to 709 as well when going to an intermediate file for editing and reencoding?
What do you mean with "Canon DSLR is BT601 but HD". Are you referring to the primaries, the transfer function, or the encoding matrix?
The transfer function is not a problem, because it's the same in both BT.601 and BT.709. The differences between them are the encoding matrices and the primaries.

Just thinking about final playback, aiming for widest compatibility with playback devices, should I really be encoding HD size material with 709, I assume that's what players will expect
Yes. According to what I've read everywhere, the players and TV sets use BT.709 when they detect a HD signal. It might happen that some equipments don't, but that's the exception (manufacturer mistake) and not the rule.

[Yellow_]

What do you mean with "Canon DSLR is BT601 but HD". Are you referring to the primaries, the transfer function, or the encoding matrix?
The transfer function is not a problem, because it's the same in both BT.601 and BT.709. The differences between them are the encoding matrices and the primaries.

Whether it's colour primaries or matrix, I'm unsure, all i know is that 601 is said to be "flagged in the bitstream"? FFMPEG for example reads Canon 7D and 550D DSLR video as 601 where as HDV video from my other vidcam is read as 709.

[yesgrey]

That's strange... I've googled a bit about those two models and I saw no reference whether it's PAL or NTSC, so it would be very strange if the cameras use BT.709 primaries and BT.601 encoding matrix... Did you see any reference to PAL or NTSC in the user manuals?

[poisondeathray]

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M


This is the mediainfo metadata for the 7D, it's the same for 5D MK2

[yesgrey]

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
For characterizing this source in yCMS it should be used:

Input_Format HD YCbCr 8
Input_Matrix_Coefficients 3

if you prefer a simpler form, or

Input_Primaries 0
Input_Transfer_Function 1
Input_Matrix_Coefficients 3
Input_Bit_Depth 8
Input_Range 16 235

if you prefer the advanced/detailed form.

[Yellow_]

Thanks guys. I've now installed Mediainfo, a fine tool. Canon 550D/T2i is same as 7D & 5D mkII. All sources are PAL.

Prefer the advanced / detailed form for yCMS. :-)

So, for example, using the detailed form above gives me suitably 'decoded', colourmetrics 'neutral' source which I can then use to go to full range RGB using RGB_PC 16 and / or Output_Range 0 255 and then from that RGB intermediate to whatever, 601, 709 just using matrix co efs without the need for transfer function?

Looking at some HD encoded files done previously from edits and also source mpeg2 from a HDV cam, mediainfo just lists colormetry as 4:2:0, assume then these are not flagged sufficiently, so does that become more of a lottery at playback, as to what colourmetrics the player uses, perhaps based on frame size/pixel count where colourmetrics are not flagged?

Thanks for your patience with this, it must quite frustrating. :-)

[yesgrey]

Thanks guys. I've now installed Mediainfo, a fine tool. Canon 550D/T2i is same as 7D & 5D mkII. All sources are PAL.
If it's the same as above it can't be PAL, it has different primaries.

Prefer the advanced / detailed form for yCMS.
Me too, but I'm suspect.;)

So, for example, using the detailed form above gives me suitably 'decoded', colourmetrics 'neutral' source which I can then use to go to full range RGB using RGB_PC 16 and / or Output_Range 0 255 and then from that RGB intermediate to whatever, 601, 709 just using matrix co efs without the need for transfer function?
RGB_PC assumes always full range (0 255), so you won't need to use the Output_Range command. Of course you could also use the advanced/detailed form for the output, you just need to know what you want to get.

The RGB intermediate only makes sense if you plan to process the image in RGB, but then, if you want to output as YCbCr, you would need to use another 3DLUT for performing the RGB->YCbCr conversion. Is that your intention?

Looking at some HD encoded files done previously from edits and also source mpeg2 from a HDV cam, mediainfo just lists colormetry as 4:2:0, assume then these are not flagged sufficiently, so does that become more of a lottery at playback, as to what colourmetrics the player uses, perhaps based on frame size/pixel count where colourmetrics are not flagged?
If you know which camera was used for the capture you could try to know, otherwise it's safer to stick to the standards. Another option would be using the standard and the other and decide which look best.

[Yellow_]

If it's the same as above it can't be PAL, it has different primaries.

I'll check again. The 550D/T2i does both PAL & NTSC, but I use it mainly on PAL, just NTSC to get the 60fps for slow mo. (720P)

The RGB intermediate only makes sense if you plan to process the image in RGB,

Unfortuneatley the NLE / Compositor / 3D app I use stuffs up video sources with regard to levels and colourmetrics, (FFMPEG based) as it works solely in RGB. So I prefer to do a controlled conversion with AVISynth, then finally encode back to video for final delivery. Also want to maintain full range levels in editing / grading then squash 16 - 235 for final delivery.

but then, if you want to output as YCbCr, you would need to use another 3DLUT for performing the RGB->YCbCr conversion. Is that your intention?

Yes, I've used ConvertToYUY2 or YV12. However since finding yCMS + t3dlut I've created some 'Output' LUTS via yCMS instead which include 16 - 235 levels. I assume encoders don't provide method to set levels, generally just pass what they get through?

If you know which camera was used for the capture you could try to know, otherwise it's safer to stick to the standards. Another option would be using the standard and the other and decide which look best.

The 4:2:0 files are from a Canon HV30 HDV cam and the other 4:2:0 files are generally XVid and h264 final encodes that don't flag colourmetrics I guess.

Thanks again.

[Yellow_]

Check mediainfo and get this for 550D videos:

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

The camera is set to it's PAL mode as opposed to NTSC. Whether that's strictly to spec I don't know.

[yesgrey]

The BT.709 primaries are not much different from the PAL primaries, only the green changes, and it's a very small change, so the effect would not be significant. What's more important is using the right matrix, and that it does. However, due to the slight difference of the green primary it would not follow exactly the standards.
Just FYI the PAL's green coordinates are: 0.2900, 0.6000, while BT.709's are 0.3000, 0.6000 .

Just for curiosity, what do you get when the camera is set to NTSC mode?

[Yellow_]

What's more important is using the right matrix, and that it does.

You mentioned in an earlier post that it would be strange for the camera to use 709 primaries and 601 matrix. But above that it uses the correct matrix, ie: 601?

Just for curiosity, what do you get when the camera is set to NTSC mode?

Mediainfo gives exact same for NTSC mode from camera.

Assume th mix of primaries and matrix, increases chances of apps misjudging how to handle it? For example FFMPEG suggests 601?

I see variations in different apps with regard to brightness (assume levels stretching there) and colour hue mainly a difference in red. One app will show something of reddish colour more orange, generally when using 709 and the same source with a definite pink hue instead of orange, generally when using 601.

There's much 'folk law' about Canon being on the 'red' side, wonder how much that is to do with camera settings (I use Neutral profile and knocked magenta down a bit in custom white balance) or assuming incorrect colour primaries 601 instead of 709, would that make any real difference I wonder?

Lightworks NLE goes Free as Open Source on the 29th and offers handling of DSLR sources + GPU effects and playback/editing without transcoding to DNxHD or similar first. Time will tell how successful that is. Which may or may not result in a second workflow, other than the RGB one, staying YCbCr. I think there are still benefits to using your LUT + td3lut for precision and eeking most out. Many advocate Cineform products for similar reasons, high precision, upsampling and more lightweight codec.

Considering whether it's beneficial to decode the Canon sources as we've discussed 709 primaries & 601 matrix and put them into 709 and use a lossless codec like UT / lossless h264 / Matrox I Frame ? Sort of a 'poor mans' Neoscene. :-) Or maybe better?

[yesgrey]

You mentioned in an earlier post that it would be strange for the camera to use 709 primaries and 601 matrix. But above that it uses the correct matrix, ie: 601?
Yes, but I did not remember that BT.709 and PAL primaries are almost the same. Yes, it uses the correct matrix.

Mediainfo gives exact same for NTSC mode from camera.
With NTSC it would not be that good... Look at all the primaries (R;G;B):
BT.709: 0.6400, 0.3300; 0.3000, 0.6000; 0.1500, 0.0600
PAL: 0.6400, 0.3300; 0.2900, 0.6000; 0.1500, 0.0600
NTSC: 0.6300, 0.3400; 0.3100, 0.5950; 0.1550, 0.0700

There's much 'folk law' about Canon being on the 'red' side... or assuming incorrect colour primaries 601 instead of 709, would that make any real difference I wonder?
It might be from the primaries... If you compare the Red coordinates from above you could see that the NTSC Red is more saturated than the BT.709 one. If you capture using BT.709 and then process assuming NTSC the end result might be just that... To be sure you would need to process the same file considering both options and compare.

Assume th mix of primaries and matrix, increases chances of apps misjudging how to handle it? For example FFMPEG suggests 601?
Ideally you should use all correct parameters, but considering not all applications allow the selection of the primaries at least choose the right coefficients matrix.

Considering whether it's beneficial to decode the Canon sources as we've discussed 709 primaries & 601 matrix and put them into 709 and use a lossless codec like UT / lossless h264 / Matrox I Frame ? Sort of a 'poor mans' Neoscene. :-) Or maybe better?
I can't help you on that. I'm not in the editing area, so I really don't know the results...

[Yellow_]

yesgrey, I really appreciate your continued replies.

In trying to read around the subject and try to get a better understanding I found info on xvYCC, http://en.wikipedia.org/wiki/XvYCC and stated there:

xvYCC-encoded video retains the same color primaries and white point as BT.709, and uses either a BT.601 or BT.709 RGB-to-YCC conversion matrix and encoding. This allows it to travel through existing digital YCC data paths, and any colors within the normal gamut will be compatible.

Which sounds like what the Canon DSLR is doing? It's h264 AVC.

Although it suggests for final output:

xvYCC is not supported by DVD-Video or Blu-ray, but is supported by the high-definition recording format AVCHD and PlayStation 3.

However when reading about AVCHD it is suggested it is compatible and designed for Blu-ray, I assume there are various profiles and the higher end of AVCHD accommodate the xvYCC gamut?

Is it possible to use a LUT and retain the xvYCC data in an intermediate for grading / image manipulation and then encoding out to a lesser gamut like 709 or 601?.

Would it need to be as RGB? maybe described in a wider colourspace than sRGB, AdobeRGB perhaps? I see yCMS includes an AdobeRGB output option.

[Yellow_]

yesgrey, could you clarify whether I have this right:

Source is 709 primaries, 601 matrix. Want to convert to 709 primaries and matrix and export from Vdub as uncompressed YCbCr HD. The bit I'm unsure about is the need for the Output transfer matrix or not required?

# Set input format


Input_Primaries 0

Input_Transfer_Function 1

Input_Matrix_Coefficients 3

Input_Bit_Depth 8

Input_Range 0 255



# Set output format



Output_Primaries 0

Output_Transfer_Function 0

Output_Matrix_Coefficients 1

Output_Bit_Depth 16

Output_Range 0 255

re Adobe RGB & xvYCC query from previous post, when converting using 709 pri and 601 matrix to AdobeRGB, I get less colour info per frame using AdobeRGB than sRGB, I'm ensuring that Gimp uses the correct ICC under colour management for importing the image frames, I'd assumed I see better colour info per frame, ie: wider gamut.

For AdobeRGB I was using the same input details as above with these outputs:

Output_Primaries 4

Output_Transfer_Function 5

Output_Matrix_Coefficients 0

Output_Bit_Depth 16

Output_Range 0 255

Does all look correct for generating the LUT's?

[yesgrey]

Source is 709 primaries, 601 matrix. Want to convert to 709 primaries and matrix and export from Vdub as uncompressed YCbCr HD.
# Set input format
Input_Primaries 0
Input_Transfer_Function 1
Input_Matrix_Coefficients 3
Input_Bit_Depth 8
Input_Range 0 255

# Set output format
Output_Primaries 0
Output_Transfer_Function 0
Output_Matrix_Coefficients 1
Output_Bit_Depth 16
Output_Range 0 255

Almost correct. You shouldn't change the TF. You should use:
Output_Transfer_Function 1

If you're not using any of the mandatory commands you must use all STANDARDS DEFINITION commands for input and output.

re Adobe RGB & xvYCC query from previous post, when converting using 709 pri and 601 matrix to AdobeRGB, I get less colour info per frame using AdobeRGB than sRGB, I'm ensuring that Gimp uses the correct ICC under colour management for importing the image frames, I'd assumed I see better colour info per frame, ie: wider gamut.

For AdobeRGB I was using the same input details as above with these outputs:
Is your source full range YCbCr? If not, try using:
Input_Range 16 235

[diffid]

Post removed, wrong thread.

[Yellow_]

Almost correct. You shouldn't change the TF. You should use:
Output_Transfer_Function 1

If you're not using any of the mandatory commands you must use all STANDARDS DEFINITION commands for input and output.

Just to clarify, I have missed the mandatory? So should add:

Input_Format HD YCbCr 8 & Output_Format HD YCbCr 8

When you say almost correct, which is almost correct the 709pri /601 matrix to 709 or the AdobeRGB route? Obviously I want to get the LUTs right before using them on a full project. :-)

If I'm for example going from 709 pri / 601 matrix to 709 for both, then will either YCbCr or HD work the same in Output_Format? Which would be correct?

Is your source full range YCbCr? If not, try using:
Input_Range 16 235

Yes always full range from the cameras I'm using. But if I haven't been doing the LUT generation correctly for these latest tests then that might explain the AdobeRGB problem. :-)

[yesgrey]

Just to clarify, I have missed the mandatory? So should add:
Input_Format HD YCbCr 8 & Output_Format HD YCbCr 8
If you're using all STANDARDS DEFINITION commands the mandatory lose their mandatory state, so, no, you don't need to add those two lines. If you miss any command yCMS would let you know, because it never assumes any default values.

When you say almost correct, which is almost correct the 709pri /601 matrix to 709 or the AdobeRGB route?
The first. You were using the sRGB transfer function (0) instead of the BT.601/BT.709 one (1). The AdobeRGB route is correct.

If I'm for example going from 709 pri / 601 matrix to 709 for both, then will either YCbCr or HD work the same in Output_Format? Which would be correct?
If you are comfortable in using the standards definition commands stick to them. The mandatory always consider YCbCr to be in the standard range, so it's safer for you to have full control on the Input and Output settings.

Yes always full range from the cameras I'm using. But if I haven't been doing the LUT generation correctly for these latest tests then that might explain the AdobeRGB problem. :-)
Right. Let me know the results with the correct LUTs then.

[Yellow_]

Right. Let me know the results with the correct LUTs then.

Ok, I've been trying to establish whether Canon DSLR h264 with 709 priimaries / 609 matrix is xvYCC and whether it is more beneficial to try putting that into a wider RGB gamut than sRGB.

My assumptions to establish either way are:

That sRGB is not sufficient for conversion from xvYCC to RGB and hold all data. ie enough for 709 primaries and matrix, but not xvYCC.

That a wider gamut like AdobeRGB would be needed.

However using the following spec for the 3DLUT:

# Set input format

Input_Primaries 0

Input_Transfer_Function 1

Input_Matrix_Coefficients 3

Input_Bit_Depth 8

Input_Range 0 255


# Set output format

Output_Primaries 4

Output_Transfer_Function 5

Output_Matrix_Coefficients 0

Output_Bit_Depth 16

Output_Range 0 255


Gives me far less unique colours in the exported image frames, (using .tif and reading in Gimp with assumed ICC profile AdobeRGB) than exactly the same process and t3dlut settings.


The sRGB LUT used the same LUT config but substituting sRGB instead and reading the images with an sRGB ICC profile.

# Set input format

Input_Primaries 0

Input_Transfer_Function 1

Input_Matrix_Coefficients 3

Input_Bit_Depth 8

Input_Range 0 255


# Set output format

Output_Primaries 0

Output_Transfer_Function 0

Output_Matrix_Coefficients 0

Output_Bit_Depth 16

Output_Range 0 255

I've tried different methods of wrting the frames out, copy to clip in Vdub, image seq out in Vdub, imagewriter to tif in AVISynth and even Wilberts Imagemagick write to tif, all AdobeRGB ICC images are identical output and far less colours than the sRGB ones. :-(

Are my assumptions about xvYCC totally wrong or is the LUT config still not right?

[yesgrey]

Are my assumptions about xvYCC totally wrong or is the LUT config still not right?
yCMS does not support xvYCC colorspace yet, so that might be the reason for your current results. I plan to support it, but I don't know when.

[Yellow_]

lol yep that could be it. :-)

Oh well, thanks for your time and I'll look out occasionally in case you feel the urge to add support. :-)

[yesgrey]

I'll look out occasionally in case you feel the urge to add support. :-)
I guess I haven't expressed myself clearly enough...

It's not a question of feeling the urge for to add support, is because I don't have the xvYCC standard's documentation. So, until I could be able to access reliable information about it I could not do it. For the current supported formats the specs are widely spread, but for xvYCC I don't.

If you have it let me know and I will consider it soon.;)

[Yellow_]

Sorry for misunderstanding, urge was really wrong word anyway, time and resources.

I'll see what I can find, maybe others on Doom9 may shout out.

Don't want to provide links to what might not be 'reliable', it is Sony after all, but here's a link.

http://www.sony.net/SonyInfo/technology/technology/theme/xvycc_02.html

KMO offers two links in the bottom of first post here and a test pattern in second post. I think you are a part time resident at avsforum anyway. :-)

http://www.avsforum.com/avs-vb/showthread.php?t=1170632

And Neuron2s site for h264AVC additional info:

http://www.avsforum.com/avs-vb/showthread.php?p=17051065#post17051065

I'll try to find written, ratified, for purchase doc if necessary.

Thanks

[yesgrey]

Thanks for the links.

I've also searched in the documents I have and I think I have all the info needed. If it's not too much work I will try to add xvYCC support to yCMS v1.9.

[Yellow_]

Hey, that's good news.

I notice the one link I gave above to avsforum, Neuron2's site needs a password, Neuron2's suggested you PM him at his site if you'd like access.

[yesgrey]

OK, thanks.

[Yellow_]

Hi, I'm unable to eek out anymore from the Canon DSLR video source using xvYCC, maybe the camera doesn't record it. :-( Although from what I've read it appears to be an extension of ITU601 and ITU709 where the range 1 to 254 is used so assumed the camera was xvYCC as I can capture above and below 16 - 235, especially with a flatter picture style camera curve.

Did you see anything / were successful with the gold source?

Sorry to ask again but with the following header info from the camera .mov files:

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

I've tried various combinations of settings to generate the LUT. If I want full range RGB from the above source which is 0 - 255 what settings would I need again if I want to assume the source is xvYCC.

Also will using 16bit output dithered down skew the results, been using 8bit out only anyway.

And last query :-), Do you think when going to RGB via the LUT, AdobeRGB or sRGB?

[yesgrey]

Hi, I'm unable to eek out anymore from the Canon DSLR video source using xvYCC, maybe the camera doesn't record it. :-(
That's what I thought too. The Gold sample seems to have the same number of available colors when using BT.709 or xvYCC.

I've tried various combinations of settings to generate the LUT. If I want full range RGB from the above source which is 0 - 255 what settings would I need again if I want to assume the source is xvYCC.
With that you can go as simple as:
Input_Format xvYCC_SD YCbCr 8
Output_Format videoStandard RGB_PC 16

on the Output format use as videoStandard the RGB space you want.

Also will using 16bit output dithered down skew the results, been using 8bit out only anyway.
Using the 16 bit output dithered to 8 bit is always preferable, unless you plan to compress the source, but since you're talking about RGB space I don't think you are considering any compression...

[yesgrey]

Do you think when going to RGB via the LUT, AdobeRGB or sRGB?
If your display supports AdobeRGB it would be preferable. It's always a good idea to use the widest color gamut supported by the display.

[Yellow_]

In your Config above you've used SD rather than HD is that deliberate ie because the transfer is BT601?

I wonder whether the cameras 'Picture Style' camera curves play a part? Would the curve be applied in the conversion from linear to gamma encoded I wonder, could that reduce the chances of seeing xvYCC? More testing I think. :-)

I don't think the curve styles affect actual captured range ie 0 - 255 but only colour content.

However I think I used 'Faithful' for the Gold source as I had the thought in mind then. I also use the Marvel Styles that emulate a LOG space.

Whats peoples general opinion of camera curves here I wonder?

Also about colour gamut, the app I'm using is linear RGB is that a wide gamut compared to AdobeRGB or does gamut not apply to liear space?

Would it be worth transforming to linear RGB or detrimental many apps appear to do all processing in linear space such as Nuke and AE.

[yesgrey]

In your Config above you've used SD rather than HD is that deliberate ie because the transfer is BT601?
Yes. According to the spec the BT.601 coefficients matrix is to be used with SD and the BT.709 with HD, hence why I named them like I did. I think it's more user friendly than xvYCC601 and xvYCC709.;)

I wonder whether the cameras 'Picture Style' camera curves play a part?
Sorry, but I don't know what you're referring to...

Also about colour gamut, the app I'm using is linear RGB is that a wide gamut compared to AdobeRGB or does gamut not apply to liear space?
The colour gamut depends on the RGB primaries only. Being linear or non linear doesn't matter, the colour gamut would be exactly the same. You need to know which are the primaries coordinates of the linear RGB space the application works with.

Would it be worth transforming to linear RGB or detrimental many apps appear to do all processing in linear space such as Nuke and AE.
If the application could accept the 16 bit output of the 3DLUT, then it might be beneficial, but if it only accepts 8 bit I think you should go with a non linear output, and let the application perform the linearisation itself.

[zcream]

A Q about xvYCC. For this extended color gamut, do we need YUV 10-bit 4:2:2 ?
The HDC-SD9 advertises xvYCC output via HDMI.
However, every other camcorder I have seen gives 8-bit YUV 4:2:2 via HDMI. For greater color depth would we need to go from 8-bit to 10-bit HDMI ?

[yesgrey]

A Q about xvYCC. For this extended color gamut, do we need YUV 10-bit 4:2:2 ?
No. xvYCC is an extension of BT.709, so it's still 8-bit. The gamut extension is achieved by using the CbCr values of 1-15 and 241-254.

[zcream]

So, if I use a HDMI capture card to get lossless 8-bit 4:2:2 data, do I need to do something to map the extra data ?
I would assume that it gets recorded normally.

[yesgrey]

So, if I use a HDMI capture card to get lossless 8-bit 4:2:2 data, do I need to do something to map the extra data ?
I would assume that it gets recorded normally.
Sorry, but I don't quite understand what you are intending...

[zcream]

Hi! Chroma is usually 16-240 for YUV video. For xvYCC it is 0-255. My question related to capturing this signal via HDMI. If I use a video capture program like VirtualDub, does it capture the extra chroma values for chroma ?

Problem is that a HDMI capture card outputs HDYC, which is then converted to RGB24 (as the video preview is seen on the monitor), then it is converted to YUV 4:2:2 for capture.
The extra chroma values would give a negative RGB value, so I would think they get thrown away.

[Yellow_]

Hi! Chroma is usually 16-240 for YUV video. For xvYCC it is 0-255. My question related to capturing this signal via HDMI. If I use a video capture program like VirtualDub, does it capture the extra chroma values for chroma ?

If your camera captures outside the 16-240 range as most do, certainly my Canon DSLR, HV30 & old JVC DV do then you have access to both. But just how much is xvYCC data is the thing. :-)

f your NLE or whatever is strictly 16 - 240 then you'll loose the rest and I think it's the case that if you're NLE or whatever works above 8bit processing(ie 10, 16 or 32bit) then they may well allow a full range workflow holding onto whatever extra that may have been captured.

Problem is that a HDMI capture card outputs HDYC, which is then converted to RGB24 (as the video preview is seen on the monitor), then it is converted to YUV 4:2:2 for capture.
The extra chroma values would give a negative RGB value, so I would think they get thrown away.

From what I've found so far doing xvYCC / full range to R'G'B is that out of the potential far wider gamut that xvYCC is said to have by the time the 4:2:0 subsampling has been done there is I think only the potential for 2.75million colors to be utilised out of the 16million and therefore where I thought I needed to use AdobeRGB or some other wide gamut profile to work with xvYCC converted to R'G'B I don't think it's necessary. :-) However if it were possible to capture 4:2:2 or 4:4:4 then something bigger than sRGB gamut might be needed I guess?

To eek out most there maybe some more to find using certain 'picture profiles' to pack more values in, possibly. Shoot Neutral or with Marvels profile but wonder whether a vivid maybe better for xvYCC?


Which leads me onto a couple of questions. I think I know the reason why I'm seeing no more colour values than before the xvYCC addition to yCMS. Here my thinking to be put right. :-)

Normal NLE handling would be 16 - 235/240 in 8bit processing, The conversion to RGB by taking reference black as 16 and reference white as 235 and putting them on that 0 1 abstract scale. To my understanding that is Rec709 to R'G'B. sRGB.

What I've been doing is using the full range because the camera captures it and in AVISynth using PC.709 as the matrix and yesgrey's yCMS with Full Range Input/Output, getting all the range and putting it in R'G'B so already doing a xvYCC conversion to R'G'B.

Which raises the question about the abstract scale, the conversion to R'G'B and handling there on in an NLE.

If an NLE only extracts 16 - 235/240 and puts it on that 1 0 scale and applies 8bit processing, I make the distinction because I think that 10,16 or 32bit and that it's float, is required for holding onto the negative values and values over 1 ie xvYCC. Then applies colour processing on a 0 1 scale set to 0 to 255 that would be incorrect handling unless they had used the full range in a bit depth greater than 8bit in the initial YCbCr to R'G'B conversion or I guess this is why they scale 16 - 235 to 0 - 255 for R'G'B processing in 8bit thus staying inside the supposed 'legal' boundaries for video?

[yesgrey]

Hi! Chroma is usually 16-240 for YUV video. For xvYCC it is 0-255.
Not quite. For xvYCC is 1-254. The 0 and 255 values should not be used with video data.

Problem is that a HDMI capture card outputs HDYC, which is then converted to RGB24 (as the video preview is seen on the monitor), then it is converted to YUV 4:2:2 for capture.
The extra chroma values would give a negative RGB value, so I would think they get thrown away.
I think it would be easier if you tell me which HDMI capture card are you thinking of (post a link, please)...

[yesgrey]

From what I've found so far doing xvYCC / full range to R'G'B is that out of the potential far wider gamut that xvYCC is said to have by the time the 4:2:0 subsampling has been done there is I think only the potential for 2.75million colors to be utilised out of the 16million and therefore where I thought I needed to use AdobeRGB or some other wide gamut profile to work with xvYCC converted to R'G'B I don't think it's necessary. :-) However if it were possible to capture 4:2:2 or 4:4:4 then something bigger than sRGB gamut might be needed I guess?
4:2:0, 4:2:2 and 4:4:4 have nothing to do with the number of available colors. In all the modes you will have the same number of available colors. The difference between them is the color resolution of an image. With 4:4:4 the chroma and luminance resolutions are the same. With 4:2:2 the chroma is half the resolution of the Luminance, and with 4:2:0 it's 1/4.

I will not comment any of the other parts of your post because it's very hard to understand what you are trying to say. Sorry.

[zcream]

Hi
I am using the Blackmagic intensity capture card.
http://www.blackmagic-design.com/products/intensity/

The colorspace output by the card was discussed here, and a special build of Huffyuv created.
http://forums.virtualdub.org/index.php?act=ST&f=6&t=16116&#entry66552

We did a test posted at vimeo
http://vimeo.com/10174263 - Comparison of Blackmagic MJPEG and Huffyv colorspace on Vimeo
We played out a SMPTE color bar from a 5d Mark II. It was ingested with a BM Intensity card using Virtualdub. There were 2 files, a special Huffyuv build for HDYC and the default BM MJPEG. As you scroll through the video it can be seen that the colorspace changes when Huffyuv records. This is a confirmation of the problem first noticed at
etfinder.net/capturepics/

To my knowledge, only AMV2-MT and Cineform handle the color conversion properly to capture a direct feed.



Not quite. For xvYCC is 1-254. The 0 and 255 values should not be used with video data.


I think it would be easier if you tell me which HDMI capture card are you thinking of (post a link, please)...

[Yellow_]

yesgrey, here again. :-)

I've started to read up on DCP (Digital Cinema Package).

http://reduser.net/forum/showthread.php?t=33118

Open Source route:

https://github.com/wolfgangw/digital_cinema_tools/wiki/Open-source-tools-for-a-digital-cinema-pipeline

Part of the process is getting from sRGB to X’Y’Z’ (Gamma 2.6) however my interest is from Canon DSLR YCbCr 1 - 254 xvYCC to X’Y’Z’ (Gamma 2.6) and then output Jpeg2000 image sequences via Wilberts Imagemagick AVISynth plugin.

What would be involved in getting a 3D LUT created to X’Y’Z’ (Gamma 2.6) is it possible within what you've created so far in yCMS?

[yesgrey]

What would be involved in getting a 3D LUT created to X’Y’Z’ (Gamma 2.6) is it possible within what you've created so far in yCMS?
Yes, it should be possible, but I haven't tested it yet. I'm planning to include that option in next yCMS version, but you can already use it with the current one by defining it on your own by using:

Output_Primaries 1.000 0.000 0.000 1.000 0.000 0.000 0.3127 0.3290
Output_Transfer_Function 1.0 0.0 0.384615384615385 0.0

Note: I've used D65 white point, but I think you can use any other you would prefer. I've read the DCI spec and did not find any reference for a specific white point.

[Yellow_]

Excellent, once again thanks, going to give it a go. :-)

Looks like last bit of the jigsaw is a avisynth plugin using Openjpeg to export the jpeg2000 images unless imagemagick does it now, via Wilberts plugin.

[yesgrey]

Hi! Chroma is usually 16-240 for YUV video. For xvYCC it is 0-255. My question related to capturing this signal via HDMI. If I use a video capture program like VirtualDub, does it capture the extra chroma values for chroma ?
I don't know, but if it works according to spec it should, because the entire range 1-254 is supposed to contain video data, but to be sure ask VirtualDub's author about it.

Problem is that a HDMI capture card outputs HDYC, which is then converted to RGB24 (as the video preview is seen on the monitor), then it is converted to YUV 4:2:2 for capture.
The extra chroma values would give a negative RGB value, so I would think they get thrown away.
If you perform any conversion from HDYC to an RGB that could not hold the entire range of colors you will lose them. However, why would you perform that conversion if the capture would always be in YUV? Just capture the original data without any processing.

Am I missing something?

[Yellow_]

Queried xvYCC handling with Virtualdub author and Vdub can't handle an RGB gamut wide enough to contain xvYCC in RGB such as AdobeRGB, think Vdub is sRGB only.

That could well explain why I wasn't seeing anymore colors than just doing full range conversion prior to you implementing xvYCC, both must have been clipping at the boundary of sRGB.

Need to find an alternative tool to process avisynth scripts, maybe FFmpeg on the command line? Hack Blender to support AdobeRGB, as it only supports sRGB and linear currently but can process avs scripts via ffmpeg.

Or perhaps when I was using Wilberts Imagemagick plugin it was writing out images of sRGB gamut, maybe need to revisit that and see if there is a way to set gamut to AdobeRGB in imagemagick via his plugin.

Still haven't got my head round linear space yet, I assume the width of gamut is the same as the source?

If an app has a 32bit float linear compositing pipeline and writes images out either as linear exr or gamma encoded formats like png, jpg etc restricted to sRGB, is the linear exr restricted sRGB gamut or does linear have a capability for a wide gamut?

[yesgrey]

Still haven't got my head round linear space yet, I assume the width of gamut is the same as the source?
Yes, it's exactly the same width. The linear vs gamma only affects the distance between the different points inside the gamut, and not the gamut itself.

[zcream]

Just wondering how we could even get xvYCC data in a video file anyway ?

I checked with Blackmagic Design, and it turns out that the chipset they use clips the colors from 16-240. Most HDMI capture cards use the same HDMI chipset - hence its not possible to capture this color range.

xvYCC is only present in the HDMI specs, I dont see it on any other video transport spec.

So how can one get xvYCC video data anyway ?

Also, with VD, if the input stream is YUY2 or HDYC, you can use Fast Recompress and thus turn off any RGB conversion. This way, any xvYCC data should be retained during conversion.

[Yellow_]

Just wondering how we could even get xvYCC data in a video file anyway ?

xvYCC is only present in the HDMI specs, I dont see it on any other video transport spec.

So how can one get xvYCC video data anyway ?



http://forum.doom9.org/showthread.php?p=1464035#post1464035

[yesgrey]

I checked with Blackmagic Design, and it turns out that the chipset they use clips the colors from 16-240.
This kind of thing always amazes me... Why do they do it? Even the ITU.BT-709 standard clearly says that video data is all the range from 1-254, so why do they clip it?
Then, this kind of thing happens. A new standard is developed considering the previous one was fully respected, but it wasn't...

[Yellow_]

Majority I guess, are there many sources that are full range by specification?

Broadcast, cable, satalite? Video cameras? a few video cameras support xv.color but it's not widely used.

But then what codecs support full range by specification? h264AVC is the only one I know.

Uncompressed capture will need a RAID.

Then having captured full range, other than playback on a TV with hdmi 1.3 and able to display full range correctly, what else to do with it, burn it to Bluray, not supported.

Edit it, what NLE's actually handle xvYCC without squashing it into 16 - 235/240 in some intermediate codec to do all the RGB processing on it? Not many I think. :-(

[poisondeathray]

Edit it, what NLE's actually handle xvYCC without squashing it into 16 - 235/240 in some intermediate codec to do all the RGB processing on it? Not many I think. :-(

This is true, but some can access Y'CbCr in filters even though they function in RGB . These filters are applied before the NLE converts to RGB. eg. if you have "illegal levels" you can use YUV filters to bring back into legal ranges. Premiere Pro CS5 does this for some filters. But I don't know how xvYCC is handled specifically

[Yellow_]

Yes, I think Premiere CS5 is one of the can handle it based on a comment from a Adobe representative:

Adobe CS5 reads the H.264 files natively into Premiere Pro and After Effects at the highest possible quality. Our color gamut and dynamic range for tonal detail from shadow to highlight is unsurpassed. There is even support for over-brights beyond 100% in After Effects.

The magic comes from the use of proprietary interpretation algorithms and I might also mention that we bypass QuickTime for this process, which avoids the whole gamma conundrum. Once the file is living inside our apps on the timeline or project, we deal with the image information at the 32 bit float level. Now that is not saying we can make an 8 bit H.264 DSLR video capture look like perfectly shot IMAX footage scanned at 16 bits, but what we do offer up is the ability to edit, apply effects and color corrections within our apps. at an unprecedented level of quality.

Obviously not proof but interesting. :-)

[xbox360]

What is the gamut for NTSC-J ? & how do I use it in an Avisynth script ?

[yesgrey]

What is the gamut for NTSC-J ?
Is it an analog source? If it is you might need to use the "US NTSC 1953" options. In addition to that you should use an input range that would compensate for the black point difference.

how do I use it in an Avisynth script ?
With t3dlut.

[xbox360]

In addition to that you should use an input range that would compensate for the black point difference.


With t3dlut.

And what would that input range be ?

[yesgrey]

And what would that input range be ?
It would depend on how the capture is performed. How are you doing it?

[xbox360]

sRGB captures.

[yesgrey]

sRGB captures.
Are you sure? Which card are you using? Also, tell me which output do you want? Tell me as much information as you can, only then I could help you creating a configuration file to use with yCMS.

[xbox360]

sRGB captures from Camera Fujifilm A100 .avi JPEG convert to NTSC-J. It would be great if you can make me a PAL to NTSC-J & NTSC to NTSC-J.

[yesgrey]

sRGB captures from Camera Fujifilm A100 .avi JPEG convert to NTSC-J. It would be great if you can make me a PAL to NTSC-J & NTSC to NTSC-J.
Start by trying this:

# PAL to NTSC-J
Input_Format PAL RGB_PC 8
Output_Format NTSC RGB_PC 8

and

# NTSC to NTSC-J
Input_Format NTSC RGB_PC 8
Output_Format NTSC RGB_PC 8
Input_Range 16 255

If you prefer you can use 16 bit depth on the Output_Format commands.

I'm not sure if these would be the correct configuration files, so let me know how they work out.

[leeperry]

A CUDA implementation would be easy to do, but I was thinking that it would be pretty limiting (in terms of supported video cards) compared to a pixel shader.
hi tritical, 3 years later times have changed...how about OpenCL then?

I kinda like the idea of keeping the gamut mapping stuff outside the VR...so we can set automatic rules in ffdshow, and get ddcc to use SMPTE-C/EBU/HDTV gamut mapping depending on the frame rate and the video stream native resolution. Also, there's no need to wait for the 96MB 3DLUT to be loaded each and every time you wanna watch a movie...so you get all the pros w/o any of the cons, too good!

Doing all this in the VR would require auto-detection of upscaled SD(madVR currently forces the HDTV gamut when x>1024) and a lof new automatic rules code that's already in ffdshow...no need to reinvent the wheel really.

I realize that doing all this in 8bit might not be the best idea, but SmoothLevels() does very impressive dithering...so this point is more or less covered. And SmoothLevels() is also using a kludge to allow 16bit in Avisynth 2.6(stacking MSB/LSB in YV16/YV24 (http://forum.doom9.org/showpost.php?p=1504207&postcount=210)). I guess that would be fairly easy to implement in ddcc? So provided that some small changes in ffdshow would be made(I think I know someone who could commit them), we could have a full 16bit avisynth pipeline in ffdshow, and feed it as P216/RGB48 to madVR :devil:

I was also told that it would be a far better idea to post-process video when already using the right colors, instead of changing them afterwards...that'd make a lot more sense to use ddcc in 16bit at the very top of my ffdshow/avisynth scripts, than using a 3DLUT in madVR at the very last stage.

Hope you'll consider it, :thanks: in advance! I really miss ddcc in Avisynth, but it's a CPU hog...getting it to run off the GPU would be a God bless, and a perfect solution for on-the-fly and automatic rules based gamut mapping. A killer combo together w/ the supreme smoothness of madVR :cool:

[leeperry]

@tritical: any chance you could make yv12toyuy2() fallback to itype=0 if it's not mod4 please?
which can easily be overcome by using this script (http://forum.doom9.org/showpost.php?p=1453641&postcount=22), that will pad black borders in order to become mod4.

it's nice to see that solutions do arise over time...now all that'd be required is OpenCL GPU acceleration for ddcc, and then this would become an entirely workable solution :cool:

[Kazuya]

Hope you'll consider it, :thanks: in advance! I really miss ddcc in Avisynth, but it's a CPU hog...getting it to run off the GPU would be a God bless, and a perfect solution for on-the-fly and automatic rules based gamut mapping. A killer combo together w/ the supreme smoothness of madVR :cool:

Automatic switching gamut would be great of course !!! :)

[tritical]

Do you want ddcc() or rgb3dlut() on the gpu?

[leeperry]

hi tritical, thanks for the reply!

well, ddcc() works in realtime, doesn't need to read LUT's and can provide gamut mapping on its own...IIRC, it was chosen to go LUT in order to drastically lower the CPU usage. Going GPU accelerated would alleviate this problem, so I don't really see the point to bother w/ LUT's anymore?

OTOH, ddcc() requires RGB24/RGB32 input, which takes a lot of CPU cycles....rgb3dlut() uses small 8bit LUT files and only needs YUY2 input.

tough call! I guess rgb3dlut() would make a lot more sense indeed...and doing the RGB32 conversion via the GPU is always a nice touch :)

[tritical]

Yeah, I guess what I was asking was what colorspace would you be using for input/output? ddcc is much easier to put on the gpu - in terms of complete feature set - (in fact I did it last night in cuda since I have a lot of experience with cuda and none with opencl), but has the restriction of rgb24/rgb32 input/output. Of course, that input/output restriction is what makes it an easier task than putting rgb3dlut on the gpu. I could add yuy2 input to ddcc, but what output format makes sense in that case (yuy2, rgb24, rgb32, all three)? Plus with yuy2 input I'd have to handle different chroma placements, upsampling methods, etc... which is kind of a pain.

[leeperry]

Oh, YUY2 input on ddcc() would rock! I'd be using YV12 input in the best case scenario, otherwise YUY2. And I'd need RGB32 output, I don't see much point to RGB24? Ideally YV12 input/output would be best, but that'd require a lot of lossy conversions I guess...or maybe you could add dithering to make it less painful? :o

That's for the regular 8bit Avisynth pipeline, because P216/Y416 input and RGB48 output could be useful sometime in the future.

I'm from team nvidia, so a CUDA version would be truly fantastic...you could always go OpenCL in the future if there's any request for it(and that you want to bother w/ OpenCL in the first place).

Indeed, a CUDA version of ddcc() that would accept YUY2 input and converts to RGB32 using the GPU would really be beyond words! If it could also convert from a YV12 input to YUY2 internally using the GPU would be even better :cool:

And feeding RGB32 to madVR wouldn't require using ColorMatrix() to convert the 601 decoding matrix coeffs to 709 for upscaled SD(because madVR uses 709 if x>1024) anymore, so that'd mean one less 8bit Avisynth plugin to process :)

:thanks:

[tritical]

In the interest of actually getting something released, I put up a new version of ddcc which has a CUDA implementation of ddcc(). Syntax wise the only thing that changed is 'opt' can be set to 2, which forces cuda to be used. By default, it will use the cuda implementation if a suitable device is found. I do not perform a search over all devices, just query the default device for the thread that ddcc is created in. I only tested it on an old 9800 gtx+, speed was the same as the cpu version on my q6600 quadcore.

I might add yuy2 support or other things in the future as time/motivation allows.

[leeperry]

ouh that was a fast, thanks a lot!

I'll be testing it and report back then :)

[leeperry]

having second thoughts, do you think it would be possible to get ConvertToRGB32() to use CUDA as well? that would be a perfect solution as a combo w/ the CUDA build of ddcc(), and far less work for you than reinventing the wheel? I guess the source code should be fairly easy to locate :)

[leeperry]

having even more thoughts about it, if you could embed a CUDA version of ConvertToRGB32() and ddcc() into one single plugin, this would avoid one very lossy 8bit pass? going YV12 > 32fp RGB(or RGB48 for that matter) > ddcc > RGB32(and RGB48 as well, as madVR supports it natively...but that'd require some modifications in ffdshow).

:thanks:

[tritical]

Creating a full converttorgb (with different interpolation functions, chroma placements, interlaced vs progressive for yv12, etc...) would take more time than I want to spend. I would be willing to start with a single case for ddcc: yuy2 input with mpeg2 chroma placement and linear interpolation for upsampling to 4:4:4 and output rgb32. Would that be usable?

[leeperry]

Oh, you've got me a bit lost here...is it what RGB32HQ in ffdshow and ConvertToRGB32() do? then that would be great :)

from reading the rgb3dlut() manual, "mpeg2/mpeg4/h264" chroma placement sounds good, I think the "Mitchell-Netravali two-part cubic interpolation" used to look better than "linear interpolation"...but if that's too much trouble, let's forget about it. I could always blur the chroma in madVR if I like(I upscale before going through the Avisynth scripts then I let madVR downscale using the GPU, otherwise LSF gives jaggies at 1:1 resolution...hence the requirement to use "SuperSampling" as they call it).

And I guess MPEG1 wouldn't look too ugly when using MPEG2 chroma placement? I dunno what placement madVR and ffdshow assume, prolly MPEG2 as well :o

The main goal would be to have the RGB32 conversion done through CUDA, in order to save CPU cycles indeed. And possibly output RGB48 to madVR when Avisynth/ffdshow will allow it.

:thanks: for all once more, as you're one of the shapers of my dreams :cool:

[leeperry]

OK, I finally found the ddcc() calls I was using a few years back, but now ddcc() complains that I don't have "cudart32_40_17.dll" :o

I run a 9600GSO(rebadged G92 8800GS w/ 96SP) and the 257.21 drivers on XPSP3, and I've got "nvcuda.dll 6.14.12.5721". CoreAVC 2.55 CUDA works like a charm, and "CUDA" support is checked in GPU-Z.

Is that a DLL that can be found in the dev.kit? http://developer.nvidia.com/cuda-toolkit-40

Or shall I update to the newest WHQL drivers? They don't mention CUDA 4.0, though: http://www.nvidia.com/object/winxp-275.33-whql-driver.html

[jmac698]

I'm new to t3dlut etc., is there a way to convert yuv (rec709) to Lab?

[leeperry]

Because of the CUDA error message, I cannot seem to be able to use ddcc() in SSE3 mode either...I did set "opt=1" so it shouldn't even try to use CUDA? :o

PS: ok, using 1.11 and spot-on gamut mapping in plain RGB32 fed to madVR is really major bliss! I can't use spline SuperSampling anymore because the software RGB32 conversion and gamut mapping are quite a CPU hog...can't wait for the full CUDA version. :thanks:

[Yellow_]

Having now established a way to export 10bit h264 and 16bit RGB using avs2yuv is it possible to use t3dlut to export 10 / 16bit rather than it dither back to 8? Is setting output bitdepth to 16 in the LUT generation all that is reqired?

[tritical]

I'm new to t3dlut etc., is there a way to convert yuv (rec709) to Lab?

Not at the moment. Why do you need to convert to LAB? Conversion to LAB from XYZ is simple, but outputting lab as 8-bit would not work very well.

Having now established a way to export 10bit h264 and 16bit RGB using avs2yuv is it possible to use t3dlut to export 10 / 16bit rather than it dither back to 8? Is setting output bitdepth to 16 in the LUT generation all that is reqired?

Current version of t3dlut only supports 8-bit output. I am not update to date on avisynth 2.6 or whether it supports higher bit depths. The 8-bit output requirement is a restriction of avisynth (at least with 2.5.8), if avisynth supports higher bit depths then t3dlut could be made to dither to those.

but now ddcc() complains that I don't have "cudart32_40_17.dll"
Is that a DLL that can be found in the dev.kit?
Yes, it is part of the 4.0 toolkit. The ddcc.dll is linked statically against it so it must be found in the system path in order for the dll to load at all. I believe I included it in the ddcc.zip archive.

[jmac698]

I want to do processing in L*a*b, but output to 8bit yuv again. I'm using this to colormatch videos, so lab is the ideal colourspace for this.

If we wait for high bit support in avisynth, it will be a long time. I suggest supporting one of the workaround formats. Smooth levels for example supports high bit depths and dithering down to 8 bit. It uses MSB stacked vertically on top of LSB. My deepcolor tools uses a separate clip for MSB and LSB. I also support levels adjustments, and I can input true highbit videos. I helped with the update to sashimi to support reading high bit quicktime formats.

[Yellow_]

Current version of t3dlut only supports 8-bit output. I am not update to date on avisynth 2.6 or whether it supports higher bit depths. The 8-bit output requirement is a restriction of avisynth (at least with 2.5.8), if avisynth supports higher bit depths then t3dlut could be made to dither to those..

Thanks to the Dither 1.9 functions, stacked lsb/msb and avs2yuv, 10bit h264 encoding and 16bit image writing via Imagemagick using standard out successfully works with Avisynth 2.5.8.

A git build of ffmpeg is required to successfully play 10bit h264 however and that also appears to work.

[leeperry]

Yes, it is part of the 4.0 toolkit. The ddcc.dll is linked statically against it so it must be found in the system path in order for the dll to load at all. I believe I included it in the ddcc.zip archive.
Oops, my bad! So I've copied it to the system32 folder but now it says "opt = 2 but no cuda device detected".

Can I send you a log somehow? Should I install the dev.kit in your opinion?

And once that'll work, how to figure out what to set for "oog" if you don't mind me asking?

:thanks:

[tritical]

leeperry, it is probably a driver issue. I would try upgrading to the latest driver from nvidia (275.33?). As for 'oog', I think 1 would generally be preferable since it maintains hue/saturation. It's really just a personal preference.

jmac698/Yellow_, I will look in the stacked MSB/LSB output. Or someone else can modify it if they feel so inclined. I can merge the changes.

[leeperry]

As for 'oog', I think 1 would generally be preferable since it maintains hue/saturation.
Oh indeed, my CRT barely reaches SMPTE-C and when I map gamuts from EBU...if I set oog=0 then the colors end up utterly undersatured :o

leeperry, it is probably a driver issue. I would try upgrading to the latest driver
you nailed it! I was afraid to update coz that'd mean setting up all my custom res all over again, but they seem to have improved the custom res panel..and it all went like a breeze :)

BTW, some tests results in VDUB(Q9450@3.5Ghz on XPSP3):

ddcc(chr_i=3,gam_i=5,gam_o=5,ofile="P:\CRT.txt",threads=4,opt=1)
http://www.pixelz.fr/e/3/4/ca018bb46b31e6ba87f2858bae662.png

=252 fps

ddcc(chr_i=3,gam_i=5,gam_o=5,ofile="P:\CRT.txt",opt=2)
http://www.pixelz.fr/e/6/8/850977083923dfb2fa24777dd5582.png

=230 fps

How could I change the cores affinity? I'd rather have the load evenly balanced between the four cores if any possible :o

I've tried to force "threaded optimization" for my media player in there, but that gives randomly dropped frames(that don't occur when it's left on "auto"): http://www.pixelz.fr/9/f/4/dd152000bd4ff9f4d18e332d11adct.jpg (http://www.pixelz.fr/9/f/4/dd152000bd4ff9f4d18e332d11adc.png)

PS: ddcc() works beautifully in combination w/ CoreAVC CUDA of course :cool:

That's an untouched BD w/ CoreAVC CUDA 2.55 + dddc() CUDA + madVR Spline downscaling: http://thumbnails45.imagebam.com/13719/e97bf1137184129.jpg (http://www.imagebam.com/image/e97bf1137184129) http://thumbnails46.imagebam.com/13719/d707a4137184130.jpg (http://www.imagebam.com/image/d707a4137184130)

PPS: it's pretty annoying that "ConvertToRGB32" crashes most of the time when used in MT("",4) mode...lotsa wasted CPU cycles running it non-MT :o

[Yellow_]

jmac698/Yellow_, I will look in the stacked MSB/LSB output. Or someone else can modify it if they feel so inclined. I can merge the changes.

Excellent, enquring if you've had time to give this any more consideration.

[leeperry]

Hi tritical,

I've been using the CUDA build of ddcc() ever since you released it(XPSP3/96SP 8800GS/275.33), but I've encountered 2 problems when switching back and forth between input gamuts(chr_i=0/2/3) in ffdshow(without restarting the video). In both cases, I wasn't using CoreAVC CUDA...only PotPlayer/madVR and ffdshow audio+video.

That's the call I was using:
ddcc(chr_i=3,gam_i=5,gam_o=5,ofile="P:\CRT.txt",opt=2)

1) A few days ago, after switching back and forth like 4 times, I got the "opt = 2 but no cuda device detected" error message...so I closed the video, reopened it and it worked fine again.

2) a few mins ago, I was switching like +8 times(trying to figure out if this 30fps european SD video was EBU or SMPTE-C :rolleyes:) then I got a brief green flash at the second third of the screen, the computer locked up on the last video frame before the green flash...and bye bye Kansas, not even a soft reset would allow the computer to work again. My mobo BIOS decided that the graphic card was crashed for good and ran a hard reset instead.

That's too bad I've got no log to provide you w/, hopefully you could bulletproof the realtime changes in order to avoid any crash/deadlock please?

:thanks: again for your hard work, much appreciated!

[leeperry]

Ahhh, there's a new option in madVR 0.67 to force prebuffering when seeking, so I was trying it and enabling/disabling LSF on the fly in ffdshow to see how the new option would react(I use several scripts in ffdshow: SmoothLevels(for TV>PC conversion)>LSF>GrainFactory3>ddcc). I was running madVR in FullScreen Exclusive mode, and after I had toggled LSF like 6 times in a row, I got the very same green flash at the second third of the screen(like this: http://thumbnails50.imagebam.com/14100/129389140995987.jpg (http://www.imagebam.com/image/129389140995987) ) for a half second, then the picture froze, the mouse froze a few secs later...and I was forced to reboot. My mobo BIOS managed to get away w/ a soft reset this time.

Any chance you could reproduce tritical? Any chance for a fix please please please?

I will now refrain from making realtime changes in my ffdshow Avisynth scripting, and I have to say that I'm really amazed by the colors and PQ when using proper gamut mapping via ddcc() :eek:

:thanks:

[tritical]

@leeperry I would fix it if it had anything to do with ddcc, but there's no way ddcc can cause that or anything in the code I can change. It must be either a driver/card issue, or the software you are running avisynth in is not closing the associated thread(s) (and associated cuda context(s)) properly.

Also, for anyone using it, I would not advise using setmtmode or other avisynth multithreading methods with ddcc+cuda. However, it should work correctly as long as the getframe method is called in the same thread as the constructor/destructor.

[leeperry]

oh ok, thanks for the reply! but ddcc() works perfectly fine in software mode when messing in realtime w/ the avisynth filter of ffdshow...it seems rather clear that sometimes the CUDA connection is not closed properly and hell breaks loose at the GPU drivers level =/

so indeed ffdshow doesn't close the threads properly, and "Leak"(the coder who took care of the avisynth support in ffdshow) has recently made it clear to me that he doesn't plan on developing it any further.

[leeperry]

OK I've found my old Avisynth scripts and going:
ConvertToYUY2()
rgb3dlut(lutfile="P:\smpte-c",threads=4,itype=2,b=1.0,c=0.0)

carries many advantages:
-no CUDA drivers required, meaning that ffdshow won't crash my computer anymore when rolling gamuts on the fly
-no need to make a CPU hogging ConvertToRGB32() conversion
-the ability to use oog=1, which isn't possible in CUDA mode
-ddcc() CUDA still uses quite a lot of CPU cycles from what I've seen, mostly due to the nvidia drivers I presume...OTOH, rgb3dlut() is very light CPU-wise.

I gave up on this solution because up to very recently, mVR only supported YV12 input.

Also, using rgb3dlut() in ffdshow allows automatic profiles based on resolution & frame rate, and mVR now uses a new colorimetry system called "yRGB" that requires a 16bit 96MB LUT(that takes forever to load), won't remember the last used gamut and won't allow automatic profiles (yet)...so all in all, going back to the old school sounds very reasonable. Shelling out $500 on a new i7 box in order to get CPU based gamut mapping simply does not :rolleyes:

I fully realize that doing all this in 8bit is a terrible idea, but 16-235 SMPTE-C(the smallest gamut in the industry) isn't quite as data intensive as xvYCC I guess. And tbh SmoothLevels() does such an amazing job at dithering that I highly doubt anyone could DBT it from native 10/12bit.

PS: ends up 8bit LUT's are 48MB, I've got 3 gamuts and 2 YUY2 LUT's for each decoding matrix...so that's 240MB of LUT's(I don't see how HDTV could use BT601).

PPS: I might as well input and output YUY2 using t3dlut(), but then I'd have to rely on mVR to either go 601 or 709 RGB...and t3dlut() requires far more CPU cycles than rgb3dlut().

Actually, rgb3dlut() in YUY2 is so light on the CPU that I can use Gavino's script (http://forum.doom9.org/showpost.php?p=1453641&postcount=22) to automatically become mod4 and yv12toyuy2(itype=2,threads=4) http://forum.slysoft.com/images/smilies/agreed.gif

yv12toyuy2(itype=2,threads=4,b=0,c=0.75) is way too edgy...0.33/0.33 would appear far more reasonable, as madshi advised (http://forum.doom9.org/showpost.php?p=1276180&postcount=426).

[leeperry]

Alright, I will need to do screenshots comparisons against vanilla ddcc() in order to ensure that gamuts mappings & YCbCr decoding matrixes are processed properly, I'll put my 240MB of LUT's on a PC8500 ramdisk for instant access then it'll all be looking very much kosher to me :D

It's great how it all fits perfectly together in order to provide a very impressive HTPC experience :)

The ability to change the bicubic coeff for both the YV12>YUY2 interpolation and RGB32 conversion really allows you to finetune it all perfectly to your 1) video processing pipeline 2) equipment 3) taste...I'm really stunned by the PQ tbh :cool:

[leeperry]

Bumpity, Bump :)

AVS 2.60 supports ConvertToYUY2(chromaresample="Spline64") in MT mode, so that more or less renders yv12toyuy2(itype=2,threads=4) useless? And it's not mod4-only so that makes my life a lot easier.

Also, I might consider creating a bigger ramdisk and use 16bit YUY2 LUT's instead of 8bit, but why is t3dlut() so much more power hungry than rgb3dlut() again? :o

[nand chan]

Does anybody have plans for the future of the .3dlut spec, or possibly a v2/v1.1?
These are some of the issues I've noticed while working with the current, and I'd be more than happy to help discuss changes / alterations to improve these:


Many programss still have to scan through the parameters file to find out some information that is not present in the tags
No tag for the value range (full range, limited range, min/max, etc)
No concept of color space - a color-aware 3dlut could easily be achieved with optional gamut tags, this would allow tools such as madVR to transform color into the input color space
It seems like nothing actually uses the “color encoding” fields, they're set to 0 even on YCbCr LUTs. Am I mistaken of its purpose? This could be improved to reflect the color encoding nature (YUV, RGB, BGR, etc)
No currently defined compression methods

[madshi]

yesgrey was planning to specify the meaning of the color encoding fields for a while. He hasn't had the time to do that yet.

I'd welcome an addition to the 3dlut spec with the changes you're suggesting. Hopefully yesgrey can participate? The problem is that yesgrey is in the process of moving to another country, so this is a bad time for him to extend the spec. I don't know how much time (if any at all) he will have to participate in the next couple of days/weeks.

[nand chan]

yesgrey was planning to specify the meaning of the color encoding fields for a while. He hasn't had the time to do that yet.

I'd welcome an addition to the 3dlut spec with the changes you're suggesting. Hopefully yesgrey can participate? The problem is that yesgrey is in the process of moving to another country, so this is a bad time for him to extend the spec. I don't know how much time (if any at all) he will have to participate in the next couple of days/weeks.

Yeah, I've contacted him via PM and it seems like he won't have time for a few months at least.

It seems we will have to make do with ourselves for now, it's just a spec after all - not the implementation in yCMS.

In effort to get this moving forwards, I shall propose some suggested changes:

In addition to modifying the current color encoding fields, we will have to add new tags for some things. Should the space in the current header not suffice, the solution will be to increase the offset of the parameters file, which is helpfully encoded in the format itself. As such, all new tags will simply be appended to the end of the last tag, lutUncompressedSize, to maintain backwards compatibility with v1.

Encoding the input and output value ranges

Three ways I have thought of dealing with this:

Encoding the value range as enumeration of possibilities, eg. 0 = (0-255), 1 = (16-235), possibly more in the future (xvYCC?)
Encoding the lower and upper bounds as separate numbers, eg. 0 and 255 - this has the possibility of added flexibility, but it would create a situation where we have to either complicate the rendering chain further or risk creating unsupported LUTs
Encoding the lower and upper bounds as floating point numbers, relative to the maximum for that bit-depth, eg. 0.0627 and 0.922 for 16-235 (as relative to 255). While this may seem like an ideal solution in practice, and required if we are to use 32-bit floating point LUTs, it will also complicate the rendering chain and possibly add inaccuracies.

I'm personally leaning towards either options 1 or 3, the latter because it offers the greatest flexibility, and the former because it's the easiest to work with, especially if you don't want to add the conversion logic and simply want to detect whether a LUT is 16-235 (and reject it otherwise, like madVR does).

Color Encoding field

Given that the current color encoding value of 0 represents BGR, in both value order and enumeration order, we can introduce the value of 1 for YCbCr and the value of 2 for RGB. If the value is 2, the values would simply be flipped around, meaning that the offset would now be (b<<(inputBitDepth[1]+inputBitDepth[0])+g<<(inputBitDepth[0])+r)*3, and so forth.

If this is too contrived or seems unnecessary, it could also be simply limited to 0 and 1.

Color space encoding

This tag will be a strictly optional, with 0 for every value meaning “disabled” or “unknown”. Some things we would have to take care of:

Encoding the red point, green point, blue point and white point of RGB data
Potentially encode the conversion constants for YCbCr output, but this alone will not remove color space ambiguity

A simple method would be to introduce the following fields:

float primaryRedX
float primaryRedY
float primaryGreenX
float primaryGreenY
float primaryBlueX
float primaryBlueY
float primaryWhiteX
float primaryWhiteY

Another possibility would be to encode the values using doubles.

File compression:

We will probably have to make a trade-off here between compression quality and decompression speed, as waiting a few seconds to decompress the LUT when starting playback might be more of a trade-off than it's worth, especially with increasing hard drive sizes.

In effort to measure the gain, I have performed some test compressions on the .3dlut which I use for daily viewing, sorted by size:

Original size: 100 MB
.bz2: 83.59 MB
.gz: 77.66 MB
.zip (normal): 75.84 MB
.rar (fastest): 66.42 MB
.rar (fast): 64.34 MB
.7z (LZMA): 34.61 MB
.rar (normal): 7.35 MB

Gamma

Another thing that might be useful to store is the input/output gamma transfer functions, but I don't know where this would truly be necessary.

XYZ output and PCS

Finally, in effort to get the power of 3dluts closer to something like ICC profiles, we could perhaps allow a PCS such as XYZ as an acceptable output color encoding, that way you could generate two RGB -> PCS LUTs and link them using implementation specific logic to form a single RGB -> RGB LUT.

On the matter of backwards compatibility (for tools and implementations):

To indicate the presence and/or alterations of these fields, the “fileVersion” shall be updated to 2. Should a program supporting version 2 encounter a version 1 LUT, the appropriate backup response shall be to ignore the ColorEncoding fields and draw information from the parameters file as currently. Similarly, if creating a v1 YCbCr LUT, the field shall be kept as “0” to avoid confusing older programs unnecessarily.

Thoughts?

If nobody has any suggestions or further input, then I'll create the first draft of the spec v2 myself and implement it for my toolset.

[nand chan]

If nobody has any suggestions or further input, then I'll create the first draft of the spec v2 myself and implement it for my toolset.

Said and done:

The updated .3dlut spec proposal: OBSOLETE - See the 3DL2 spec below

________________________________________________________________________________

3DLUT file format specification (version 2)
________________________________________________________________________________

enum {PAGE_SIZE = 16384};
struct H3DLUT
{
char signature[4]; // file signature; must be: '3DLT'
long fileVersion; // file format version number (currently 2)
char programName[32]; // name of the program that created the file
long long programVersion; // version number of the program that created the file
long inputBitDepth[3]; // input bit depth per component (Y,Cb,Cr or B,G,R)
long inputColorEncoding; // input color encoding standard (0 = BGR, 1 = YCbCr)
long outputBitDepth; // output bit depth for all components (valid values are 8, 16, 32 and 64)
long outputColorEncoding; // output color encoding standard (0 = BGR, 1 = YCbCr, 2 = XYZ)
long parametersFileOffset; // number of bytes between the beginning of the file and array parametersData
long parametersSize; // size in bytes of the array parametersData
long lutFileOffset; // number of bytes between the beginning of the file and array lutData
long lutCompressionMethod; // type of compression used if any (0 = none, ...)
long lutCompressedSize; // size in bytes of the array lutData inside the file, whether compressed or not
long lutUncompressedSize; // true size in bytes of the array lutData when in memory for usage (outside the file)
long inputValueRange; // value range for the input (0 = Full range (0-255), 1 = Limited (16-235))
long outputValueRange; // value range for the output
// Input color space - this section is strictly optional, a value of 0 for all means “disabled/unknown”
double inputPrimaryRedX; // Though the X and Y are capitalized here for the naming convention,
double inputPrimaryRedY; // they refer to the x and y coordinates on the CIE xy chromaticity diagram,
double inputPrimaryGreenX; // and *not* the XY values of the XYZ color space.
double inputPrimaryGreenY;
double inputPrimaryBlueX;
double inputPrimaryBlueY;
double inputPrimaryWhiteX;
double inputPrimaryWhiteY;
// This header is followed by the char array 'parametersData', of length 'parametersSize',
// and by the array 'lutDataxx', of length 'lutCompressedSize'.
};
char parametersData[1];
union LUTDATA
{
unsigned char lutData8[1];
unsigned short lutData16[1];
float lutData32[1];
double lutData64[1];
};
// The array 'parametersData' starts 'parametersFileOffset' bytes after the beginning of the file.
// The array 'lutDataxx' starts 'lutFileOffset' bytes after the beginning of the file.
// When creating a 3DLUT file, 'lutDataxx' should be positioned on a 16384 byte boundary.
//
// parametersData - char array with size parametersSize that contains an exact copy of the
// input file with the commands and settings used for creating the 3DLUT file
// lutDataxx - array with size lutSizeUncompressed that contains the 3D LUTs output values.
// The type used depends on the 'outputBitDepth' field:
// - unsigned char, if outputBitDepth = 8
// - unsigned short, if outputBitDepth = 16
// - float, if outputBitDepth = 32
// - double, if outputBitDepth = 64
// The value ranges are assumed to be as follows:
// Full range (integers): 0 to (2^depth) - 1, for example 0-255 and 0-65535
// Full range (floats): 0 to 1
// Limited range (integers): 16 to 235, left/right shifted to the correct bit depth, eg. 4096-60160)
// Limited range (floats): (16/255) to (235/255), approx. 0.06275 - 0.92157.
// For XYZ output:
// XYZ must be appropriately normalized so that the luminosity of white = the range limit.
// eg. for limited range 8-bit output, the luminosity of white would be 235. If the value range is full range,
// this would mean that the values are essentially capped to 255. As such, using limited range for XYZ is
// preferable for integer output. It is strongly recommended that one uses full range floats for XYZ however,
// where the luminosity of white would be normalized to 1.0
// The offset inside the array is calculated as:
// offset = (cr<<(inputBitDepth[1]+inputBitDepth[0])+cb<<(inputBitDepth[0])+y)*3 // YCbCr input
// offset = ( r<<(inputBitDepth[1]+inputBitDepth[0])+ g<<(inputBitDepth[0])+b)*3 // BGR input
// The output order inside the array is:
// Y = lutDataxx(offset); Cb = lutDataxx(offset+1); Cr = lutDataxx(offset+2) // YCbCr output
// B = lutDataxx(offset); G = lutDataxx(offset+1); R = lutDataxx(offset+2) // BGR output
// X = lutDataxx(offset); Y = lutDataxx(offset+1); Z = lutDataxx(offset+2) // XYZ output
// The 'lutUncompressedSize' of the array is calculated as:
// lutDim = 3*(2^inputBitDepth[0]*2^inputBitDepth[1]*2^inputBitDepth[2])
// lutUncompressedSize = lutDim*outputBitDepth/8
// This specification assumes:
// char = 1 byte; short = 2 byte; float = 4 byte; long = 4 byte; long long = 8 byte; double = 8 byte

Notable changes:

The inputBitDepth field has been redefined to be ordered as B,G,R instead of R,G,B
64 is now an acceptable outputBitDepth, and an appropriate array has been added to LUTDATA
The addition of fields inputValueRange and outputValueRange, and the definition of their ranges in the specification itself
Fields inputPrimaryRedX through inputPrimaryWhiteY define the input color space of a .3dlut
The inputColorEncoding and outputColorEncoding fields have been elaborated on
XYZ is now an acceptable output color encoding, and the implementation is defined
Due to the increased header size, the parametersFileOffset must not fall short of 168, a value of 176 is recommended

Reference implementation:

Preview release of the v0.9 of the TI3Parser toolset which includes full support for .3dlut v2 can be found here: http://www.mediafire.com/?aix71ea5y5kmqw8 (source code included)

This includes a utility to convert v2 .3dluts into v1 .3dluts (by running tag3dlut -1 -i <somefile>.3dlut) so we can use the new spec until madVR supports them.

Full changelog of the version 0.9 up to now:

Version 0.9:
! Created and added support for the .3dlut specification v2, changes include:
+ Added support for 64-bit floating point LUTs
+ Added support for color-space aware LUTs
+ Added support for RGB/YCbCr -> XYZ LUTs for profiling purposes, similar to how ICC device profiles work
+ Added support for file-encoded value ranges
* Utilities such as gen3dlut and changedepth which create new LUTs now use the v2, so you no longer need to fix tagging
using tag3dlut
? Note: Since programs such as madVR still only support v1 .3dluts, you need to “convert” it to a v1 for those programs
+ --one (-1) tag added to tag3dlut in order to degrade the version number to v1, this also overwrites the params in order
to correctly tag everything for madVR etc.
+ --color-space (-c) flag added to inspect3dlut
+ !Input_Primaries(rx, ry, gx, gy, bx, by, wx, wy) tag added to LutScript
+ !Input_Primaries(String) overload added to LutScript, acceptable values are currently: "BT709" and "None"
+ --ycbcr (-y) flag added to gen3dlut to generate a blank YCbCr LUT
* ColorTriple<T> is now aware of its encoding, in order to ensure transformations are properly chained
eg. the grayscale filter now simply sets Cr and Cb to 0 if the input is already YCbCr
~ Significantly increased performance here and there by operating on a single value in memory instead of copying it
over and over, however the old style of doing it is still available for cases where it's needed

[yesgrey]

The updated .3dlut spec:

You are forcing a spec without any of the original authors agreeing with it, so you are at your own risk.

Sorry, but I don't have time for this now. I don't see any reason for all this rush...

[nand chan]

You are forcing a spec without any of the original authors agreeing with it, so you are at your own risk.

Sorry, but I don't have time for this now.

As I've said, it's a first draft.

I don't see any reason for all this rush...

Because I'm having issues working with the existing .3dlut format. If you would prefer I not touch the original spec, then I shall simply create a new file format from scratch for my projects.

[nand chan]

If you would prefer I not touch the original spec, then I shall simply create a new file format from scratch for my projects.

Actually, this seems like a good idea regardless, so I can re-order the existing header without worrying about backwards compatibility.

.3dl2 specification:

________________________________________________________________________________

3DLUT2 file format specification
________________________________________________________________________________

enum {PAGE_SIZE = 16384};
struct H3DLUT2
{
byte signature[4]; // file signature; must be: “3DL2” as encoded using the ASCII standard (0x33444C32)
int fileVersion; // file format version number (currently 1)
byte programName[32]; // name of the program that created the file
long programVersion; // version number of the program that created the file
int inputBitDepth[3]; // input bit depth per component (Y,Cb,Cr or B,G,R)
int inputColorEncoding; // input color encoding standard (0 = BGR, 1 = YCbCr)
int inputValueRange; // value range for the input (0 = Full range (0-255), 1 = Limited (16-235))
int outputBitDepth; // output bit depth for all components (valid values are 8, 16, 32 and 64)
int outputColorEncoding; // output color encoding standard (0 = BGR, 1 = YCbCr, 2 = XYZ)
int outputValueRange; // value range for the output
int parametersFileOffset; // number of bytes between the beginning of the file and array 'parametersData'
int parametersSize; // size in bytes of the array 'parametersData'
int lutFileOffset; // number of bytes between the beginning of the file and array lutData
int lutCompressionMethod; // type of compression used if any (0 = none, 1 = LZO, ...)
int lutCompressedSize; // size in bytes of the array 'lutData' inside the file, whether compressed or not
PRIMARIES inputColorSpace; // Input color space - this section is strictly optional,
// a value of 0 for all means “disabled/unknown”
PRIMARIES outputColorSpace; // Output color space - the same rules apply as for input color space.
// In addition, if the output is XYZ, this section is to be set to 0 for all values

// This header is followed by the byte array 'parametersData', of length 'parametersSize',
// and by the array 'lutDataxx', of length 'lutCompressedSize'.
};
struct PRIMARIES
{
double primaryRedX; // Though the X and Y are capitalized here for the naming convention,
double primaryRedY; // they refer to the x and y coordinates on the CIE xy chromaticity diagram,
double primaryGreenX; // and *not* the XY values of the XYZ color space.
double primaryGreenY;
double primaryBlueX;
double primaryBlueY;
double primaryWhiteX;
double primaryWhiteY;
};
byte parametersData[1];
union LUTDATA
{
byte lutData8[1];
ushort lutData16[1];
float lutData32[1];
double lutData64[1];
};
// The array 'parametersData' starts 'parametersFileOffset' bytes after the beginning of the file.
// The array 'lutDataxx' starts 'lutFileOffset' bytes after the beginning of the file.
// When creating a 3DLUT2 file, 'lutDataxx' should be positioned on a 16384 byte boundary.
//
// parametersData - byte array with size 'parametersSize' that contains an exact copy of the
// input file with the commands and settings used for creating the 3DLUT2 file
//
// lutDataxx - array with size lutSizeUncompressed that contains the 3D LUTs output values.
// The type used depends on the outputBitDepth field:
// - unsigned byte, if outputBitDepth = 8
// - unsigned short, if outputBitDepth = 16
// - float, if outputBitDepth = 32
// - double, if outputBitDepth = 64
//
// The value ranges are assumed to be as follows:
// Full range (integers): 0 to (2∧depth)−1, for example 0–255 and 0–65535
// Full range (floats): 0 to 1
// Limited range (integers): 16–235, left/right shifted to the correct bit depth, eg. 4096–60160)
// Limited range (floats): (16÷255)≈0.06275 to (235÷255)≈0.92157.
//
// For XYZ output:
// XYZ must be appropriately normalized so that the luminosity of white = the range limit.
// eg. for limited range 8-bit output, the luminosity of white would be 235. If the value range is full range,
// this would mean that the values are essentially capped to 255. As such, using limited range for XYZ is
// preferable for integer output. It is strongly recommended that one uses full range floats for XYZ however,
// where the luminosity of white would be normalized to 1.0
//
// The offset inside the array is calculated as:
// offset = (Cr<<(inputBitDepth[1]+inputBitDepth[0])+Cb<<(inputBitDepth[0])+Y)×3 // YCbCr input
// offset = ( R<<(inputBitDepth[1]+inputBitDepth[0])+ G<<(inputBitDepth[0])+B)×3 // BGR input
//
// The output order inside the array is:
// Y = lutDataxx[offset]; Cb = lutDataxx[offset+1]; Cr = lutDataxx[offset+2] // YCbCr output
// B = lutDataxx[offset]; G = lutDataxx[offset+1]; R = lutDataxx[offset+2] // BGR output
// X = lutDataxx[offset]; Y = lutDataxx[offset+1]; Z = lutDataxx[offset+2] // XYZ output
//
// The lutUncompressedSize of the array is calculated as:
// lutDim = 3 × 2∧inputBitDepth[0] × 2∧inputBitDepth[1] × 2∧inputBitDepth[2] × outputBitDepth÷8
//
// This specification assumes:
// byte = 1 byte; short = 2 byte; int = 4 byte; long = 8 byte; // integers
// float = 4 byte; double = 8 byte; // floating point numbers
//
// << is used to denote an arithmetic left shift operator. Where strict/large inequality is wanted, ≪ is used.

I've updated the signature to 3DL2 and decreased the fileVersion back to 1. This also makes code supporting both very easy, you simply check to see if the signature is 3DLT or 3DL2 and is what I do in my code.

Other changes include the addition of an output color space field as well (I'll eventually create a fully color aware pipeline that can link together multiple 3dluts by mapping the gamuts between each step, so I've added this as a prerequisite) and the fixing of some stylistic issues (eg. incorrect ASCII symbols for mathematical operators being used where appropriate Unicode replacements exist)

[madshi]

Original size: 100 MB
.bz2: 83.59 MB
.gz: 77.66 MB
.zip (normal): 75.84 MB
.rar (fastest): 66.42 MB
.rar (fast): 64.34 MB
.7z (LZMA): 34.61 MB
.rar (normal): 7.35 MB
That's all too slow for real time use. I've already experimented with LZO and although it doesn't compress too well, at least it decompresses faster than reading from harddisk. I've already fully working LZO compression projects for 3dluts on my harddisk, but haven't had time yet to polish and publish it all.

[nand chan]

That's all too slow for real time use. I've already experimented with LZO and although it doesn't compress too well, at least it decompresses faster than reading from harddisk. I've already fully working LZO compression projects for 3dluts on my harddisk, but haven't had time yet to polish and publish it all.

I've added LZO compression to v0.10 of mine, using CompressionMethod = 1 to denote LZO.

Some metrics:
16-bit “blank” .3dl2 (input=output): Reduced from ~100 MB to ~50 MB

8-bit “blank” .3dl2: /increased/ from ~49 MB to ~50 MB. LutCompressedSize is larger than LutUncompressedSize.

16-bit gamut mapping .3dl2 created using LittleCMS + ICC profiles: Decreased from ~100 MB to ~70 MB.

Doesn't seem too bad, and decompressing is quite fast as mentioned. I'll leave it in for now.

[Yellow_]

A bit of a weird query but if I wanted a 3D LUT to convert from rec709/sRGB to 'another' with primaries as follows: Red CIE x = 0.73470 CIE y = 0.26530, Green CIE x = 0.00000, CIE y = 1.00000 and Blue CIE x 0.00010 & CIE y -0.07700.

Neutral Axis CIE x = 0.32168, y = 0.33767 Approx CIE D60 and Reference Midpoint Grey at CIE XYZ {0.1715, 0.1800, 0.1816}

What would I need to put in the 3dlut config file?

[madshi]

I've added LZO compression to v0.10 of mine, using CompressionMethod = 1 to denote LZO.

Some metrics:
16-bit “blank” .3dl2 (input=output): Reduced from ~100 MB to ~50 MB

8-bit “blank” .3dl2: /increased/ from ~49 MB to ~50 MB. LutCompressedSize is larger than LutUncompressedSize.

16-bit gamut mapping .3dl2 created using LittleCMS + ICC profiles: Decreased from ~100 MB to ~70 MB.

Doesn't seem too bad, and decompressing is quite fast as mentioned. I'll leave it in for now.
I've found that pre-processing the data before compression helps a lot with LZO compression. E.g. compression the difference instead of the absolute values.

[nand chan]

I've found that pre-processing the data before compression helps a lot with LZO compression. E.g. compression the difference instead of the absolute values.

So we make a LZOM (Lempel-Ziv-Oberhumer-Madshi) variation of it? :P

I'll experiment with what you suggested later. The only immediately jarring problem I see is that you need a signed integer to encode a negative offset, and if you use a signed integer then you can't encode a difference of something like 200. For example, if I want to make a 3dlut that inverts its output, I'll either need two signed integers or an unsigned integer to encode the difference offset.

A bit of a weird query but if I wanted a 3D LUT to convert from rec709/sRGB to 'another' with primaries as follows: Red CIE x = 0.73470 CIE y = 0.26530, Green CIE x = 0.00000, CIE y = 1.00000 and Blue CIE x 0.00010 & CIE y -0.07700.

Neutral Axis CIE x = 0.32168, y = 0.33767 Approx CIE D60 and Reference Midpoint Grey at CIE XYZ {0.1715, 0.1800, 0.1816}

What would I need to put in the 3dlut config file?

Just use yCMS? Something like

Input_Primaries 0.640312221900565 0.331429429181046 0.309178195500916 0.598966865076147 0.146091462964633 0.0570065026117047 0.3127266146811209 0.32902313032606195
Output_Primaries 0.73470 0.26530 0.00000 1.00000 0.00010 -0.07700 0.32168 0.33767

By the way, that is one *HUGE* color space you are talking about. 180% NTSC laser projector or what are you mapping to?

[Yellow_]

By the way, that is one *HUGE* color space you are talking about. 180% NTSC laser projector or what are you mapping to?

hehe, yep and pretty pointless from rec709/sRGB for 90% of uses. :-)

It's ACES IIF a overview here: Need to scroll down a bit to the ACES section.

http://www.fxguide.com/featured/the-art-of-digital-color/

And

http://www.oscars.org/science-technology/council/projects/iif.html

Thanks for the yCMS config.

[nand chan]

hehe, yep and pretty pointless from rec709/sRGB for 90% of uses. :-)

It's ACES IIF a overview here: Need to scroll down a bit to the ACES section.

http://www.fxguide.com/featured/the-art-of-digital-color/

And

http://www.oscars.org/science-technology/council/projects/iif.html

Thanks for the yCMS config.

Oh, thanks a lot for pointing me to this.

So it's basically like the PRMG except less shitty? It would be a good reference gamut for perceptual conversions in ICCv2 profiles (too bad the ICCv4 is already standardized to the PRMG).

(Then again, for perceptual conversions, it doesn't make a difference).

I like the idea of using the ACES as an *essentially* device independent gamut, we could use RGB as a PCS without needing to modify existing RGB gamut correction technologies (eg. yCMS).

That way you could make a 3dlut from BT.709 to ACES, and a 3dlut from ACES to any device, and link the two together using technologies such as merge3dlut.exe.

[Yellow_]

I'm pleased it's useful to you, most of what you've said is over my head, not really got into ICC stuff. :-)

On the subject of gamut's and conversions though, could I point you to this too in case it is of use, was meaning to ask here if anyone is looking at a plugin for Avisynth using it.

http://opencolorio.org/

http://code.google.com/p/opencolorio/

Although it's by Sony, it's open standard / opensource and being adopted pretty much everywhere, including VFX apps like the Foundary's Nuke Compositor and OSS tools like Blender.

OpenColorIO is also in the process of supporting ACES.

[nand chan]

I'm pleased it's useful to you, most of what you've said is over my head, not really got into ICC stuff. :-)

On the subject of gamut's and conversions though, could I point you to this too in case it is of use, was meaning to ask here if anyone is looking at a plugin for Avisynth using it.

http://opencolorio.org/

http://code.google.com/p/opencolorio/

Although it's by Sony, it's open standard / opensource and being adopted pretty much everywhere, including VFX apps like the Foundary's Nuke Compositor and OSS tools like Blender.

OpenColorIO is also in the process of supporting ACES.

Looks interesting. I wonder how much it differs from LittleCMS as far as gamut mapping goes. I may have to provide a LutScript function for this :P

[nand chan]

Updating my 3DL2 spec, it seems like we will have to support dynamic ranges after all. It's good that I split it off since now I can experiment and change the spec as the different needs and wants come in, and adapt my own implementation - until the changes are ready to be pushed back upstream.

For the sake of future flexibility, I am going to encode the black and white levels as 64 bit floating point values on the scale 0-1.

So, for example, a limited range 8-bit LUT (value ranges 16-235) would be (16/255) and (235/255) respectively, or approx. 0.0627451 - 0.921561.

Edit: Having done some testing, it is revealed to me that this method is not quite perfect, since that way you can't simply shift the bit depth without accounting for the value range, eg. (16/255) * 65535 is not, as correct, 4096, but in fact 4112. I'm still trying to come up with an elegant solution for this problem.

Edit 2: The solution dawned on me just as I type this. The value will not be represented as a fraction of the maximum value, but that of /one above it/ (eg. the range limit).

So, a 16-235 value range would be encoded as 16/256 and 235/256, or about 0.0625 and 0.91796875 respectively. This way, the scaling is preserved - 0.0625 * 65536 = 4096 and 0.91796875 * 65536 = 60160.

Some minor rewriting of my pullup/down engine will be required but very doable.

Floating point values will still be kept as their respective exact values, eg. a 32-bit .3dl2 with the output white level set to 0.2 will have a white point of exactly 0.8.

[IanB]

... For the sake of future flexibility, I am going to encode the black and white levels as 64 bit floating point values on the scale 0-1.
...
So, a 16-235 value range would be encoded as 16/256 and 235/256, or about 0.0625 and 0.91796875 respectively. This way, the scaling is preserved - 0.0625 * 65536 = 4096 and 0.91796875 * 65536 = 60160.
You may be better off using rational pairs (like FPS is done with numerator and denominator) to store this concept. This lets you store the exact values and do any required rounding at the time you implement them some time later. Once rounding is done it cannot be undone.


Edit 2: The solution dawned on me just as I type this. The value will not be represented as a fraction of the maximum value, but that of /one above it/ (eg. the range limit).This might be better expressed as the number of values in the range, i.e. [0..255] has 256 values, [16..235] has 220 values.

[nand chan]

You may be better off using rational pairs (like FPS is done with numerator and denominator) to store this concept. This lets you store the exact values and do any required rounding at the time you implement them some time later. Once rounding is done it cannot be undone.

This might be a good idea, the only issue I see here is an implementation issue: If you have some arbitrary value limit, how would you compute the best matching fraction (unless you allow floating point fractions as well)?

For example, say I have some 32-bit LUT with value limits of, I dunno, 0.19439583945 and 0.938593485 - you'd have to generate some sort of integer fraction pair for those and the process for that might as well introduce more rounding inaccuracies than the process of storing a floating point value.

Also, you have to realize that technically, floating points are themselves just a collection of fractions, eg. 1/4 + 1/8 + 1/16 = 0.4375.

And with 64-bit precision the difference between storing the value and computing the value at runtime will be negligible.

This might be better expressed as the number of values in the range, i.e. [0..255] has 256 values, [16..235] has 220 values.

I don't see how that would get us anywhere, elaborate?

[IanB]

This might be a good idea, the only issue I see here is an implementation issue: If you have some arbitrary value limit, how would you compute the best matching fraction (unless you allow floating point fractions as well)?

For example, say I have some 32-bit LUT with value limits of, I dunno, 0.19439583945 and 0.938593485 - you'd have to generate some sort of integer fraction pair for those and the process for that might as well introduce more rounding inaccuracies than the process of storing a floating point value.

Also, you have to realise that technically, floating points are themselves just a collection of fractions, eg. 1/4 + 1/8 + 1/16 = 0.4375.

And with 64-bit precision the difference between storing the value and computing the value at runtime will be negligible.
Yes, floating point numbers are built from fractions of the form 1/2^n so only fractional values that have a last decimal digit of 5 after the point can be exactly represented, and then only within the available precision of the mantissa. But yes it is still a very good representation of the value.

Using rational pair to store a value is a way of never actually doing the divisions in the calculation of the value, thus never having a rounding issue.

If you are always just plonking pre-calculated decimal values into the LUT header then you gain nothing and you might as well use a double.

However if the values are calculations resulting in a normalised (a+b/c) result then rational pairs have a lot to offer.


For your 2 example number with simple normalising and also approximated with continued fractions limited to your last digit :-

0.19439583945 = (3887916789/20000000000) ~ (231749/1192150) = 0.19439583944973

0.938593485 = (187718697/200000000) ~ (106811/113799) = 0.938593485004

Of course I don't know your original calculation, I am working with what appears as an already rounded double result. The true result maybe a much simpler rational pair.

Some rational pairs for PI are 22/7, 333/106, 355/113


This might be better expressed as the number of values in the range, i.e. [0..255] has 256 values, [16..235] has 220 values.
I don't see how that would get us anywhere, elaborate?For the original idea you were expressing, the justification to use 256 and 220 as the divisors in your specification were that they are the count of unique values in the range not the range limit, e.g. which would be 236 for the [16.235] subset.

[nand chan]

Yes, floating point numbers are built from fractions of the form 1/2^n so only fractional values that have a last decimal digit of 5 after the point can be exactly represented, and then only within the available precision of the mantissa. But yes it is still a very good representation of the value.

Using rational pair to store a value is a way of never actually doing the divisions in the calculation of the value, thus never having a rounding issue.

Negligible since the calculations of the value will be performed millions of times during both generation and usage either way - even if you /could/ store some theoretically perfect fraction it would offer no single usage case.

If you are always just plonking pre-calculated decimal values into the LUT header then you gain nothing and you might as well use a double.

The only situations in which you /wouldn't/ want to put a pre-calculated value into the header is for the Full range situation (0-1), but both 0 and 1 can be accurately represented as a double. Everything else will be implicitly tied to the generation, whether it's during gamut mapping using ICC profiles, or yCMS' 64 bit creation, or even simple I=O mapping (pulldown and pullup get performed regardless to transfer the values from an 8-bit range to a 16-bit range, for example - so precision is lost)

You have to remember also we are dealing with color here and the difference between, say, 0.123456789 and 0.123456788 approximates to a difference in XYZ of <0.0000001, even after gamma pullup and mapping.

However if the values are calculations resulting in a normalised (a+b/c) result then rational pairs have a lot to offer

Such exact calculations are not performed here and are in the realm of mathematical accuracy implementations, not color management.

Even if you could achieve such results after /one/ step of the operation (eg. pulldown/pullup which will indeed get calculated as an a + b*c or (a-b)/c triple, storing them that way would be detrimental to both storage space and calculation speed - the point of .3dluts is to pre-calculate everything already so the resulting program just has to run the values through.

For your 2 example number with simple normalising and also approximated with continued fractions limited to your last digit :-

0.19439583945 = (3887916789/20000000000) ~ (231749/1192150) = 0.19439583944973

0.938593485 = (187718697/200000000) ~ (106811/113799) = 0.938593485004

Of course I don't know your original calculation, I am working with what appears as an already rounded double result. The true result maybe a much simpler rational pair.

Some rational pairs for PI are 22/7, 333/106, 355/113

For the original idea you were expressing, the justification to use 256 and 220 as the divisors in your specification were that they are the count of unique values in the range not the range limit, e.g. which would be 236 for the [16.235] subset.

Yes, I understood that much, it's just that I'm wondering what dividing by the count of values would achieve - the point of dividing by 256 in the first place is so you can express the range limits - if you divide by some factor of that range in the first place then the point is destroyed - we would end up with a situation where every range limit turns out to be 1.0 (or every value from 0-1 plus some number (base/lim)).

Unless you are suggesting that we define the divisor as the amount of unique values within the integer range we are representing (and not the value range), in which case that's just expressing the same thing using different words (and would pose a problem to floating point values).

Also, I'm considering removing the whole variable-range proposal in the first place, since it complicates implementations - a true implementation will now have to perform an addition, a subtraction, a multiplication and a division for each components of each pixel of each frame - four things that would previously all not have been necessary.

The point of .3dluts was to be to pre-calculate values, so I'm wondering why re-calculation should be necessarily - .3dluts should be simple look up tables.

The original idea for the variable range limits was to fix a problem that never existed (and indeed, introducing variable ranges didn't fix the problem either - I had forgotten that the range gets normalized within the pipeline either way).

And lastly, the only situation in which flexible range limits would be of benefit is for adjustable white and black levels - and for those, a normalized, full range floating point .3dlut would be ideal, since you can just express, say, 1.15 easily.

Edit: I've also slightly rewritten my copy of the 3DL2 proposal to remove the distinction between R/G/B or Y/Cb/Cr - calculations are now simply performed as “A, B and C” and are unaware of their own encoding, the encoding type determines which channel means what. Encoding = 0 means “BGR”, so A = Blue, B = Green and C = Red.

[nand chan]

I've removed the silly variable ranges again, here is my current copy:

________________________________________________________________________________

3DL2 file format specification
________________________________________________________________________________

enum {PAGE_SIZE = 16384};
struct H3DLUT2
{
byte signature[4]; // file signature; must be: “3DL2” as encoded using the ASCII standard (0x33444C32)
int fileVersion; // file format version number (currently 2)
byte programName[32]; // name of the program that created the file
long programVersion; // version number of the program that created the file
int inputBitDepth[3]; // input bit depth per component (Y,Cb,Cr or B,G,R)
int inputColorEncoding; // input color encoding standard (0 = BGR, 1 = YCbCr)
int inputValueRange; // value range for the input (0 = Full range (0-255), 1 = Limited (16-235)) [up to v1]
int outputBitDepth; // output bit depth for all components (valid values are 8, 16, 32 and 64)
int outputColorEncoding; // output color encoding standard (0 = BGR, 1 = YCbCr, 2 = XYZ)
int outputValueRange; // value range for the output
int parametersFileOffset; // number of bytes between the beginning of the file and array 'parametersData'
int parametersSize; // size in bytes of the array 'parametersData'
int lutFileOffset; // number of bytes between the beginning of the file and array lutData
int lutCompressionMethod; // type of compression used if any (0 = none, 1 = LZO, ...)
int lutCompressedSize; // size in bytes of the array 'lutData' inside the file, whether compressed or not
PRIMARIES inputColorSpace; // Input color space - this section is strictly optional,
// a value of 0 for all means “disabled/unknown”
PRIMARIES outputColorSpace; // Output color space - the same rules apply as for input color space.
// In addition, if the output is XYZ, this section is to be set to 0 for all values

// This header is followed by the byte array 'parametersData', of length 'parametersSize',
// and by the array 'lutDataxx', of length 'lutCompressedSize'.
};
struct PRIMARIES
{
double primaryRedx; // The x and y refer here to the coordinates on the CIE xy chromaticity diagram,
double primaryRedy; // Y is assumed to be 1.0 for these primaries
double primaryGreenx;
double primaryGreeny;
double primaryBluex;
double primaryBluey;
double primaryWhitex;
double primaryWhitey;
};
byte parametersData[1];
union LUTDATA
{
byte lutData8[1];
ushort lutData16[1];
float lutData32[1];
double lutData64[1];
};
// The array 'parametersData' starts 'parametersFileOffset' bytes after the beginning of the file.
// The array 'lutDataxx' starts 'lutFileOffset' bytes after the beginning of the file.
// When creating a 3DLUT2 file, 'lutDataxx' should be positioned on a 16384 byte boundary.
//
// parametersData - byte array with size 'parametersSize' that contains an exact copy of the
// input file with the commands and settings used for creating the 3DLUT2 file
//
// lutDataxx - array with size lutSizeUncompressed that contains the 3D LUTs output values.
// The type used depends on the outputBitDepth field:
// - unsigned byte, if outputBitDepth = 8
// - unsigned short, if outputBitDepth = 16
// - float, if outputBitDepth = 32
// - double, if outputBitDepth = 64
//
// The value ranges are assumed to be as follows:
// Full range (integers): 0 to (2∧depth)−1, for example 0–255 and 0–65535
// Full range (floats): 0 to 1
// Limited range (integers): 16–235, left/right shifted to the correct bit depth, eg. 4096–60160)
// Limited range (floats): (16÷255)≈0.06275 to (235÷255)≈0.92157.
//
// For XYZ output:
// XYZ must be appropriately normalized so that the luminosity of white = the range limit.
// eg. for limited range 8-bit output, the luminosity of white would be 235. If the value range is full range,
// this would mean that the values are essentially capped to 255. As such, using limited range for XYZ is
// preferable for integer output. It is strongly recommended that one uses full range floats for XYZ however,
// where the luminosity of white would be normalized to 1.0
//
// The offset inside the array is calculated as:
// offset = (A + B << (inputBitDepth[0]) + C << (inputBitDepth[1]+inputBitDepth[0])) × 3
//
// The output order inside the array is:
// A = lutDataxx[offset]; B = lutDataxx[offset+1]; C = lutDataxx[offset+2]
//
// A, B and C refer to the respective channels of the used encoding (eg. B, G, R or Y', Cb, Cr)
//
// The lutUncompressedSize of the array is calculated as:
// lutDim = 3 × 2∧inputBitDepth[0] × 2∧inputBitDepth[1] × 2∧inputBitDepth[2] × outputBitDepth÷8
//
// This specification assumes:
// byte = 1 byte; short = 2 byte; int = 4 byte; long = 8 byte; // integers
// float = 4 byte; double = 8 byte; // floating point numbers
//
// << is used to denote an arithmetic left shift operator. Where strict/large inequality is wanted, ≪ is used.

[leeperry]

I might consider creating a bigger ramdisk and use 16bit YUY2 LUT's instead of 8bit, but why is t3dlut() so much more power hungry than rgb3dlut() again? :o
hi tritical, if you're still around: is there any way you could provide a way to apply 16bit LUT's w/ the same CPU load as rgb3dlut() please? t3dlut() is a CPU hog :/