gamut conversions through Avisynth ?

[yesgrey]

Hi! Chroma is usually 16-240 for YUV video. For xvYCC it is 0-255. My question related to capturing this signal via HDMI. If I use a video capture program like VirtualDub, does it capture the extra chroma values for chroma ?
I don't know, but if it works according to spec it should, because the entire range 1-254 is supposed to contain video data, but to be sure ask VirtualDub's author about it.

Problem is that a HDMI capture card outputs HDYC, which is then converted to RGB24 (as the video preview is seen on the monitor), then it is converted to YUV 4:2:2 for capture.
The extra chroma values would give a negative RGB value, so I would think they get thrown away.
If you perform any conversion from HDYC to an RGB that could not hold the entire range of colors you will lose them. However, why would you perform that conversion if the capture would always be in YUV? Just capture the original data without any processing.

Am I missing something?

[Yellow_]

Queried xvYCC handling with Virtualdub author and Vdub can't handle an RGB gamut wide enough to contain xvYCC in RGB such as AdobeRGB, think Vdub is sRGB only.

That could well explain why I wasn't seeing anymore colors than just doing full range conversion prior to you implementing xvYCC, both must have been clipping at the boundary of sRGB.

Need to find an alternative tool to process avisynth scripts, maybe FFmpeg on the command line? Hack Blender to support AdobeRGB, as it only supports sRGB and linear currently but can process avs scripts via ffmpeg.

Or perhaps when I was using Wilberts Imagemagick plugin it was writing out images of sRGB gamut, maybe need to revisit that and see if there is a way to set gamut to AdobeRGB in imagemagick via his plugin.

Still haven't got my head round linear space yet, I assume the width of gamut is the same as the source?

If an app has a 32bit float linear compositing pipeline and writes images out either as linear exr or gamma encoded formats like png, jpg etc restricted to sRGB, is the linear exr restricted sRGB gamut or does linear have a capability for a wide gamut?

[yesgrey]

Still haven't got my head round linear space yet, I assume the width of gamut is the same as the source?
Yes, it's exactly the same width. The linear vs gamma only affects the distance between the different points inside the gamut, and not the gamut itself.

[zcream]

Just wondering how we could even get xvYCC data in a video file anyway ?

I checked with Blackmagic Design, and it turns out that the chipset they use clips the colors from 16-240. Most HDMI capture cards use the same HDMI chipset - hence its not possible to capture this color range.

xvYCC is only present in the HDMI specs, I dont see it on any other video transport spec.

So how can one get xvYCC video data anyway ?

Also, with VD, if the input stream is YUY2 or HDYC, you can use Fast Recompress and thus turn off any RGB conversion. This way, any xvYCC data should be retained during conversion.

[Yellow_]

Just wondering how we could even get xvYCC data in a video file anyway ?

xvYCC is only present in the HDMI specs, I dont see it on any other video transport spec.

So how can one get xvYCC video data anyway ?



http://forum.doom9.org/showthread.php?p=1464035#post1464035

[yesgrey]

I checked with Blackmagic Design, and it turns out that the chipset they use clips the colors from 16-240.
This kind of thing always amazes me... Why do they do it? Even the ITU.BT-709 standard clearly says that video data is all the range from 1-254, so why do they clip it?
Then, this kind of thing happens. A new standard is developed considering the previous one was fully respected, but it wasn't...

[Yellow_]

Majority I guess, are there many sources that are full range by specification?

Broadcast, cable, satalite? Video cameras? a few video cameras support xv.color but it's not widely used.

But then what codecs support full range by specification? h264AVC is the only one I know.

Uncompressed capture will need a RAID.

Then having captured full range, other than playback on a TV with hdmi 1.3 and able to display full range correctly, what else to do with it, burn it to Bluray, not supported.

Edit it, what NLE's actually handle xvYCC without squashing it into 16 - 235/240 in some intermediate codec to do all the RGB processing on it? Not many I think. :-(

[poisondeathray]

Edit it, what NLE's actually handle xvYCC without squashing it into 16 - 235/240 in some intermediate codec to do all the RGB processing on it? Not many I think. :-(

This is true, but some can access Y'CbCr in filters even though they function in RGB . These filters are applied before the NLE converts to RGB. eg. if you have "illegal levels" you can use YUV filters to bring back into legal ranges. Premiere Pro CS5 does this for some filters. But I don't know how xvYCC is handled specifically

[Yellow_]

Yes, I think Premiere CS5 is one of the can handle it based on a comment from a Adobe representative:

Adobe CS5 reads the H.264 files natively into Premiere Pro and After Effects at the highest possible quality. Our color gamut and dynamic range for tonal detail from shadow to highlight is unsurpassed. There is even support for over-brights beyond 100% in After Effects.

The magic comes from the use of proprietary interpretation algorithms and I might also mention that we bypass QuickTime for this process, which avoids the whole gamma conundrum. Once the file is living inside our apps on the timeline or project, we deal with the image information at the 32 bit float level. Now that is not saying we can make an 8 bit H.264 DSLR video capture look like perfectly shot IMAX footage scanned at 16 bits, but what we do offer up is the ability to edit, apply effects and color corrections within our apps. at an unprecedented level of quality.

Obviously not proof but interesting. :-)

[xbox360]

What is the gamut for NTSC-J ? & how do I use it in an Avisynth script ?

[yesgrey]

What is the gamut for NTSC-J ?
Is it an analog source? If it is you might need to use the "US NTSC 1953" options. In addition to that you should use an input range that would compensate for the black point difference.

how do I use it in an Avisynth script ?
With t3dlut.

[xbox360]

In addition to that you should use an input range that would compensate for the black point difference.


With t3dlut.

And what would that input range be ?

[yesgrey]

And what would that input range be ?
It would depend on how the capture is performed. How are you doing it?

[xbox360]

sRGB captures.

[yesgrey]

sRGB captures.
Are you sure? Which card are you using? Also, tell me which output do you want? Tell me as much information as you can, only then I could help you creating a configuration file to use with yCMS.

[xbox360]

sRGB captures from Camera Fujifilm A100 .avi JPEG convert to NTSC-J. It would be great if you can make me a PAL to NTSC-J & NTSC to NTSC-J.

[yesgrey]

sRGB captures from Camera Fujifilm A100 .avi JPEG convert to NTSC-J. It would be great if you can make me a PAL to NTSC-J & NTSC to NTSC-J.
Start by trying this:

# PAL to NTSC-J
Input_Format PAL RGB_PC 8
Output_Format NTSC RGB_PC 8

and

# NTSC to NTSC-J
Input_Format NTSC RGB_PC 8
Output_Format NTSC RGB_PC 8
Input_Range 16 255

If you prefer you can use 16 bit depth on the Output_Format commands.

I'm not sure if these would be the correct configuration files, so let me know how they work out.

[leeperry]

A CUDA implementation would be easy to do, but I was thinking that it would be pretty limiting (in terms of supported video cards) compared to a pixel shader.
hi tritical, 3 years later times have changed...how about OpenCL then?

I kinda like the idea of keeping the gamut mapping stuff outside the VR...so we can set automatic rules in ffdshow, and get ddcc to use SMPTE-C/EBU/HDTV gamut mapping depending on the frame rate and the video stream native resolution. Also, there's no need to wait for the 96MB 3DLUT to be loaded each and every time you wanna watch a movie...so you get all the pros w/o any of the cons, too good!

Doing all this in the VR would require auto-detection of upscaled SD(madVR currently forces the HDTV gamut when x>1024) and a lof new automatic rules code that's already in ffdshow...no need to reinvent the wheel really.

I realize that doing all this in 8bit might not be the best idea, but SmoothLevels() does very impressive dithering...so this point is more or less covered. And SmoothLevels() is also using a kludge to allow 16bit in Avisynth 2.6(stacking MSB/LSB in YV16/YV24 (http://forum.doom9.org/showpost.php?p=1504207&postcount=210)). I guess that would be fairly easy to implement in ddcc? So provided that some small changes in ffdshow would be made(I think I know someone who could commit them), we could have a full 16bit avisynth pipeline in ffdshow, and feed it as P216/RGB48 to madVR :devil:

I was also told that it would be a far better idea to post-process video when already using the right colors, instead of changing them afterwards...that'd make a lot more sense to use ddcc in 16bit at the very top of my ffdshow/avisynth scripts, than using a 3DLUT in madVR at the very last stage.

Hope you'll consider it, :thanks: in advance! I really miss ddcc in Avisynth, but it's a CPU hog...getting it to run off the GPU would be a God bless, and a perfect solution for on-the-fly and automatic rules based gamut mapping. A killer combo together w/ the supreme smoothness of madVR :cool:

[leeperry]

@tritical: any chance you could make yv12toyuy2() fallback to itype=0 if it's not mod4 please?
which can easily be overcome by using this script (http://forum.doom9.org/showpost.php?p=1453641&postcount=22), that will pad black borders in order to become mod4.

it's nice to see that solutions do arise over time...now all that'd be required is OpenCL GPU acceleration for ddcc, and then this would become an entirely workable solution :cool:

[Kazuya]

Hope you'll consider it, :thanks: in advance! I really miss ddcc in Avisynth, but it's a CPU hog...getting it to run off the GPU would be a God bless, and a perfect solution for on-the-fly and automatic rules based gamut mapping. A killer combo together w/ the supreme smoothness of madVR :cool:

Automatic switching gamut would be great of course !!! :)

[tritical]

Do you want ddcc() or rgb3dlut() on the gpu?

[leeperry]

hi tritical, thanks for the reply!

well, ddcc() works in realtime, doesn't need to read LUT's and can provide gamut mapping on its own...IIRC, it was chosen to go LUT in order to drastically lower the CPU usage. Going GPU accelerated would alleviate this problem, so I don't really see the point to bother w/ LUT's anymore?

OTOH, ddcc() requires RGB24/RGB32 input, which takes a lot of CPU cycles....rgb3dlut() uses small 8bit LUT files and only needs YUY2 input.

tough call! I guess rgb3dlut() would make a lot more sense indeed...and doing the RGB32 conversion via the GPU is always a nice touch :)

[tritical]

Yeah, I guess what I was asking was what colorspace would you be using for input/output? ddcc is much easier to put on the gpu - in terms of complete feature set - (in fact I did it last night in cuda since I have a lot of experience with cuda and none with opencl), but has the restriction of rgb24/rgb32 input/output. Of course, that input/output restriction is what makes it an easier task than putting rgb3dlut on the gpu. I could add yuy2 input to ddcc, but what output format makes sense in that case (yuy2, rgb24, rgb32, all three)? Plus with yuy2 input I'd have to handle different chroma placements, upsampling methods, etc... which is kind of a pain.

[leeperry]

Oh, YUY2 input on ddcc() would rock! I'd be using YV12 input in the best case scenario, otherwise YUY2. And I'd need RGB32 output, I don't see much point to RGB24? Ideally YV12 input/output would be best, but that'd require a lot of lossy conversions I guess...or maybe you could add dithering to make it less painful? :o

That's for the regular 8bit Avisynth pipeline, because P216/Y416 input and RGB48 output could be useful sometime in the future.

I'm from team nvidia, so a CUDA version would be truly fantastic...you could always go OpenCL in the future if there's any request for it(and that you want to bother w/ OpenCL in the first place).

Indeed, a CUDA version of ddcc() that would accept YUY2 input and converts to RGB32 using the GPU would really be beyond words! If it could also convert from a YV12 input to YUY2 internally using the GPU would be even better :cool:

And feeding RGB32 to madVR wouldn't require using ColorMatrix() to convert the 601 decoding matrix coeffs to 709 for upscaled SD(because madVR uses 709 if x>1024) anymore, so that'd mean one less 8bit Avisynth plugin to process :)

:thanks:

[tritical]

In the interest of actually getting something released, I put up a new version of ddcc which has a CUDA implementation of ddcc(). Syntax wise the only thing that changed is 'opt' can be set to 2, which forces cuda to be used. By default, it will use the cuda implementation if a suitable device is found. I do not perform a search over all devices, just query the default device for the thread that ddcc is created in. I only tested it on an old 9800 gtx+, speed was the same as the cpu version on my q6600 quadcore.

I might add yuy2 support or other things in the future as time/motivation allows.

[leeperry]

ouh that was a fast, thanks a lot!

I'll be testing it and report back then :)

[leeperry]

having second thoughts, do you think it would be possible to get ConvertToRGB32() to use CUDA as well? that would be a perfect solution as a combo w/ the CUDA build of ddcc(), and far less work for you than reinventing the wheel? I guess the source code should be fairly easy to locate :)

[leeperry]

having even more thoughts about it, if you could embed a CUDA version of ConvertToRGB32() and ddcc() into one single plugin, this would avoid one very lossy 8bit pass? going YV12 > 32fp RGB(or RGB48 for that matter) > ddcc > RGB32(and RGB48 as well, as madVR supports it natively...but that'd require some modifications in ffdshow).

:thanks:

[tritical]

Creating a full converttorgb (with different interpolation functions, chroma placements, interlaced vs progressive for yv12, etc...) would take more time than I want to spend. I would be willing to start with a single case for ddcc: yuy2 input with mpeg2 chroma placement and linear interpolation for upsampling to 4:4:4 and output rgb32. Would that be usable?

[leeperry]

Oh, you've got me a bit lost here...is it what RGB32HQ in ffdshow and ConvertToRGB32() do? then that would be great :)

from reading the rgb3dlut() manual, "mpeg2/mpeg4/h264" chroma placement sounds good, I think the "Mitchell-Netravali two-part cubic interpolation" used to look better than "linear interpolation"...but if that's too much trouble, let's forget about it. I could always blur the chroma in madVR if I like(I upscale before going through the Avisynth scripts then I let madVR downscale using the GPU, otherwise LSF gives jaggies at 1:1 resolution...hence the requirement to use "SuperSampling" as they call it).

And I guess MPEG1 wouldn't look too ugly when using MPEG2 chroma placement? I dunno what placement madVR and ffdshow assume, prolly MPEG2 as well :o

The main goal would be to have the RGB32 conversion done through CUDA, in order to save CPU cycles indeed. And possibly output RGB48 to madVR when Avisynth/ffdshow will allow it.

:thanks: for all once more, as you're one of the shapers of my dreams :cool:

[leeperry]

OK, I finally found the ddcc() calls I was using a few years back, but now ddcc() complains that I don't have "cudart32_40_17.dll" :o

I run a 9600GSO(rebadged G92 8800GS w/ 96SP) and the 257.21 drivers on XPSP3, and I've got "nvcuda.dll 6.14.12.5721". CoreAVC 2.55 CUDA works like a charm, and "CUDA" support is checked in GPU-Z.

Is that a DLL that can be found in the dev.kit? http://developer.nvidia.com/cuda-toolkit-40

Or shall I update to the newest WHQL drivers? They don't mention CUDA 4.0, though: http://www.nvidia.com/object/winxp-275.33-whql-driver.html

[jmac698]

I'm new to t3dlut etc., is there a way to convert yuv (rec709) to Lab?

[leeperry]

Because of the CUDA error message, I cannot seem to be able to use ddcc() in SSE3 mode either...I did set "opt=1" so it shouldn't even try to use CUDA? :o

PS: ok, using 1.11 and spot-on gamut mapping in plain RGB32 fed to madVR is really major bliss! I can't use spline SuperSampling anymore because the software RGB32 conversion and gamut mapping are quite a CPU hog...can't wait for the full CUDA version. :thanks:

[Yellow_]

Having now established a way to export 10bit h264 and 16bit RGB using avs2yuv is it possible to use t3dlut to export 10 / 16bit rather than it dither back to 8? Is setting output bitdepth to 16 in the LUT generation all that is reqired?

[tritical]

I'm new to t3dlut etc., is there a way to convert yuv (rec709) to Lab?

Not at the moment. Why do you need to convert to LAB? Conversion to LAB from XYZ is simple, but outputting lab as 8-bit would not work very well.

Having now established a way to export 10bit h264 and 16bit RGB using avs2yuv is it possible to use t3dlut to export 10 / 16bit rather than it dither back to 8? Is setting output bitdepth to 16 in the LUT generation all that is reqired?

Current version of t3dlut only supports 8-bit output. I am not update to date on avisynth 2.6 or whether it supports higher bit depths. The 8-bit output requirement is a restriction of avisynth (at least with 2.5.8), if avisynth supports higher bit depths then t3dlut could be made to dither to those.

but now ddcc() complains that I don't have "cudart32_40_17.dll"
Is that a DLL that can be found in the dev.kit?
Yes, it is part of the 4.0 toolkit. The ddcc.dll is linked statically against it so it must be found in the system path in order for the dll to load at all. I believe I included it in the ddcc.zip archive.

[jmac698]

I want to do processing in L*a*b, but output to 8bit yuv again. I'm using this to colormatch videos, so lab is the ideal colourspace for this.

If we wait for high bit support in avisynth, it will be a long time. I suggest supporting one of the workaround formats. Smooth levels for example supports high bit depths and dithering down to 8 bit. It uses MSB stacked vertically on top of LSB. My deepcolor tools uses a separate clip for MSB and LSB. I also support levels adjustments, and I can input true highbit videos. I helped with the update to sashimi to support reading high bit quicktime formats.

[Yellow_]

Current version of t3dlut only supports 8-bit output. I am not update to date on avisynth 2.6 or whether it supports higher bit depths. The 8-bit output requirement is a restriction of avisynth (at least with 2.5.8), if avisynth supports higher bit depths then t3dlut could be made to dither to those..

Thanks to the Dither 1.9 functions, stacked lsb/msb and avs2yuv, 10bit h264 encoding and 16bit image writing via Imagemagick using standard out successfully works with Avisynth 2.5.8.

A git build of ffmpeg is required to successfully play 10bit h264 however and that also appears to work.

[leeperry]

Yes, it is part of the 4.0 toolkit. The ddcc.dll is linked statically against it so it must be found in the system path in order for the dll to load at all. I believe I included it in the ddcc.zip archive.
Oops, my bad! So I've copied it to the system32 folder but now it says "opt = 2 but no cuda device detected".

Can I send you a log somehow? Should I install the dev.kit in your opinion?

And once that'll work, how to figure out what to set for "oog" if you don't mind me asking?

:thanks:

[tritical]

leeperry, it is probably a driver issue. I would try upgrading to the latest driver from nvidia (275.33?). As for 'oog', I think 1 would generally be preferable since it maintains hue/saturation. It's really just a personal preference.

jmac698/Yellow_, I will look in the stacked MSB/LSB output. Or someone else can modify it if they feel so inclined. I can merge the changes.

[leeperry]

As for 'oog', I think 1 would generally be preferable since it maintains hue/saturation.
Oh indeed, my CRT barely reaches SMPTE-C and when I map gamuts from EBU...if I set oog=0 then the colors end up utterly undersatured :o

leeperry, it is probably a driver issue. I would try upgrading to the latest driver
you nailed it! I was afraid to update coz that'd mean setting up all my custom res all over again, but they seem to have improved the custom res panel..and it all went like a breeze :)

BTW, some tests results in VDUB(Q9450@3.5Ghz on XPSP3):

ddcc(chr_i=3,gam_i=5,gam_o=5,ofile="P:\CRT.txt",threads=4,opt=1)
http://www.pixelz.fr/e/3/4/ca018bb46b31e6ba87f2858bae662.png

=252 fps

ddcc(chr_i=3,gam_i=5,gam_o=5,ofile="P:\CRT.txt",opt=2)
http://www.pixelz.fr/e/6/8/850977083923dfb2fa24777dd5582.png

=230 fps

How could I change the cores affinity? I'd rather have the load evenly balanced between the four cores if any possible :o

I've tried to force "threaded optimization" for my media player in there, but that gives randomly dropped frames(that don't occur when it's left on "auto"): http://www.pixelz.fr/9/f/4/dd152000bd4ff9f4d18e332d11adct.jpg (http://www.pixelz.fr/9/f/4/dd152000bd4ff9f4d18e332d11adc.png)

PS: ddcc() works beautifully in combination w/ CoreAVC CUDA of course :cool:

That's an untouched BD w/ CoreAVC CUDA 2.55 + dddc() CUDA + madVR Spline downscaling: http://thumbnails45.imagebam.com/13719/e97bf1137184129.jpg (http://www.imagebam.com/image/e97bf1137184129) http://thumbnails46.imagebam.com/13719/d707a4137184130.jpg (http://www.imagebam.com/image/d707a4137184130)

PPS: it's pretty annoying that "ConvertToRGB32" crashes most of the time when used in MT("",4) mode...lotsa wasted CPU cycles running it non-MT :o

[Yellow_]

jmac698/Yellow_, I will look in the stacked MSB/LSB output. Or someone else can modify it if they feel so inclined. I can merge the changes.

Excellent, enquring if you've had time to give this any more consideration.

[leeperry]

Hi tritical,

I've been using the CUDA build of ddcc() ever since you released it(XPSP3/96SP 8800GS/275.33), but I've encountered 2 problems when switching back and forth between input gamuts(chr_i=0/2/3) in ffdshow(without restarting the video). In both cases, I wasn't using CoreAVC CUDA...only PotPlayer/madVR and ffdshow audio+video.

That's the call I was using:
ddcc(chr_i=3,gam_i=5,gam_o=5,ofile="P:\CRT.txt",opt=2)

1) A few days ago, after switching back and forth like 4 times, I got the "opt = 2 but no cuda device detected" error message...so I closed the video, reopened it and it worked fine again.

2) a few mins ago, I was switching like +8 times(trying to figure out if this 30fps european SD video was EBU or SMPTE-C :rolleyes:) then I got a brief green flash at the second third of the screen, the computer locked up on the last video frame before the green flash...and bye bye Kansas, not even a soft reset would allow the computer to work again. My mobo BIOS decided that the graphic card was crashed for good and ran a hard reset instead.

That's too bad I've got no log to provide you w/, hopefully you could bulletproof the realtime changes in order to avoid any crash/deadlock please?

:thanks: again for your hard work, much appreciated!

[leeperry]

Ahhh, there's a new option in madVR 0.67 to force prebuffering when seeking, so I was trying it and enabling/disabling LSF on the fly in ffdshow to see how the new option would react(I use several scripts in ffdshow: SmoothLevels(for TV>PC conversion)>LSF>GrainFactory3>ddcc). I was running madVR in FullScreen Exclusive mode, and after I had toggled LSF like 6 times in a row, I got the very same green flash at the second third of the screen(like this: http://thumbnails50.imagebam.com/14100/129389140995987.jpg (http://www.imagebam.com/image/129389140995987) ) for a half second, then the picture froze, the mouse froze a few secs later...and I was forced to reboot. My mobo BIOS managed to get away w/ a soft reset this time.

Any chance you could reproduce tritical? Any chance for a fix please please please?

I will now refrain from making realtime changes in my ffdshow Avisynth scripting, and I have to say that I'm really amazed by the colors and PQ when using proper gamut mapping via ddcc() :eek:

:thanks:

[tritical]

@leeperry I would fix it if it had anything to do with ddcc, but there's no way ddcc can cause that or anything in the code I can change. It must be either a driver/card issue, or the software you are running avisynth in is not closing the associated thread(s) (and associated cuda context(s)) properly.

Also, for anyone using it, I would not advise using setmtmode or other avisynth multithreading methods with ddcc+cuda. However, it should work correctly as long as the getframe method is called in the same thread as the constructor/destructor.

[leeperry]

oh ok, thanks for the reply! but ddcc() works perfectly fine in software mode when messing in realtime w/ the avisynth filter of ffdshow...it seems rather clear that sometimes the CUDA connection is not closed properly and hell breaks loose at the GPU drivers level =/

so indeed ffdshow doesn't close the threads properly, and "Leak"(the coder who took care of the avisynth support in ffdshow) has recently made it clear to me that he doesn't plan on developing it any further.

[leeperry]

OK I've found my old Avisynth scripts and going:
ConvertToYUY2()
rgb3dlut(lutfile="P:\smpte-c",threads=4,itype=2,b=1.0,c=0.0)

carries many advantages:
-no CUDA drivers required, meaning that ffdshow won't crash my computer anymore when rolling gamuts on the fly
-no need to make a CPU hogging ConvertToRGB32() conversion
-the ability to use oog=1, which isn't possible in CUDA mode
-ddcc() CUDA still uses quite a lot of CPU cycles from what I've seen, mostly due to the nvidia drivers I presume...OTOH, rgb3dlut() is very light CPU-wise.

I gave up on this solution because up to very recently, mVR only supported YV12 input.

Also, using rgb3dlut() in ffdshow allows automatic profiles based on resolution & frame rate, and mVR now uses a new colorimetry system called "yRGB" that requires a 16bit 96MB LUT(that takes forever to load), won't remember the last used gamut and won't allow automatic profiles (yet)...so all in all, going back to the old school sounds very reasonable. Shelling out $500 on a new i7 box in order to get CPU based gamut mapping simply does not :rolleyes:

I fully realize that doing all this in 8bit is a terrible idea, but 16-235 SMPTE-C(the smallest gamut in the industry) isn't quite as data intensive as xvYCC I guess. And tbh SmoothLevels() does such an amazing job at dithering that I highly doubt anyone could DBT it from native 10/12bit.

PS: ends up 8bit LUT's are 48MB, I've got 3 gamuts and 2 YUY2 LUT's for each decoding matrix...so that's 240MB of LUT's(I don't see how HDTV could use BT601).

PPS: I might as well input and output YUY2 using t3dlut(), but then I'd have to rely on mVR to either go 601 or 709 RGB...and t3dlut() requires far more CPU cycles than rgb3dlut().

Actually, rgb3dlut() in YUY2 is so light on the CPU that I can use Gavino's script (http://forum.doom9.org/showpost.php?p=1453641&postcount=22) to automatically become mod4 and yv12toyuy2(itype=2,threads=4) http://forum.slysoft.com/images/smilies/agreed.gif

yv12toyuy2(itype=2,threads=4,b=0,c=0.75) is way too edgy...0.33/0.33 would appear far more reasonable, as madshi advised (http://forum.doom9.org/showpost.php?p=1276180&postcount=426).

[leeperry]

Alright, I will need to do screenshots comparisons against vanilla ddcc() in order to ensure that gamuts mappings & YCbCr decoding matrixes are processed properly, I'll put my 240MB of LUT's on a PC8500 ramdisk for instant access then it'll all be looking very much kosher to me :D

It's great how it all fits perfectly together in order to provide a very impressive HTPC experience :)

The ability to change the bicubic coeff for both the YV12>YUY2 interpolation and RGB32 conversion really allows you to finetune it all perfectly to your 1) video processing pipeline 2) equipment 3) taste...I'm really stunned by the PQ tbh :cool:

[leeperry]

Bumpity, Bump :)

AVS 2.60 supports ConvertToYUY2(chromaresample="Spline64") in MT mode, so that more or less renders yv12toyuy2(itype=2,threads=4) useless? And it's not mod4-only so that makes my life a lot easier.

Also, I might consider creating a bigger ramdisk and use 16bit YUY2 LUT's instead of 8bit, but why is t3dlut() so much more power hungry than rgb3dlut() again? :o

[nand chan]

Does anybody have plans for the future of the .3dlut spec, or possibly a v2/v1.1?
These are some of the issues I've noticed while working with the current, and I'd be more than happy to help discuss changes / alterations to improve these:


Many programss still have to scan through the parameters file to find out some information that is not present in the tags
No tag for the value range (full range, limited range, min/max, etc)
No concept of color space - a color-aware 3dlut could easily be achieved with optional gamut tags, this would allow tools such as madVR to transform color into the input color space
It seems like nothing actually uses the “color encoding” fields, they're set to 0 even on YCbCr LUTs. Am I mistaken of its purpose? This could be improved to reflect the color encoding nature (YUV, RGB, BGR, etc)
No currently defined compression methods

[madshi]

yesgrey was planning to specify the meaning of the color encoding fields for a while. He hasn't had the time to do that yet.

I'd welcome an addition to the 3dlut spec with the changes you're suggesting. Hopefully yesgrey can participate? The problem is that yesgrey is taking a break for personal reasons, so this is a bad time for him to extend the spec. I don't know how much time (if any at all) he will have to participate in the next couple of days/weeks.