raw UYVY 4:2:2 Bright blue / red UV :-)

[Yellow_]

hi I have some raw UYVY raw 4:2:2 which appears as bright blue in dark areas to yellow for bright areas or if I swapUV red to green.

Obviously missing last step mixing luma and CrCb for correct preview. Using rawsource and sashimi give identical results.

Just missing the correct conversion to RGB preview.

[Guest]

Post a sample.

[Yellow_]

sorry, thought it'd be a simple answer.

http://dl.dropbox.com/u/74780302/sample.yuv

Image size is around 1056x705, going too large (expected to be 1920x1080) causes Avisynth to give an error "File too small for even one frame"

I do get a frame with either:

rawsource("sample.yuv",1056,705,"UYVY")

or with sashimi

RawReadInterleaved("sample.yuv", "UYVY", 1056,705)

But not a correct frame by a long way.

[poisondeathray]

I think 705 is your problem. Not divisible by 2. I think it's required for Y'CbCr 4:2:2 . RGB can be divisible by 1

[Yellow_]

hi PDR, unfortunatley not, I get same output with numerous heights, just tried 680 and had the same, saturated blocks of color. :-(

[poisondeathray]

I haven't looked at your sample yet, but how did generate it?

I just did a quick test and rawsource opens uyvy422 fine on another sample

[poisondeathray]

hi PDR, unfortunatley not, I get same output with numerous heights, just tried 680 and had the same, saturated blocks of color. :-(


It has to be the matching width and height of the actual data . You can't just randomly pick numbers

The reason why you got the "File too small for even one frame" error is the filesize didn't match. With raw yuv every frame should be the same size when using the same sampling and dimensions. This means you entered dimension values too small

Here is a real 1280x720 uyvy sample .
http://www.mediafire.com/?ktkv35p5gux95it

Note if you use different width numbers like 1260 you get messed up results too

rawsource("uyvy422.yuv", 1280,720, "uyvy")

Again, how did you generate your sample and what are the real dimensions ?

[um3k]

This fixes it:
rawsource("sample.yuv", 1056, 704, "UYVY")
ConvertToYV16()
mt_lut("x 127 + 256 %", "x", chroma="process")
Strangely, the chroma is offset and wrapped. My guess is that whatever program made it used a signed integer when it should have used unsigned.

[Guest]

Very good find, um3K.

But ConvertToYV16 requires Avisynth 2.6. Can you do it in 2.58? :)

[um3k]

Have I just been given homework? :P

Anyways, here's one way, which requires Kassandro's RemoveGrain (http://home.pages.at/kassandro/RemoveGrain/) plugin:
rawsource("C:\Users\Justin\Downloads\sample.yuv", 1056, 704, "UYVY")
Interleaved2Planar()
mt_lut("x 127 + 256 %", "x", chroma="process")
Planar2Interleaved()
Do I get my Avisynth diploma now?

[Guest]

Hey, don't get me wrong, you've just been elevated to the pantheon of Avisynth greats. All hail!

[um3k]

Woohoo, pantheons are awesome!

Also, the modulo is corrected now. Darn off-by-one human errors...

[Yellow_]

It has to be the matching width and height of the actual data . You can't just randomly pick numbers

Again, how did you generate your sample and what are the real dimensions ?

The exact dims I understand to be the ones I used above, the non divisible by two height value.

The source is data captured from the feed to the LCD and possibly the h264 encoder within a Canon DSLR. Silent pic via Magic Lantern Firmware.

[Yellow_]

This fixes it:
rawsource("sample.yuv", 1056, 704, "UYVY")
ConvertToYV16()
mt_lut("x 127 + 256 %", "x", chroma="process")
Strangely, the chroma is offset and wrapped. My guess is that whatever program made it used a signed integer when it should have used unsigned.

Ok, many thanks for the solution, as mentioned above the raw source is from the magic lantern firmware, so to fix the signed integer problem they can probably alter their firmware to write it correctly, is the signed problem detrimental other than not so staight forward to correct.

**EDIT**

Wrapped? The mt_lut seems to be shifting the chroma? Is the source in that case JFIF? Where chroma is full range and I think described as centred at 0 +128 & - 127? If that makes any sense.

[um3k]

I'm having trouble finding a reference for JFIF chroma storage, but if I understand your post correctly, that could indeed be the case, and would make sense in the context of a (primarily) still camera. Regardless, a modulo addition works quite nicely to fix it.

[Yellow_]

Yeah sorry I tried looking for JFIF when posting but couldn't find reference to the instances I'd read about JFIF, but here this says it all I think, pages 175 - 176:

http://books.google.co.uk/books?id=dSCEGFt47NkC&pg=PA175&lpg=PA175&dq=chroma%2BJFIF%2Bvideo&source=bl&ots=OL4zeJ7Vyr&sig=aoNstetOv-HN7PpZ3i-dOj2JxVs&hl=en#v=onepage&q=chroma%2BJFIF%2Bvideo&f=false

[Yellow_]

The raw JFIF source as posted above is assumed to be the feed into the cameras h264 encoder from raw jpeg data, so would the change in chroma storage get changed by settings in the h264 encoder to a more 'standard' rec709 rather than as Poynton calls it a 'mess'.

Obviously the h264 out of the camera is correct and 1920x1088 rec709 primaries, like jpeg sRGB, bt601 matrix co effs like jpeg sRGB images, with a rec709 transfer curve, so scene referred gamma rather than 2.2 display referred sRGB. Also the h264 stream is flagged full range.

Would like to establish where chroma is stored in the final h264 ie: 16-240 rec709 or +- 128 JFIF and also chroma placement, centred interstitially as jpeg or left of with typical YCbCr.

If chroma is over full range but +- 128 rather than 1 - 254 then does the fix above put the chroma full range 1 - 254, if so that would be xvYCC extended gamut theoretically 1.8x the number of Munsell colors but maintaining backward compatibility with rec709 extended gamut whilst maintaining rec709 sRGB color primaries.

[um3k]

I can't comment on the chroma placement, but if the camera is feeding video of this resolution to the h.264 encoder, that would go a long way towards explaining the "coarseness" I perceive in DSLR video. The shallow depth of field is wonderful, but it's kind of sad that my measly HV20 from 2007 can outperform a modern DSLR on any test involving resolution or aliasing. On a side note, thanks for reminding me about Magic Lantern, I used it to enable video on my 50D. That should satiate me until DSLR video actually reaches a level of quality I feel is worth investing in.

[Yellow_]

No problem, ML provides so much. I too have a HV, the HV30, actually bought the T2i as it's replacement and use the T2i 99% of the time, agree the HV's have better resolution and detail but seems noisy even in bright daylight and that's using the locked exposure / zero gain / shutter at 180deg fiddle. But still enjoy it.

Thanks for the solution to the raw chroma. ML development seem to be looking into the raw jpeg path through the cameras to see what improvements can be made such as resolution hopefully data closer to jpeg image quality can be realized.