Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
14th December 2011, 17:39 | #181 | Link | |
Registered User
Join Date: May 2008
Posts: 40
|
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.
Quote:
Setting brightstr to 0.0 and darkstr to 0.0...1.0 should reduce dark halos quite effectively. |
|
14th December 2011, 21:28 | #182 | Link |
Registered User
Join Date: Nov 2009
Posts: 327
|
For those interested, the results of ResampleHQ can be recreated using DitherTools.
Code:
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() See the following images: ResampleHQ DitherTools Last edited by Stephen R. Savage; 15th December 2011 at 14:56. |
15th December 2011, 12:46 | #183 | Link |
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
Join Date: Feb 2009
Location: No support in PM
Posts: 712
|
You probably forgot the Dither_linear_to_gamma() after Dither_resize16().
You can also do the linear<->gamma conversion in the RGB colorspace: Code:
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)
__________________
dither 1.28.1 for AviSynth | avstp 1.0.4 for AviSynth development | fmtconv r30 for Vapoursynth & Avs+ | trimx264opt segmented encoding |
16th December 2011, 21:26 | #184 | Link |
Registered User
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
|
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. |
26th December 2011, 22:53 | #186 | Link |
Registered User
Join Date: May 2008
Posts: 40
|
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/4...warugamma3.png Spline36Resize(1280,720) http://img832.imageshack.us/img832/6...warugamma4.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. Last edited by Sapo84; 26th December 2011 at 22:56. |
18th January 2012, 20:05 | #187 | Link |
Registered User
Join Date: Jan 2004
Posts: 849
|
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?
__________________
Geforce GTX 260 Windows 7, 64bit, Core i7 MPC-HC, Foobar2000 |
18th January 2012, 21:51 | #188 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Scan all of this thread, various links are sprinkled throughout.
http://www.google.com.au/search?q=gamma+resize+image http://www.google.com.au/search?q=dither+image |
19th January 2012, 05:35 | #190 | Link | |
Grand Fruitioner
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
|
Quote:
What are you interested in learning about? Gamma correctness? Resampling? Colorspace conversion?
__________________
Lanczos4, Spline36, what!? Don't know how to pick a resizer? Take a look at my kernel visualizations. Want a high-quality, gamma-aware resizer? Check out my ResampleHQ filter. |
|
29th April 2012, 18:37 | #191 | Link | ||
Registered User
Join Date: Oct 2009
Posts: 212
|
Quote:
Quote:
|
||
7th May 2012, 13:33 | #192 | Link |
Registered User
Join Date: Oct 2009
Posts: 212
|
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/foru...08819#p1433031 Here is what the next version of Reasmple-Hq will bring: Changelog from http://svn.int64.org/viewvc/int64/re...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. |
8th May 2012, 06:15 | #194 | Link |
Registered User
Join Date: Jul 2009
Posts: 19
|
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. |
19th July 2012, 05:46 | #195 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
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).
__________________
sucking the life out of your videos since 2004 |
1st August 2012, 19:29 | #196 | Link |
Registered User
Join Date: May 2007
Posts: 53
|
Questions about color spaces
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? |
3rd August 2012, 21:12 | #197 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
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. Last edited by Asmodian; 4th August 2012 at 04:23. |
Thread Tools | Search this Thread |
Display Modes | |
|
|