Gamma-aware, dithered colorspace conversion and resizing

[SEt]

Non-linear scaling allows a lot of freedom that should be able to correct the problems, though mathematics should be pretty intimidating. The best real world non-linear solution so far seems to be nnedi, but it's empirical one.

[madshi]

So is non-linear scaling the solution to the "Implementing linear light scaling is a bit tricky" problem you mentioned? Or are you applying special tweaks to linear resamplers to make linear light scaling work better?

I'm not sure if NNEDI3 would work with linear light? I mean it was trained with gamma corrected light images, AFAIK.

[SEt]

Personally I tweak linear resamplers now. Results are not perfect though. NNEDI needs to work in the same light it was trained (current in corrected), but being non-linear it doesn't really matter.

[madshi]

What kind of tweaks are you doing? Something like this?

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

[SEt]

No, won't help as it's unrelated to main problem (and non-linear too). I'm playing with 2D non-separable resampling. Something similar to EWA but worse.

[madshi]

Ah ok. I think I'll try my luck with non-linear methods.

[tritical]

IMO, working in linear light is only important for downscaling (shrinking) images. Specifically, the larger the ratio of original_size/new_size the more important it is. The reason is because the larger the ratio, the stronger the low-pass filtering you need to do before interpolation in order to avoid aliasing, and if you don't work in linear light when doing the low-pass filtering then you wont approximate an optical blur.

For enlargement, where you're not performing low-pass filtering, but are simply trying to predict values at intermediate locations I don't believe that there is any evidence that fir interpolation in linear light is more accurate than in gamma corrected. I have done tests myself that show this. The typical FIR filters don't fit a vast majority of image content any better in linear light than they do in gamma corrected except for cases where the difference between the two would be too small to notice. Working in linear light will definitely cause more ringing (increase overshoot) when using FIR filters with negative taps though.

[killazys]

Thanks for the responses! One more thing, why did you pick Bilinear for chroma subsampling? It makes everything.. softer..

[PhrostByte]

Thanks for the responses! One more thing, why did you pick Bilinear for chroma subsampling? It makes everything.. softer..

It's Avisynth's default, that's the only reason.

[NicolasRobidoux]

http://imagemagick.org/discourse-server/viewtopic.php?f=22&t=19636&p=78285#p78285

[Stereodude]

Any chance for a x64 version of the latest build or does it still not work?

[Stereodude]

So, I noticed that my x264 encodes were smaller when using ResampleHQ instead of plain Spline36Resize. Has anyone else noticed this? I would have expected the opposite to be true.

Using ResampleHQ(1280,720, "YV12", "TV.709", "TV.709", false, 0, 0, 0, 0 ,"Spline36"):
encoded 4746 frames, 1.43 fps, 3114.31 kb/s
x264 [info]: frame I:210 Avg QP:14.09 size: 89541
x264 [info]: frame P:1078 Avg QP:19.45 size: 29109
x264 [info]: frame B:3458 Avg QP:23.31 size: 7772

Using Spline36Resize(1280,720):
encoded 4746 frames, 1.36 fps, 3322.29 kb/s
x264 [info]: frame I:211 Avg QP:14.64 size:106961
x264 [info]: frame P:1073 Avg QP:19.67 size: 30165
x264 [info]: frame B:3462 Avg QP:23.33 size: 7877

My x264 command line:
--crf 18 --preset placebo --tune film --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --ref 9 --b-adapt 2 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1

[PhrostByte]

So, I noticed that my x264 encodes were smaller when using ResampleHQ instead of plain Spline36Resize.

Just a coincidence, probably.

[Stereodude]

Just a coincidence, probably.Well FWIW I've seen it on all three of my test encodes so far. I've got another few tests clips I'll be doing and will report back.

[markanini]

Wild guess, it (over-?)accentuates contours over vanilla Spline36 so maybe the encoder has an easier time distinguishing between that and noise and what not....

[Stereodude]

My original tests were OTA broadcast 1080i HDTV (MPEG-2) that was IVTC'd or QTGMC deinterlaced, debanded, and finally resized. I ran a 5000 frame test this afternoon from a pretty high bitrage Blu-Ray (AVC/H.264) with only resizing and got the same sort of results.

[markanini]

http://imagemagick.org/discourse-server/viewtopic.php?f=22&t=19636&p=78285#p78285

An updated Lanczossharp?

[NicolasRobidoux]

An updated Lanczossharp?
Exactly. From a spectral viewpoint (which never tells the whole story in image processing), the theory suggests that the previous one was too soft, which some on this forum stated as well. So, I went on the hunt for a sharper one.

The thread documents the hunt.

[NicolasRobidoux]

...
Random thought: I don't know how flexible Avisynth's resampling code is, but it would be really nice if you could manually control the support width - maybe by supplying a user specified scaling factor >= 1.0 - instead of having it always scaled by a factor of max(old_width/target_width,1.0).
This last scaling (or its reciprocal, depending on whether you do the lookup "forward" or "backward") is what the ImageMagick implementation of Clamped EWA (Elliptical Weighted Averaging) resampling uses when resizing.

In addition, depending on the filter, there are situations when using a scaling factor < 1.0 gives good results.

[NicolasRobidoux]

Actually, there is more than one way of doing it. In the Avisynth implementation, your line:

is effectively replaced by:
result = P0 + distance * (P1 + distance * (P2 + distance * P3));
which is marginally faster (fewer multiplies). ;)
This is a standard trick usually taught in Numerical Analysis 1: the Horner Scheme (http://en.wikipedia.org/wiki/Horner_scheme)

[NicolasRobidoux]

In case someone wants to try the new sharper EWA ImageMagick filters without sorting through the ImageMagick Forum threads I mentioned earlier, here is what you can run if you have a reasonably recent IM install.

The first one is the new four lobe "optimally sharp" Jinc-windowed Jinc EWA (replace INPUT_IMAGE and PERCENT by the desired values):
convert INPUT_IMAGE -define filter:filter=Jinc -define filter:window=Jinc -define filter:blur=0.88451002338585141 -define filter:lobes=4 -distort Resize PERCENT% JincJinc4blur0p88451002338585141.png

It even works fairly well (IMHO) with "Super Mario"-type old skool CG, even though it has noticeable haloing.

The second is the BC-cubic EWA which is a sharper version of the Robidoux filter (using the same optimization method that produced the above 4-lobe Jinc-windowed Jinc):
convert INPUT_IMAGE -define filter:c=.3689927438004929 -filter Cubic -distort Resize PERCENT% RobidouxSharp.png This would be quite a cheap scheme to implement (even though it is a cylindrical scheme).

These methods are documented in the following threads:
http://imagemagick.org/discourse-server/viewtopic.php?f=22&t=19636 and http://imagemagick.org/discourse-server/viewtopic.php?f=22&t=19823&sid=f3054401194ad62e9b9cbe42116ad860

You may see the above as improvements (or at least sharper versions) of convert INPUT_IMAGE -filter LanczosSharp -distort Resize PERCENT% LanczosSharp.png

and convert INPUT_IMAGE -distort Resize PERCENT% Robidoux.png
(the Robidoux EWA filter is the current ImageMagick default).

P.S. If you don't like the idea of using 4 lobes, here is the 3-lobe version:
convert INPUT_IMAGE -define filter:filter=Jinc -define filter:window=Jinc -define filter:blur=0.88549061701764 -define filter:lobes=3 -distort Resize PERCENT% JincJinc3blur0p88549061701764.png
IMHO, the mild "third halo band" of the 4-lobe version is worth the antialiasing.

P.S. Actually, when haloing is glaringly obvious, the "third halo band" may be offensive, and the 3-lobe version is better. This is seen in some of the results linked in http://forum.doom9.org/showthread.php?p=1541800#post1541800. See, for example, the "bullseye" enlargements.

[markanini]

the new four lobe "optimally sharp" Jinc-windowed Jinc EWA

Tried A/B-ing the new LaczosSharp and lanczos3 in Irfanview on a 10Mpixel photo resized to to 13%. Wasn't sure if I could see a difference at all though the original was neither very detailed or a problem image. I wonder if there's a DBT program for images out there.

EDIT: Is it possible to use a softer kernel for chroma?

[NicolasRobidoux]

Tried A/B-ing the new LaczosSharp and lanczos3 in Irfanview on a 10Mpixel photo resized to to 13%. Wasn't sure if I could see a difference at all though the original was neither very detailed or a problem image...
What I forgot to say is that it is when you upsample that the differences jump at you, esp. if you have sharp non-vertical/horizontal lines and interfaces.

What you are seeing is that if the image is reasonably smooth ("sub-critical", meaning, not too far from being band-limited away from the Nyquist threshold) both filters are decent low-pass filters, and consequently give somewhat similar results when downsampling because Lanczos 3 and "sharpened" Jinc-windowed Jinc 4 have similar footprints (Lanczos 3 has the usual square of half-width equal to 3, "sharpened" Jinc-windowed Jinc 4 is a disk of radius 3.75126261283712774 with an area just a little over 44, compared to an area of 36 for the Lanczos 3 square).

I expect more of a difference downsampling text, old skool CG or other images with very crisp pieces.

EDIT: Is it possible to use a softer kernel for chroma?I could go on a hunt for a good match, but I think you'd get better results by post-processing the chroma channel with a reasonable anti-aliasing filter. I really like convolving with the five-point cross filter

0 t 0
t 1-4t t
0 t 0
where t is in (0,1/5], with favorite value t=1/8 (1/16 also works well).

[infoeater]

Following Avisynth script is causing ResampleHQ-v8 to report "Unknown ResampleHQ internal error" at frame 5941:
Note: I used Avisynth "AVS 2.6.0 Alpha 3 [110525]" installed in old directory.

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\ffms\ffms2.dll")
FFVideoSource("C:\Video\00106org.mp4")
ResampleHQ(width=768, height=432, dstcolorspace="YV12", srcmatrix="TV.709", dstmatrix="TV.601", dither=true, kernel="Spline36", chroma_kernel="Spline36")


EDIT:
Setting dither to false doesn't help.
Setting kernel and chroma_kernel to Bilinear doesn't help.
Setting dstmatrix to TV.709 doesn't help.
Removing all parameters except width and height doesn't help.
Remuxing source file from MTS without audio does help (?!).
Remuxing source file from MTS with same parameters does help (?!).
Removing ResampleHQ from actions on original file doesn't help(?!). Avisynth reported different error: "FFVideoSource: Insanity detected: decoder returned an empty frame"
Out of date. Original muxed file was corrupted in not reproduceable way probably because of temporal lack of disk space while muxing. However Avisynth reported error was not very usable, as it pointed to ResampleHQ, but problem was somewhere else.

[NicolasRobidoux]

@markanini: I would also consider prefiltering the chroma (before resampling).
... I really like convolving with the five-point cross filter

0 t 0
t 1-4t t
0 t 0
where t is in (0,1/5], with favorite value t=1/8 (1/16 also works well).

[markanini]

@markanini: I would also consider prefiltering the chroma (before resampling).

I'll give it a try. :)

[NicolasRobidoux]

Note: The cross filter can be done using a sum of separable filters (actually 1D box). It is equal to

t *
(
[ 1 1 1 ]
+
[ 1 ]
[ 1 ]
[ 1 ]
)
+
(1-6*t) *
[1]

[titlis]

Bug report (at least I thought)

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

ResampleHQ produces a small amount of chroma shifting
as mentioned in thread above.
Probably horizontal resize issue according to Gavino

[NicolasRobidoux]

@markanini: Mark, I tried to reply with a private message but I'm not sure it went through.

In any case:

I have not tested my attempts at maximally sharpening Jinc-windowed Jinc for downsampling.

Actually, I have tested methods ("mine" and others') for downsampling less than for upsampling.

However, here are some quick pointers regarding downsampling, hopefully correct:

1) Nohalo-LBB, LBB, VSQBS and the like are NOT meant for downsampling.

2) Jinc-windowed Jinc filters are low-pass filters. They should work well. Better than (orthogonal) Lanczos? Don't know.

I am guessing that the maximally sharpened ones (which are not currently "named schemes" in ImageMagick) will not be better than (orthogonal) Lanczos. On the other hand, pre-existing halos and/or moire have less impact when downsampling.

I am also guessing that the current EWA LanczosSharp ("sharpened" Jinc-windowed Jinc 3) will be competitive, maybe better than (orthogonal) Lanczos 3. However, it is nearly identical to EWA Lanczos ("straight" Jinc-windowed Jinc 3), which is why I suggested to Anthony Thyssen of ImageMagick that he just get rid of it to simplify things.

I believe that EWA Robidoux will be slightly better than EWA Lanczos2Sharp ("sharpened" Jinc-windowed Jinc 2), which is why I suggested it be taken out of ImageMagick as well. A large commercial client of mine actually chose EWA Robidoux as default downsampling scheme. It interacts well with strong jpeg compression.

EWA Mitchell and EWA RobidouxSharp (which is not yet in ImageMagick but is defined in its forums) should also work pretty well for downsampling. Mitchell is sharper than Robidoux, and RobidouxSharp is sharper than Mitchell.

EWA Robidoux, Mitchell and RobidouxSharp only have one halo, unlike EWA LanczosSharp and EWA Lanczos (or orthogonal Lanczos which, in ImageMagick, is Lanczos 3).

Although I have no strong reason to think so besides the large number of lobes and consequently halos, I doubt that using 4 lobes or more is worth it. But I may be wrong. In any case, it is not hard to program ImageMagick to use "straight" or "sharpened" EWA to use Jinc-windowed Jinc 4.

3) I have not taken the time to think about what one should expect in terms of spectrum when one is resampling a RAW image (or a "gently" demosaiced RAW image), as opposed to the usual "sharpened" jpegs than come out of many digital cameras. This may have an impact on what will work well, or not. It could be that this is just what the maximally sharpened EWA Jinc-windowed Jinc are for.

[killazys]

So.. was 16 bit input/output support ever added in to this?

Also, if I have dark halos as evidenced in the mouse-over picture here: http://screenshotcomparison.com/comparison/98651
What downsampling filter would be recommended?

[Sapo84]

So.. was 16 bit input/output support ever added in to this?
That would be nice, ResampleHQ is by far the best resizer out there (you can really see the differenze when there is overlayed text, ResampleHQ looks much brighter and more natural), 16 bit input and output would mean having a pretty big part of the filtering process with higher precision, which really would help a lot when encoding with the Hi10P profile.

Also, if I have dark halos as evidenced in the mouse-over picture here: http://screenshotcomparison.com/comparison/98651
What downsampling filter would be recommended?
If you are bothered by the dark halos (they don't seems too bad to me) why not giving dehalo_alpha a try?
Setting brightstr to 0.0 and darkstr to 0.0...1.0 should reduce dark halos quite effectively.

[Stephen R. Savage]

For those interested, the results of ResampleHQ can be recreated using DitherTools (http://forum.doom9.org/showthread.php?t=153589).


ImageSource("earthlights_big.jpg")
x = 1200
y = 600

Dither_convert_8_to_16()
Dither_y_gamma_to_linear()
Dither_resize16(x, y)
Dither_y_linear_to_gamma()
DitherPost()

This produces slightly incorrect colors as it skips a YUV->RGB->YUV, which is theoretically wrong as chroma is not independent of luma. However, the differences are marginal, especially compared to the increased sharpness by avoiding chroma resampling (and also any chroma shift).

See the following images:

ResampleHQ
http://img840.imageshack.us/img840/6493/resamplehq.png

DitherTools
http://img11.imageshack.us/img11/2398/dithertools.png

[cretindesalpes]

You probably forgot the Dither_linear_to_gamma() after Dither_resize16().

You can also do the linear<->gamma conversion in the RGB colorspace:

Dither_convert_yuv_to_rgb (output="rgb48y")
Dither_y_gamma_to_linear (tv_range_in=false, tv_range_out=false, u=1, v=1)
Dither_resize16 (w, h, u=1, v=1)
Dither_y_linear_to_gamma (tv_range_in=false, tv_range_out=false, u=1, v=1)
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ lsb=false)

[redfordxx]

I like the kernel visualization very much. I have additional question:
Is it maybe so, that in case of downsizing some kernels do not ring or blur so much or are sharper, than it is visualized in the chart?
For example started to use Bicubic everywhere because I am afraid of ringing, but maybe, there should be better choice in case of downsizing.

[ajp_anton]

Weird things are going on with ResampleHQ, especially in dark areas:

ResampleHQ -> Dither_resize16 -> Spline36resize
http://img217.imageshack.us/img217/2378/rhq1.th.png (http://img217.imageshack.us/img217/2378/rhq1.png) http://img594.imageshack.us/img594/7687/dither1.th.png (http://img594.imageshack.us/img594/7687/dither1.png) http://img833.imageshack.us/img833/908/s361.th.png (http://img833.imageshack.us/img833/908/s361.png)

http://img100.imageshack.us/img100/5602/rhq2.th.png (http://img100.imageshack.us/img100/5602/rhq2.png) http://img407.imageshack.us/img407/8373/dither2.th.png (http://img407.imageshack.us/img407/8373/dither2.png) http://img341.imageshack.us/img341/1762/s362.th.png (http://img341.imageshack.us/img341/1762/s362.png)

[Sapo84]

This is probably is a bug report.

I was evaluating various resize methods with an anime source.

Dither_y_gamma_to_linear()
Dither_resize16(1280, 720)
Dither_y_linear_to_gamma()
http://img37.imageshack.us/img37/7812/mawarugamma1.png

ResampleHQ(1280,720,srcmatrix="TV.709",dstmatrix="TV.709",dstcolorspace="YV12",kernel="SPLINE36")
http://img851.imageshack.us/img851/4793/mawarugamma3.png

Spline36Resize(1280,720)
http://img832.imageshack.us/img832/6792/mawarugamma4.png

The PNGs are taken with AvsPmod (Rec.709 matrix).

The luma plane is correct with dither_resize16 and ResampleHQ, which is what I expected.
The chroma planes, instead, look very different with ResampleHQ, the reds are much "darker".

http://img42.imageshack.us/img42/69/mawarugamma5.png
The source frame.

Moreover if we convert to RGB and then resize with ResampleHQ (just use the last png as source, if you want to test), the result is again very different.
http://img42.imageshack.us/img42/6609/mawarugamma6.png

I think there is a bug in how ResampleHQ handles chroma in YV12 mode.

[lexor]

I am interested in learning more about the techniques and algorithms behind this. The author has started a blog series on http://int64.org but there were no updates since July of last year. And the 2 articles there don't contain much detail. Are there particularly good books/papers/blogs on the subject that I can look into?

[IanB]

Scan all of this thread, various links are sprinkled throughout.

:search: http://www.google.com.au/search?q=gamma+resize+image

:search: http://www.google.com.au/search?q=dither+image

[Abradoks]

Are there particularly good books/papers/blogs on the subject that I can look into?
You may find ImageMagick documentation, source code and forums interesting. For example, that (http://imagemagick.org/Usage/resize/) page.

[PhrostByte]

I am interested in learning more about the techniques and algorithms behind this. The author has started a blog series on http://int64.org but there were no updates since July of last year. And the 2 articles there don't contain much detail. Are there particularly good books/papers/blogs on the subject that I can look into?

I got a bit distracted with some real life things, but I'll be posting something new soon with more technical details.

What are you interested in learning about? Gamma correctness? Resampling? Colorspace conversion?

[SilaSurfer]

Weird things are going on with ResampleHQ, especially in dark areas:

ResampleHQ -> Dither_resize16 -> Spline36resize
http://img217.imageshack.us/img217/2378/rhq1.th.png (http://img217.imageshack.us/img217/2378/rhq1.png) http://img594.imageshack.us/img594/7687/dither1.th.png (http://img594.imageshack.us/img594/7687/dither1.png) http://img833.imageshack.us/img833/908/s361.th.png (http://img833.imageshack.us/img833/908/s361.png)

http://img100.imageshack.us/img100/5602/rhq2.th.png (http://img100.imageshack.us/img100/5602/rhq2.png) http://img407.imageshack.us/img407/8373/dither2.th.png (http://img407.imageshack.us/img407/8373/dither2.png) http://img341.imageshack.us/img341/1762/s362.th.png (http://img341.imageshack.us/img341/1762/s362.png)

This is probably is a bug report.

I was evaluating various resize methods with an anime source.

Dither_y_gamma_to_linear()
Dither_resize16(1280, 720)
Dither_y_linear_to_gamma()
http://img37.imageshack.us/img37/7812/mawarugamma1.png

ResampleHQ(1280,720,srcmatrix="TV.709",dstmatrix="TV.709",dstcolorspace="YV12",kernel="SPLINE36")
http://img851.imageshack.us/img851/4793/mawarugamma3.png

Spline36Resize(1280,720)
http://img832.imageshack.us/img832/6792/mawarugamma4.png

The PNGs are taken with AvsPmod (Rec.709 matrix).

The luma plane is correct with dither_resize16 and ResampleHQ, which is what I expected.
The chroma planes, instead, look very different with ResampleHQ, the reds are much "darker".

http://img42.imageshack.us/img42/69/mawarugamma5.png
The source frame.

Moreover if we convert to RGB and then resize with ResampleHQ (just use the last png as source, if you want to test), the result is again very different.
http://img42.imageshack.us/img42/6609/mawarugamma6.png

I think there is a bug in how ResampleHQ handles chroma in YV12 mode.

Does anyone know if these bugs have been fixed?

[SilaSurfer]

Double post I know. Actually over at Anime Music Videos forum user Mister Hatt explains that PhrostByte didn't find any major bugs with chroma, PhrostByte apperantly reported that over IRC channel.

Here is the link to that thread and Mister Hatt's statement:

http://www.animemusicvideos.org/forum/viewtopic.php?f=45&t=108819#p1433031

Here is what the next version of Reasmple-Hq will bring:

Changelog from http://svn.int64.org/viewvc/int64/resamplehq/doc/index.html
Resample-HQ Version 9 (Pending)

Bug fix: fix resizing very small frames.
Bug fix: infinite loop with certain invalid arguments.
FMA3 color conversions for Intel Haswell.
FMA3/FMA4 vertical resampler.

No mention of chroma bugs.

Just wanted to share.

[Sapo84]

The bug is actually in avisynth 2.58, 2.6 is fine (I think the avisynth bug was found while talking to mirkosp in IRC soon after that post).

Never actually bothered to update the post with the new info.

[mirkosp]

It's not a bug. It was just that the specific frame had very fine detail (red on white), so when downscaling the two get mixed and so the red becomes slightly darker. Using extremely sharp kernels for chroma (sinc with 8 taps) mitigates the issue (the colours are lighter) and no visible artefacts are introduced despite being sinc (since it's only on the chroma).
The issue was very evident in that case since due to :reasons: rgb input was getting downscaled to yuv (I blame Adobe), so obviously introducing a colourspace conversion is gonna make the colour shifting a lot more obvious. There is, however, a slight difference in rgb->yuv conversion output between 2.58 and 2.6, with 2.6 being very slightly better. But obviously, if you start doing rgb->yuv->rgb->yuv you're just getting the reds darker at every conversion back to yuv with that image (converting to rgb doesn't really shift the colours, it's just switching them back that introduces the issue).
Obviously, this is all completely unrelated to resamplehq and I'd guess avisynth isn't really at fault either. You can't expect black magic when dealing with colourspace conversions.

[Mug Funky]

i wondered if the new(ish) deepcolour tools could be used with internal temporalsoften? my intuition tells me this would be a bad idea.

the reason is that, like the spatial filtering in resampleHQ, temporal filtering is strongly affected by working in linear space.

my canon DSLR workflow involves the adding of motion blur (shoot without to allow better stabilization, add back later), and it just wasn't quite convincing me. wrapping the whole sorry mess in converttorgb and levels(0,1/2.2,255,0,255) showed there was a benefit to the way the motion blur worked out, but of course a massive detriment on account of the banding from that quick proof-of-concept.

so now i'm on the hunt for a way to step this up to higher bit depths in order to get a more natural looking motion blur.

this might have an effect on denoising as well, though whether it's positive or negative remains to be seen (i think it's worth a try).

[infoeater]

Are RGB24 and RGB32 in ResampleHQ in fact sRGB (or maybe system colorspace?)?

Is following formula used for conversion between linear RGB and ITU‐R BT.709?
V= 1.099*L^0.45 – 0.099 for 1 ≥ L ≥ 0.018
V = 4.500*L for 0.018 > L ≥ 0
where:
L: luminance of the image 0 ≤ L ≤ 1
V: corresponding
I am asking because theoretically different formula is recommend for displays and for cameras (which I consider generally as mistake - formula should be the same and watching conditions should be tuned to the formula, not the opposite).

Is FCC the NTSC color space?

Is it possible to use ResampleHQ to convert sRGB to TV.709?

Finally, am I correct that VirtualDub is not color space aware and is displaying everything in sRGB/system colorspace?

[Asmodian]

RGB isn't sRGB or system color space or anything; it is just RGB values. You have to know what kind of RGB it is if you want to convert it to another gamut.

ResampleHQ's docs do state it uses sRGB gamma equations. Most modern digital video (blurays, YouTube, etc) are supposed to be mastered to sRGB gamut (sRGB uses the same primaries and white point as BT.709). I assume HD cameras try to get as close as they can to BT.709 but given how bad consumer monitors and TVs are I wouldn't expect it to be that close except in the very high end. Each camera probably needs its own calibration. It would be interesting to know if there are cameras that target a different gamut.

I do not know of any video tools available to convert from custom gamuts, i.e. convert from a custom measured color space of a camera to BT.709. There must be some though.

I normally think of the NTSC color space as NTSC (1987) = BT.601 but there are others one might call NTSC as well.

It is easy to use ResampleHQ to convert to TV.709, just set dstmatrix="TV.709".

You are right VirutalDub is not color space aware and always uses the same coefficients when converting to RGB for display. Note that all programs must convert to RGB at some point during display; VirtualDub doesn't know which matrix YUV it is getting so has to assume one. I would be nice to have a setting for this.

[Gser]

I was wondering if it would be possible to add pointresize to ResampleHQ?

[jmac698]

Umm.. there wouldn't be any point, just use pointresize.

[henryho_hk]

PointResize does not involve interpolation.