CineStyle(flat picture style) Lut corrected in Avisynth

[tin3tin]

Cinestyle LUT correction Avisynth script (using Gradation(vdub plugin) for making the amp curve and GiCoCU.dll to import it into Avisynth):
http://download.videohelp.com/tin2tin/Cinestyle_Lut_corrected_script.zip
Unzip the inclosed files, add some video/image to the script and use it on photos/video shot with DSLR cameras using the CineStyle flat picture style.

About CineStyle: http://blog.vincentlaforet.com/2011/04/29/technicolor-cinestyle-profile-available-for-canon-5dmkii/

The tutorial I followed: http://zech-fstop.blogspot.com/2011/05/using-technicolors-lut-file-without-lut.html

[cretindesalpes]

Another solution, preserving dark shades better because of the 16-bit processing:

Function correct_cinestyle (clip c)
{
c
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y")
a = "0.05"
x1 = "x 32768 - 32768 /"
x2 = x1 + " 1.5 * " + x1 + " 3 ^ 0.5 * -"
x3 = x2 + " 1 " + a + " + * " + x2 + " 3 ^ "+ a +" * -"
Dither_lut16 (x3 + " 32768 * 32768 +", y=3, u=1, v=1)
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0),
\ SelectEvery (3, 1),
\ SelectEvery (3, 2),
\ matrix="601", lsb=false, mode=6)
}

Curve fitting (http://screenshotcomparison.com/comparison/88034)

[tin3tin]

@ cretindesalpes
Very interesting solution! Completely out of my league. :) Will try it out.

BTW. With your insights does this description of fixing moire make any sense to you?
It blurs the chroma channels of the YCbCr signal (YUV219). If you would call this (wrongly) Y’UV, this would mean blurring the UV part of the signal.
Blur the Cr channel somewhat heavier than the Cb channel while trying to avoid a shift to green – so not to disturb the whitepoint too much. There is some math involved that you can read about here: http://en.wikipedia.org/wiki/YCbCr

From:
http://colorbyjorg.wordpress.com/2011/02/17/now-available-my-dslr-anti-moire-filter-for-fcp-free-download/

Do you think it is possible to replicate that process in Avisynth?

[cretindesalpes]

Do you think it is possible to replicate that process in Avisynth?
From his description, it sounds like:
RemoveGrain (0, 11, 11)
RemoveGrain (0, 0, 11)
Maybe with different blur radius or strength. Without masking it may cause important discoloration, too. Anyway I don't know how effective it would be to remove this kind of moiré.

[tin3tin]

Theres an image for testing that here:
http://www.komar.org/faq/camera/auto-focus-test/micro-auto-focus-test-2.gif

I don't see any differences with the removegrain you mentioned.

[tin3tin]

Played around with the settings(haven't read the docs yet). This seems to be an improvement on the moire, however there is a colorshift(left=original and right = RemoveGrain):
RemoveGrain (0, 11, 11)
RemoveGrain (11, 0, 0)
http://download.videohelp.com/tin2tin/Moire.png

[cretindesalpes]

I don't see any differences with the removegrain you mentioned.
Indeed, the author explicitly mentioned that it blurs only the chroma. So it won't make any difference on a black and white picture. The filter was designed for real-life scenes and artifacts generated by a specific camera.

[tin3tin]

The settings I came up with does add blur. Gotta try with some Canon DSLR shots with micro-moire.

Another test image(photo):
http://www.dcresource.com/reviews/canon/eos_20d-review/IMG_0312.JPG

RemoveGrain (0, 11, 11)
RemoveGrain (11, 0, 0)
This seems to have a positive effect on the moire - however the image does get more blured.

[LaTo]

The settings I came up with does add blur. Gotta try with some Canon DSLR shots with micro-moire.

Another test image(photo):
http://www.dcresource.com/reviews/canon/eos_20d-review/IMG_0312.JPG

RemoveGrain (0, 11, 11)
RemoveGrain (11, 0, 0)

This seems to have a positive effect on the moire - however the image does get more blured.
Your RemoveGrain are wrong, you should only process chroma.
So always leave the first number to 0.

Moreover, your call can be replaced by RemoveGrain(11)...

[Yellow_]

Another solution, preserving dark shades better because of the 16-bit processing:

Function correct_cinestyle (clip c)
{
c
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y")
a = "0.05"
x1 = "x 32768 - 32768 /"
x2 = x1 + " 1.5 * " + x1 + " 3 ^ 0.5 * -"
x3 = x2 + " 1 " + a + " + * " + x2 + " 3 ^ "+ a +" * -"
Dither_lut16 (x3 + " 32768 * 32768 +", y=3, u=1, v=1)
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0),
\ SelectEvery (3, 1),
\ SelectEvery (3, 2),
\ matrix="601", lsb=false, mode=6)
}

Curve fitting (http://screenshotcomparison.com/comparison/88034)

Although 16bit it still involves a conversion to RGB, could the sGradation approach be used in dither in order to do it YV12 or YUY2?, http://avisynth.org/mediawiki/SGradation

Using those photoshop .amp's and the GiCoCU.dll is all 8bit RGB and therefore not very desirable.

[sonu patel]

great one but can u tell me about how to put white blance colour setting .....

[Boulotaur2024]

Although 16bit it still involves a conversion to RGB, could the sGradation approach be used in dither in order to do it YV12 or YUY2?, http://avisynth.org/mediawiki/SGradation

Using those photoshop .amp's and the GiCoCU.dll is all 8bit RGB and therefore not very desirable.
This is a valid question I was wondering the same... I guess the SGradation can *only* be applied to RGB, hence the required convertion ?

I just used CretinDesAlpes function and it does wonder indeed but I have no clue about the syntax and reverse polish notation gives me headache... Could you elaborate a little bit more on it CretinDesAlpes, if you have time ?

[cretindesalpes]

It computes the following formulas:
a = 0.05
x1 = (x - 32768) / 32768 ; x1 in -1...1
x2 = 1.5 * x1 - 0.5 * x1^3 ; 1st S curve
x3 = (1 + a) * x2 - a * x2^3 ; 2nd S curve
y = x3 * 32768 + 32768 ; Back to 0...65535
First formula converts x from 0–65535 range to -1–+1.
Second formula is the main S curve, keeping x2 in the same range as x1.
Third formula is a second S curve, because the first curve was not enough. The formula is actually the same as the main one, but with a smaller curvature coefficient (0.05 instead of 0.5).
Finally, the fourth formula converts the value back to the 16-bit scale.

Given the CineStyle doc and the provided LUT, the curve works on RGB components, however it's not very clear if they are linear or gamma-compressed. I'd say it's most likely the latter. Working on the Y' signal would not give the expected results.

[Yellow_]

The LUT is almost certainly applied to gamma compressed data in RGB, the NLE having first squeezed the full range luma levels off the Canon DSLR's into 16 - 235 and the RGB conversion based on that, which is the 'correct' approach in NLE land.

However I'm currently using 32 point '16bit' curve with SmoothCurve16 from SmoothAdjust plugin on the luma channel only, it gives results I'm happy with compared to applying curve to all channels in RGB but a mathmatical approach of correct_cinestyle even better. :-)

Thanks for the correct_cinestyle function, that's neat, will now compare against SmoothAdjust luma only approach based on the RGB route above being correct, how far Y only approach is 'off' although its all subjective, Cinestyle is about capturing data efficiently in camera as best that it can be in 8bit not necessarily tgen applying this curve to give a more typical rec709 appearance.

**EDIT**

I see a lot of gaps in the luma waveform at regular intevals (vertical in case of histogram function) showing some scaling is going on. i don't see this when using SmoothCurve16 and the 32 point curve as the name suggests smoothing via interpolating values is going on to help reduce the gaps.

Needed to add tv_range=false to both color space conversions in order to 'keep' full range luma that is in the original camera files but gaps are still there. :-(

SmoothCurve16 Custom offers ability to mathmatically define a curve so is it possible to combine the two to reduce/remove gaps?

**EDIT**

Testing the 32 point SmoothCurve16 's' curve I have with a few cinestyle videos, by applying it to Y Cb & Cr channels and checking the output with ColorYUV(analyze=true) gives me identical results to cinestyle_correct but without the gaps in the luma channel so it would appear convertion to RGB and back is unnecessary.

I'd kind of already concluded that as the Y only curve gave a better desaturated image for grading with but it is great to be able to test against the cinestyle_correct to confirm that.

I'd assumed from comparing with ColorYUV, Cinestyle with same shot conditions just in other flat camera profiles, that the majority of difference between using Cinestyle (log) and a more typical 'flat' picture style (Linear) was really in the greyscale anyway. And if that's the case using SmoothTweak16 on the Cb&Cr before affecting the luma, which is how I'm currently doing it, so the combined effect can be seen in RGB preview ala AVSPmod, gives more color tweak control.

[Yellow_]

Just revisiting this thread and having problem with correct_cinestyle function, getting an error about mtlutxy unsupported color space Masktools only supports Planar YUV, Dither avs line 1022.

Simply feeding it a ffmpegsource decompressed h264 file, to my knowledge I have masktools v20a48 being used.

[Yellow_]

Sorry, I'm sorted, I've been swapping machines about recently and the one I'm using had Avisynth 2.6 alpha not 2.5, even though I tried the -26 version of masktools but got the green screen, obviously something else was not right with the plugins loaded.