>8bit (AVIsynth+) linear/gamma light aware resizing?

[Stereodude]

Are there any >8bit AVIsynth+ capable resizer plugins that work in linear/gamma light?

Basically something like ResampleHQ, but capable of bit depths greater than 8-bits.

[poisondeathray]

One way is avsresize / zimg / z.lib
https://forum.doom9.org/showthread.php?t=173986

I think dither tools is another option

[Stereodude]

One way is avsresize / zimg / z.lib
https://forum.doom9.org/showthread.php?t=173986
Thanks, is there some additional documentation explaining the filter arguments in greater detail than what's in the OP of that thread?

[poisondeathray]

Thanks, is there some additional documentation explaining the filter arguments in greater detail than what's in the OP of that thread?

There is some more info in the vapoursynth docs, under "resize"
http://www.vapoursynth.com/doc/functions/resize.html

[real.finder]

I think dither tools is another option

there are this too https://forum.doom9.org/showthread.php?p=1836924#post1836924 same as dither method but with native HBD

[Stereodude]

there are this too https://forum.doom9.org/showthread.php?p=1836924#post1836924 same as dither method but with native HBD
HBD = High Bit Depth?

[poisondeathray]

there are this too https://forum.doom9.org/showthread.php?p=1836924#post1836924 same as dither method but with native HBD

Can you double check this method r.f ?

Results differ from say, resamplehq, or avsresize, or z.lib vapoursynth linear scaling . Noticable in the eyes

e.g. you can use this test image as src , eg. width/8, height/8

https://upload.wikimedia.org/wikipedia/commons/8/85/Calliphora_sp_Portrait.jpg

[real.finder]

HBD = High Bit Depth?

yes

Can you double check this method r.f ?

Results differ from say, resamplehq, or avsresize, or z.lib vapoursynth linear scaling . Noticable in the eyes



how you use it? you must use it only with native 16 bit in avs+, and you must have the last masktools2

anyway if the dither method (http://avisynth.nl/index.php/Dither_tools#Dither_y_gamma_to_linear.2C_Dither_y_linear_to_gamma) give you same results then that it, if not then check your usage and plugins

[poisondeathray]

how you use it? you must use it only with native 16 bit in avs+, and you must have the last masktools2

anyway if the dither method (http://avisynth.nl/index.php/Dither_tools#Dither_y_gamma_to_linear.2C_Dither_y_linear_to_gamma) give you same results then that it, if not then check your usage and plugins

Avisynth+ r2664-MT
masktools 2.2.14

I just copy-pasted your post
https://forum.doom9.org/showpost.php?p=1836924&postcount=13

Proper linear scaling should avoid gamma error so your script results are unexpected

e.g.
dalai lama
http://i67.tinypic.com/33k7rf4.jpg
(image host changed file name, but here is a mirror)
http://www.mediafire.com/file/u2ldnujoqv9j59o/gamma_dalai_lama_gray.jpg


ImageSource("gamma_dalai_lama_gray.jpg")
converttoyv24
convertbits(16)
y_gamma_to_linear
Spline36Resize(width/2,height/2)
y_linear_to_gamma
convertbits(8)



left is what I get from your script , right is what I get from float linear scaling with zimg in vpy (you get similar results on the right with other programs that high bit depth linear operations, like AE. Also ResampleHQ at 8bit in avisynth, and ResampleHQ at 16bit or float in vapoursynth, avsresize in avisynth+ at 16bit or float)

(this is back down to 8bit RGB for the screenshot)
http://i63.tinypic.com/2afd8on.png

I did not check dither tools yet, but linear, gamma aware scaling should result in something like the right side

[poisondeathray]

I think the reason is those dither functions don't touch Cb,Cr


Dither_y_gamma_to_linear converts the luma channel to linear light, and Dither_y_linear_to_gamma converts back a clip to gamma-corrected luma. The chroma channels remain untouched.

[real.finder]

Avisynth+ r2664-MT
masktools 2.2.14

I just copy-pasted your post
https://forum.doom9.org/showpost.php?p=1836924&postcount=13

Proper linear scaling should avoid gamma error so your script results are unexpected

e.g.
dalai lama
http://i67.tinypic.com/33k7rf4.jpg
(image host changed file name, but here is a mirror)
http://www.mediafire.com/file/u2ldnujoqv9j59o/gamma_dalai_lama_gray.jpg


ImageSource("gamma_dalai_lama_gray.jpg")
converttoyv24
convertbits(16)
y_gamma_to_linear
Spline36Resize(width/2,height/2)
y_linear_to_gamma
convertbits(8)



left is what I get from your script , right is what I get from float linear scaling with zimg in vpy (you get similar results on the right with other programs that high bit depth linear operations, like AE. Also ResampleHQ at 8bit in avisynth, and ResampleHQ at 16bit or float in vapoursynth, avsresize in avisynth+ at 16bit or float)

(this is back down to 8bit RGB for the screenshot)
http://i63.tinypic.com/2afd8on.png

I did not check dither tools yet, but linear, gamma aware scaling should result in something like the right side

try this

ImageSource("E:\gamma_dalai_lama_gray.jpg")
Interleave(ExtractR,ExtractG,ExtractB)
convertbits(16)
y_gamma_to_linear
Spline36Resize(width/2,height/2)
y_linear_to_gamma
convertbits(8)
MergeRGB(SelectEvery(3, 0), SelectEvery(3, 1), SelectEvery(3, 2))

the dither not work for me for those images but anyway that what the Documentation said

Dither_y_gamma_to_linear converts the luma channel to linear light, and Dither_y_linear_to_gamma converts back a clip to gamma-corrected luma. The chroma channels remain untouched.

This function works only on 16-bit stacked clips.

Note: usually gamma compression applies to RGB channels, not Y’CbCr. Therefore this function should be used with RGB48Y clips, obtained from Dither_convert_yuv_to_rgb for example.

[real.finder]

I think the reason is those dither functions don't touch Cb,Cr

you post that while I test, but yes, that it, don't know if it a good idea if it used in chroma the same way as luma

[poisondeathray]

That's looks more correct now. But the various methods produce slightly different results, not sure why (ie. this, avsresize, resamplehq (either at 8bit in avs, or higher in vpy) , or zlib in vpy)

avsresize / zlib

ImageSource("E:\gamma_dalai_lama_gray.jpg")
ConvertToPlanarRGB()
z_ConvertFormat(resample_filter="spline36", pixel_type="RGBPS", colorspace_op="rgb:srgb:709:f=>rgb:linear:709:f")
z_ConvertFormat(width/2, height/2, resample_filter="spline36", pixel_type="RGBPS", colorspace_op="rgb:linear:709:f=>rgb:linear:709:f")
z_ConvertFormat(resample_filter="spline36", pixel_type="RGBP", colorspace_op="rgb:linear:709:f=>rgb:srgb:709:f")

[poisondeathray]

you post that while I test, but yes, that it, don't know if it a good idea if it used in chroma the same way as luma

yes, this seems incorrect to me

[TheFluff]

That's looks more correct now. But the various methods produce slightly different results, not sure why (ie. this, avsresize, resamplehq (either at 8bit in avs, or higher in vpy) , or zlib in vpy)

avsresize / zlib

ImageSource("E:\gamma_dalai_lama_gray.jpg")
ConvertToPlanarRGB()
z_ConvertFormat(resample_filter="spline36", pixel_type="RGBPS", colorspace_op="rgb:srgb:709:f=>rgb:linear:709:f")
z_ConvertFormat(width/2, height/2, resample_filter="spline36", pixel_type="RGBPS", colorspace_op="rgb:linear:709:f=>rgb:linear:709:f")
z_ConvertFormat(resample_filter="spline36", pixel_type="RGBP", colorspace_op="rgb:linear:709:f=>rgb:srgb:709:f")


There's probably plenty of room for different rounding methods and the like. zimg also uses slightly different numeric constants for linearizing sRGB than resampleHQ does, motivated by the cryptic comment (https://github.com/sekrit-twc/zimg/blob/master/src/zimg/colorspace/gamma.cpp#L21) "adjusted for continuity of first derivative". zimg also has a parameter called "allow approximate gamma" which is enabled by default these days to speed up processing - when it's enabled, it'll use a LUT rather than runtime floating point arithmetic for gamma calculations.

Without having tested it at all, I'd rate zimg's chances of being closest to "correct" as highest out of the proposed alternatives - it's had a lot of effort put into the maths.

[poisondeathray]

There's probably plenty of room for different rounding methods and the like. zimg also uses slightly different numeric constants for linearizing sRGB than resampleHQ does, motivated by the cryptic comment (https://github.com/sekrit-twc/zimg/blob/master/src/zimg/colorspace/gamma.cpp#L21) "adjusted for continuity of first derivative". zimg also has a parameter called "allow approximate gamma" which is enabled by default these days to speed up processing - when it's enabled, it'll use a LUT rather than runtime floating point arithmetic for gamma calculations.

Without having tested it at all, I'd rate zimg's chances of being closest to "correct" as highest out of the proposed alternatives - it's had a lot of effort put into the maths.



I think so too . It looks similar to what other programs use when using linear scaling (eg. AE), if you take into account the algorithm and scaling center (e.g spline36 vs xx, MPEG2 vs. MPEG1). The original 8bit ResampleHQ avs version looks very close too, but the vpy port looks off at RGBS and 16bit.

For zimg, the vpy version has the 'cpu_type="none"' switch, which skips the LUT speed up shortcuts when using zimg operations

[poisondeathray]

fmtc in vapoursynth produces very similar results too , so I'm more inclined to believe it's correct

fmtc is Dither tools' "brother" in vapoursynth by the same author. The avisynth version is missing a few things including the transfer function. It would need to be updated for this to work in avisynth with dither tools. But I think Firesledge (aka Cretindesalpes) is "retired" from AV stuff ? Anyone know his status ? Maybe off having a coffee with didee ? :D

[FranceBB]

The avisynth version is missing a few things including the transfer function. It would need to be updated for this to work in avisynth with dither tools.

I too think that having them included in DitherTools and working in plain Avisynth would be extremely useful. I hope someone will manage to find time to update Dither Tools.

[Stereodude]

There is some more info in the vapoursynth docs, under "resize"
http://www.vapoursynth.com/doc/functions/resize.html
Do you understand the dither_type argument? I see from examples posted in other threads that "none" and "ordered" are valid. Are those the only two options?

Also, I'm a little puzzled by the colorspace_op="rgb:srgb:709:f=>rgb:linear:709:f" argument.

Format is: "matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"

How would I know how to construct the argument for a given operation? I get the primaries. I'm not very clear on the Matrix coefficient and the Transfer characteristic.


If I just want to resize rec.709 YUV 1920*x a lower res using catmull rom I need multiple steps like you did in post #13? (https://forum.doom9.org/showpost.php?p=1840942&postcount=13) right?

I'm guessing I need mutiple lines since I need to convert to Linearized RGB, resize, and then convert back since this plugin doesn't seem to do it in a single step. Can you give me an example for rec.709 video?

Is it like this?
z_ConvertFormat(resample_filter="bicubic", filter_param_a=1/3, filter_param_b=1/3, pixel_type="RGBPS", colorspace_op="709:709:709:f=>rgb:linear:709:f", dither_type="ordered")
z_ConvertFormat(1280, 544, resample_filter="bicubic", filter_param_a=1/3, filter_param_b=1/3, pixel_type="RGBPS", colorspace_op="rgb:linear:709:f=>rgb:linear:709:f")
z_ConvertFormat(resample_filter="bicubic", filter_param_a=1/3, filter_param_b=1/3, pixel_type="YUV420P10", colorspace_op="rgb:linear:709:f=>709:709:709:f", dither_type="ordered")

[poisondeathray]

Do you understand the dither_type argument? I see from examples posted in other threads that "none" and "ordered" are valid. Are those the only two options?


I think it's the same as vapoursynth. I posted the link above
http://www.vapoursynth.com/doc/functions/resize.html

dither_type:

Dithering method. Dithering is used only for conversions resulting in an integer format. The following

dithering methods are available: none, ordered, random, error_diffusion.





Also, I'm a little puzzled by the colorspace_op="rgb:srgb:709:f=>rgb:linear:709:f" argument.

Format is: "matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"

How would I know how to construct the argument for a given operation? I get the primaries. I'm not very clear on the Matrix coefficient and the Transfer characteristic.


matrix is only relevant for color model/colorspace conversions, so YUV<=>RGB conversions . In the example able, it was RGB or "identity" matrix .



If I just want to resize rec.709 YUV 1920*x a lower res using catmull rom I need multiple steps like you did in post #13? (https://forum.doom9.org/showpost.php?p=1840942&postcount=13) right?



Yes you have to split it out, same for vapoursynth using zimg/z.lib . FMTC (dither tool's "big" brother) alos requires splitting out operations. But you might be able to write a wrapper function to simplify things



I'm guessing I need mutiple lines since I need to convert to Linearized RGB, resize, and then convert back since this plugin doesn't seem to do it in a single step. Can you give me an example for rec.709 video?


Is it like this?


Not sure, have to look at it more closely , test on some pattern/test videos

[Stereodude]

I think it's the same as vapoursynth. I posted the link above
http://www.vapoursynth.com/doc/functions/resize.html
Thanks, I swear I looked at that before asking. Somehow I overlooked it.