Gamma-aware, dithered colorspace conversion and resizing - Page 9

Stereodude · 17th November 2011, 03:57

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

Stereodude · 24th November 2011, 06:05

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 · 24th November 2011, 16:58

Quote:

Originally Posted by Stereodude

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

Just a coincidence, probably.

Stereodude · 24th November 2011, 17:25

Quote:

Originally Posted by PhrostByte

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 · 24th November 2011, 19:59

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 · 25th November 2011, 00:13

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 · 27th November 2011, 13:07

Quote:

Originally Posted by NicolasRobidoux

http://imagemagick.org/discourse-ser...p=78285#p78285

An updated Lanczossharp?

NicolasRobidoux · 27th November 2011, 15:06

Quote:

Originally Posted by markanini

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 · 27th November 2011, 18:09

Quote:

Originally Posted by tritical

...
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 · 27th November 2011, 18:13

Quote:

Originally Posted by Gavino

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

is effectively replaced by:

Code:

    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

NicolasRobidoux · 27th November 2011, 18:46

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):

Code:

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):

Code:

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-ser...p?f=22&t=19636 and http://imagemagick.org/discourse-ser...9cbe42116ad860

You may see the above as improvements (or at least sharper versions) of

Code:

convert INPUT_IMAGE -filter LanczosSharp -distort Resize PERCENT% LanczosSharp.png

and

Code:

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:

Code:

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.ph...00#post1541800. See, for example, the "bullseye" enlargements.

markanini · 28th November 2011, 12:07

Quote:

Originally Posted by NicolasRobidoux

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 · 28th November 2011, 15:30

Quote:

Originally Posted by markanini

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.

Quote:

Originally Posted by markanini

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

Code:

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 · 28th November 2011, 16:26

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 · 30th November 2011, 13:13

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

Quote:

Originally Posted by NicolasRobidoux

... I really like convolving with the five-point cross filter

Code:

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 · 30th November 2011, 14:10

Quote:

Originally Posted by NicolasRobidoux

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

I'll give it a try.

NicolasRobidoux · 30th November 2011, 15:43

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

Code:

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

titlis · 10th December 2011, 02:53

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 · 10th December 2011, 03:47

@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 · 14th December 2011, 04:19

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?

17th November 2011, 03:57	#161 \| Link
Stereodude Registered User Join Date: Dec 2002 Location: Region 0 Posts: 1,436	Any chance for a x64 version of the latest build or does it still not work? Last edited by Stereodude; 17th November 2011 at 04:03.

27th November 2011, 18:46	#171 \| Link
NicolasRobidoux Nicolas Robidoux Join Date: Mar 2011 Location: Montreal Canada Posts: 269	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): Code: 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): Code: 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-ser...p?f=22&t=19636 and http://imagemagick.org/discourse-ser...9cbe42116ad860 You may see the above as improvements (or at least sharper versions) of Code: convert INPUT_IMAGE -filter LanczosSharp -distort Resize PERCENT% LanczosSharp.png and Code: 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: Code: 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.ph...00#post1541800. See, for example, the "bullseye" enlargements. Last edited by NicolasRobidoux; 29th November 2011 at 03:21.

28th November 2011, 16:26	#174 \| Link
infoeater Registered User Join Date: May 2007 Posts: 53	Internal ResampleHQ error 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. Last edited by infoeater; 28th November 2011 at 17:39.

30th November 2011, 15:43	#177 \| Link
NicolasRobidoux Nicolas Robidoux Join Date: Mar 2011 Location: Montreal Canada Posts: 269	Note: The cross filter can be done using a sum of separable filters (actually 1D box). It is equal to Code: t * ( [ 1 1 1 ] + [ 1 ] [ 1 ] [ 1 ] ) + (1-6t) [1]

10th December 2011, 03:47	#179 \| Link
NicolasRobidoux Nicolas Robidoux Join Date: Mar 2011 Location: Montreal Canada Posts: 269	@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. Last edited by NicolasRobidoux; 10th December 2011 at 03:54.

24th November 2011, 06:05	#162 \| Link
Stereodude Registered User Join Date: Dec 2002 Location: Region 0 Posts: 1,436	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

24th November 2011, 19:59	#165 \| Link
markanini Registered User Join Date: Apr 2006 Posts: 299	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....

25th November 2011, 00:13	#166 \| Link
Stereodude Registered User Join Date: Dec 2002 Location: Region 0 Posts: 1,436	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.

10th December 2011, 02:53	#178 \| Link
titlis Registered User Join Date: Apr 2011 Location: Republic of Korea Posts: 49	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

14th December 2011, 04:19	#180 \| Link
killazys Registered User Join Date: Sep 2011 Posts: 29	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? Last edited by killazys; 14th December 2011 at 04:22.