Gamma-aware, dithered colorspace conversion and resizing

[infoeater]

Sorry for delay and thank you for your explanations Asmodian.

So ResampleHQ ignore (small) gamma differences between BT.709 and sRGB and use sRBG coefficients and gamma for its internal linear colorspace?

High-end consumer video cameras (~1000 USD) often offer really very good calibration to BT.709. In fact it's often only limited by color accuracy of the sensor and cannot be improved in automatic postprocessing. There are some tests at http://www.camcorderinfo.com/. Consumer TV's on the other hand offer usually poor calibration (because many customers like oversaturated colors and cold (high Kelvin) white point), which can be improved, manually by calibration in higher models.

Canon PowerShot SD950 IS use BT.601 for its videos.

Panasonic and Sony consumer camcorders offer "http://en.wikipedia.org/wiki/XvYCC" as an option, which can be disabled in menu.
It is compatible with BT.709, just allows values out of range that define extra colors. It is possible to disable it, because normally camera tries to convert such colors to colors in range, allowing better perceived color accuracy on displays not supporting xvYCC.

BTW I am interested how ResampleHQ will handle out of range xvYCC colors when resizing TV.709 to TV.709? Will it lose them somewhere in it's internal color space?

[Asmodian]

Yes, ResampleHQ uses sRGB gamma for its linear color space but I am sure it would be impossible to tell the difference after converting back.

I believe all color space conversions done in Avisynth, including ResampleHQ's, use "absolute" color conversions. Any out of range colors are clamped to the nearest valid color. However ResamplesHQ's internal color space is in 32-bit float and any clamping occurs at the final conversion to TV.709.

[Rant]It is good to know cameras actually try for accurate colors. I wonder if/when Windows will ever be gamut aware. The thumbnail generator in Windows 7 is color space aware, a photo tagged as anything but sRGB is converted to sRGB, but not the rest of the OS and it cannot use a calibrated color space instead of sRGB. This means wide gamut displays are bad, not just useless, for anything but a Mac or Photoshop type work. I also really hate all the "fluid motion" features and similar that new TVs have but they cannot get the color even close to correct. Why are all the new Android tablets and phones using 60% of sRGB's gamut and a 7500K+ white point?! What is the point of a 1920x1200 10" screen if not image quality?[/Rant]

Sorry about the rant, I couldn't stop myself.

[active1]

how could i know that my image is linear and i need a gamma-correction?

[Asmodian]

Images are never in linear light, they all have a gamma curve (I am sure there are formats which use linear light, but no consumer ones do). At 8 bits per sample linear light is a bad idea as there aren't enough steps in the black/dark grey and too many in the almost white. It is good ResampleHQ uses 32bits for its linear color space. Using linear light when resizing to a smaller resolution allows for a more "optically correct" resize but you never leave the image in linear light for display.

ResampleHQ is not for doing gamma conversions, just resizing.

[active1]

Originally Posted by Asmodian

Images are never in linear light, they all have a gamma curve (I am sure there are formats which use linear light, but no consumer ones do). At 8 bits per sample linear light is a bad idea as there aren't enough steps in the black/dark grey and too many in the almost white. It is good ResampleHQ uses 32bits for its linear color space. Using linear light when resizing to a smaller resolution allows for a more "optically correct" resize but you never leave the image in linear light for display.

so when i need to do gamma-correction?
plus i tried ResampleHQ on different images, and i didn't see much different from the other avisynth resizers, but in the earth light image (which is included with resamplehq-x86.dll) the difference was clear

[ajp_anton]

When you have small bright spots or thin lines with sharp high contrast edges, "normal" resizers tend to lower that contrast a bit.


Say the resizer needs to average a bright spot with intensity 1 with a dark background with intensity 0.
"Normal" resizers will simply average this to 0.5, which becomes the new brightness of this bright spot.
Obviously it should get darker when you downsize, but not this much.

Converting to linear light (value^2.2): both 1 and 0 stay as they are. Average = 0.5.
Inverting the previous conversion on this value: 0.5^(1/2.2) = 0.73, which is brighter than 0.5, and is what your eyes would actually see in the real world.

The gamma-curved representation of pixel light intensities doesn't represent actual light intensity, so averaging pixels here doesn't give correct results. It does however work as a good enough approximation in most real-life scenarios.

[Asmodian]

Originally Posted by active1

so when i need to do gamma-correction?

Only when wanting to view content on a display with a different gamma than intended but that isn't related to ResampleHQ.

[TheElix]

Is this script meant for real-time usage (for watching videos with)?

[Asmodian]

This isn't a script, just a plugin, but it is fast enough to run real time. I am not sure why you would though, MadVR offers linear-light options for resizing at playback.

Also resizing in linear light is most important when resizing to a smaller resolution which is (I assume) rarely done at playback.

[pancserzso]

Hi,

I'm trying to import a AVCHD file using ffms2 from a Panasonic GH2 camera, which is 4:2:0. I'm looking for the best possible quality. Can you help me which of these are the best?

Is there any point using this plugin when there is no resolution resize, just chroma YV12 -> RGB conversion and Chroma upsample?

Color conversion by FFVideoSource:

FFVideoSource( "mts.mts", seekmode = -1, colorspace = "RGB24", resizer = "LANCZOS" )

Color conversion by AviSynth 2.60:

FFVideoSource( "mts.mts", seekmode = -1 )
ConvertToRGB24( matrix = "Rec709", chromaresample = "lanczos" )

Color conversion by ResampleHQ:

FFVideoSource( "mts.mts", seekmode = -1 )
ResampleHQ( dstcolorspace = "RGB24", srcmatrix = "TV.709", kernel = "lanczos" )

[pbristow]

pancserzso: You need to ask your question in the usage forum, not the development one. Also, open a fresh thread rather than tacking it onto an existing one. That will help you by bringing your question to the attention of more people, and will avoid irritating/confusing people who come to *this* thread looking for info about the stated topic. ("Gamma-aware, dithered colorspace conversion and resizing")

Good luck!

[EDIT: OK, Perhaps I'm being too hasty. Your question *does* have to do with the ResampleHQ plugin, after all. But it is more of a usage question than a development one.

Maybe I should just shut up and let someone else talk. ]

[pancserzso]

Originally Posted by pbristow

pancserzso: You need to ask your question in the usage forum, not the development one. Also, open a fresh thread rather than tacking it onto an existing one. That will help you by bringing your question to the attention of more people, and will avoid irritating/confusing people who come to *this* thread looking for info about the stated topic. ("Gamma-aware, dithered colorspace conversion and resizing")

Good luck!

[EDIT: OK, Perhaps I'm being too hasty. Your question *does* have to do with the ResampleHQ plugin, after all. But it is more of a usage question than a development one.

Maybe I should just shut up and let someone else talk. ]

I especially want to ask in in the ResampleHQ thread, since I believe this is the place where the developer and experts of ResampleHQ are. Also, this is the official forum linked in the ResampleHQ docs, I believe I can ask this question here.

So, I think ResampleHQ gives me the highest quality, I just want to hear some expert opinion on:
1. Whether there is any point using ResampleHQ only for chroma upsampling when doing color space conversion as well.
2. What kernel is recommended for the highest quality 4:2:0 -> RGB conversion + chroma upsampling, if the image dimensions don't change?

[Asmodian]

I think this is an ok place to ask about ResampleHQ, development seems to be done so it can/has turned into more of a support thread.

I would say it is fine to use ResampleHQ for converting to RGB but U and V do not use gamma so the "gamma-aware" doesn't help in this case. However, as ResampleHQ does the conversion in 32‐bit floating‐point and dithers to R'G'B', I do not believe another option would provide higher quality.

I don't think the normal Avisynth ConverttoRGB() uses dithering. Note that FS dithering (like that used by ResampleHQ) tends to get lost when doing a lossy compression (H.264) unless using very high bit rates.

I like Catmull-Rom, Blackman3, Blackman4, or Spline36 depending on ringing vs sharpness but I have never done or seen any good testing of the kernel choice for YUV 4:2:0 to RGB outside of MadVR. For MadVR the the consensus seems to be Jinc3 or bicubic75 but there are fewer choices in MadVR and ResampleHQ doesn't offer Jinc. I am sure that all choices have tradeoffs. I would think Blackman3 would be good, sharper than some but also low ringing and not blurring. Catmull-Rom (bicubic b=0.0, c=0.5) or bicubic75 (b=0.0, c=0.75 - sharper with more ringing) would also be good choices.

If you have chroma artifacts in the source a little blurring might be good so you could use Mitchell-Netravali or Robidoux.

Sorry, I know I have suggested half the kernels but I don't think there is a right answer for kernel choice. I wouldn't go too ringing and I don't like the stronger blurring of Softcubic unless the chroma is in a bad state.

note: 4:2:0 -> RGB includes chroma upsampling by definition. You cannot have subsampled color with RGB.

edit:
If/when you do pick a kernel please let us know which one.

[pancserzso]

Originally Posted by Asmodian

I think this is an ok place to ask about ResampleHQ, development seems to be done so it can/has turned into more of a support thread.

I would say it is fine to use ResampleHQ for converting to RGB but U and V do not use gamma so the "gamma-aware" doesn't help in this case. However, as ResampleHQ does the conversion in 32‐bit floating‐point and dithers to R'G'B', I do not believe another option would provide higher quality.

I don't think the normal Avisynth ConverttoRGB() uses dithering. Note that FS dithering (like that used by ResampleHQ) tends to get lost when doing a lossy compression (H.264) unless using very high bit rates.

I like Catmull-Rom, Blackman3, Blackman4, or Spline36 depending on ringing vs sharpness but I have never done or seen any good testing of the kernel choice for YUV 4:2:0 to RGB outside of MadVR. For MadVR the the consensus seems to be Jinc3 or bicubic75 but there are fewer choices in MadVR and ResampleHQ doesn't offer Jinc. I am sure that all choices have tradeoffs. I would think Blackman3 would be good, sharper than some but also low ringing and not blurring. Catmull-Rom (bicubic b=0.0, c=0.5) or bicubic75 (b=0.0, c=0.75 - sharper with more ringing) would also be good choices.

If you have chroma artifacts in the source a little blurring might be good so you could use Mitchell-Netravali or Robidoux.

Sorry, I know I have suggested half the kernels but I don't think there is a right answer for kernel choice. I wouldn't go too ringing and I don't like the stronger blurring of Softcubic unless the chroma is in a bad state.

note: 4:2:0 -> RGB includes chroma upsampling by definition. You cannot have subsampled color with RGB.

edit:
If/when you do pick a kernel please let us know which one.

Thanks a lot! I've compared it a bit more, and I'm confident in using ResampleHQ for the task.

Some results I've found out:
using dither gave me no visual difference (I seriously cannot see the effect on my source), while it slows down the script extremely. In my case it was 3.7 fps vs. 22 fps with dither = false

for the normal kernel, I've played around and for downsampling 1920x1080 -> 1280x720, I concluded that:
- Lanczos is too sharp / ringy for my liking
- The best filter for my liking was Mitchell

for the chroma kernel, the honest conclusion was:
- there is almost no difference visible at least on my soft real-camera source
- the only exception is SoftCubic, which is actually visibly too soft on red lights, like LEDs
- the PNG file sizes go like this:
softbicubic, bicubic = mitchell, catmull, lanczos

I think I'll choose mitchell here as well.

ResampleHQ( width = 1280, height = 720, dstcolorspace = "RGB24", srcmatrix = "TV.709", kernel = "MitchellNetravali", chroma_kernel = "MitchellNetravali" )

[creaothceann]

Originally Posted by pancserzso

using dither gave me no visual difference (I seriously cannot see the effect on my source)

Watch for color banding.

01
02
03

(pictures change upon mouseover)

[IanB]

Image links are all "Forbidden"

[Sparktank]

That's strange. They work for me.
Country-dependent access? :erm:

[pancserzso]

Thanks for the samples. My source is my own Panasonic GH2 camera, which cannot make such perfect smooth gradient like on the images you've linked, but I might try taking a video of the sky or sunset or something which is like that. On normal, everyday scenes, it didn't happen.

[astronob]

I can't get this filter to work with cinema craft encodersp3. I get a small black mpv file with the words in red on top "Unknown ResampleHQ Internal Error" Any suggestions?

[Asmodian]

please