10bit quicktime sample requested v210 format

Hello, In order to test and complete my Deep Color Tools, I need a sample Quicktime movie in v210, yuv format. Ideally, I just need a few frames of real 10bit colorbars, also a short clip of real video would be nice. Better yet, how can I create such files with free software. I have no way to acquire such video, so I'd have to export colorbars or some kind of 10bit yuv paintprogram.

Here are a few frames: For both samples, I exported AJA v210 mov using "trillions of colors" (which indicates 10bit+) Sample 1: 1280x720p29.97 Belle Nuit Test Chart Method used: imported 8-bit RGB TIFF into After Effects in 32-bit float mode Sample 2: 1920x1080p50 Park Joy Method used: imported 3840x2160,16-bit RGB SGI sequence into AE, scaled to 1920x1080p50 in 32-bit float mode PS. You can encode to v210 in avi or mov container using ffmpeg, but I'm not sure of the precision or if it's a 10-bit+ workflow for RGB<=>Y'CbCr conversions e.g ffmpeg -i input.avi -vcodec v210 -an output.mov Let me know if you have other requests Cheers

That's great, thanks! Of course if you have After Effects, it's not a big deal, but I'm making a free program. What sorts of filters do you think would be useful in Avisynth that you can't do in your tools? I was thinking of some of the cleanup you do in old film restoration.

If you were following this thread, I've made working 48bit levels management in my deep color utilities, and also was able to write a new file importer for v210 files - thanks to your samples! And yes, I could use more samples, specifically made ones for testing. I need these: 480p, 480i, and then all resolutions with sound. Really, it's up to you - what files would you use in production? And some colorbars like these I can soon let you use many avisynth plugins with full 48bit processing - for example IVTC can be done on upper 8 bits as a proxy and then applied to 48bits. I can easily do blur/sharpen/gamma correct resize/color conversion etc. I think this is exciting :) And where did that parkjoy come from? It's definitely using all the bits.

Yes, avisynth only uses 8bit, but I invented a pseudo-format which stores 16bits as two video clips, then functions to treat them as one. And I didn't explaiin, I'm wondering if you have software that creates 10bit color bars originally. Any pro equipment should send this over SDI and you can just cap it. Actually SD ones are good too. Just helps me verify if I generate it in script in 10bit someday, or use as is for now. Even with ffmpeg, I have no way to generate real 10bit files. I can transcode 8bit source to 10bit files, but where is my 10bit source generator? ffmpeg gives you a color generating function but it's only specified in RGB. Update: very cool! I've seen those images many times, never knew where they came from. Great link! I can use that rgb2yuv program, but how to create 16bit SGI files? Even so, I still can't create YUV directly (but should be enough for 10bit yuv). If there's an output plugin for povray, that's pretty easy to script in. Hmm... Update2: yep, povray can create 16bit linear rgb in PNG and PPM. With some conversions I could finally get 10bit yuv, what a pain though.

The 16-bit SGI files were scanned from film , you can use other utilities to manipulate them e.g. xnview You can generate RGB test patterns in software in 16 or 32bit mode, export using 16-bit tiff of png, or 32bit openexr . Then do the conversion to v210 in 32-bit linear light. I'm not familiar with povray, but if it can't do this then I'll generate some SMPTE bars for you

In povray it looks like it will be something like this: Code:

How do you know it's a "valid" 10bit source? The answer is you don't know unless you have something like a gradient to look at. Color bars , SMPTE bars , etc... are less useful for this testing , because there are no gradients - they show discrete solid uniform colors (ie. already quantized, so 8bit will look the same as 10bit). While you can get gradients in live footage (like skies, shadows), it's easier to see with computer generated ramps, and you can more easily start with higher precision (like a 16 or 32bit RGB format). Not all cameras output a 10bit signal through HDMI or HD-SDI (many are actually output 8bit even though the A/D signal processing upstream may be higher) v210 derived from a true 10-bit or higher source should show a smooth histogram for gradients, not quantized values or banding. (if you try to generate a v210 sample from an 8bit greyscale ramp for example, many programs will warn you that the bit depth is exceeded. If you do it anyways, and re-import, you will notice banding and aberations in the histogram) So even if you're working in a 16 or 32-bit workspace with 10-bit v210, if that asset was derived from an 8-bit source (computer generated or not), you may show banding. The higher precision workspace will help to reduce new banding during manipuations, but not help "baked in" values from an 8-bit source. For example , in 16bpc , RGB values can be 0-32768 in 16bit instead of 0-255 in 8bit mode. But the values are already quantized as soon as it touches avisynth, even before you do any adjustments or color corrections. v210 decoded properly same v210 clip decoded in avisynth ffms2, direct avs importer But ffmpeg does support 10-bit input and output directly; -if you feed true v210 source , encode v210 => no banding -if you feed true v210 source through .avs, encode v210 => banding (and ffmpeg give warning source does not equal 10-bit) So it appears avisynth is indeed the culprit I would recommend making testclips derived from 16bit RGB generated ramps, where defects can be more easily seen. Any curves or levels adjustments made will be very sensitive to show breaking up in the histogram, even if the visual change is subtle in the actual image (for example a 6-bit LCD panel might display differently than a 10-bit panel, but the histogram will be sensitive to the banding eitherway) I'll test your "deep color tools" when I get a chance , if 9bits were salvaged or it was dithered as you mentioned in the other thread, it should make a difference For now here are some other clips: Radial Ramps, Computer generated 16bit RGB ramps => v210 SMPTE NTSC Bars 10bit RGB => v210 5sec clip shot with Arri Alexa in ProRes422 => v210 (mediafire only accepts 200MB clips, so this is split rar archive)

I think what's going on is this. There are only 256 histogram bins, each covering a range of 128 32-bit values. The V210 input has (I think) 880 (220*4) different values, ie the usual [16, 235] expanded from 8 bits to 10. So some of the histogram bins will cover 3 input values and some (roughly 7 in 16) will cover 4. Hence the spikes. In the other histogram, there are only 220 input values, so we get 35 missing RGB values, ie the black gaps in the histogram.

Thanks poisondeathray and Gavino. This is what I expected. When I export your 16btr RGB ramp file to 10bit 4:4:4 BM codec all spikes gets soften- AE show smooth histogram, so I think you're right :) Does it mean codec is 4:4:4 capable? New Canopus HQX 10bit (4:2:2) codec also smooth them, so does it mean it's actually 4:4:4 capable? Is this histogram test 100% accurate to say if converted video is 10bit or not (eg. for codec, workflow testing)? Yes- 8bit falls very quickly during grading. Thanks, Andrew