Re: Issue 147 in ffmbc: rgb to yuv422p10 color shift PRORES issue

[ff...@googlecode.com]

Updates:
Summary: rgb to yuv422p10 color shift PRORES issue

Comment #5 on issue 147 by baptiste...@gmail.com: rgb to yuv422p10 color
shift PRORES issue
http://code.google.com/p/ffmbc/issues/detail?id=147

(No comment was entered for this change.)

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[ff...@googlecode.com]

Comment #6 on issue 147 by baptiste...@gmail.com: rgb to yuv422p10 color

shift PRORES issue
http://code.google.com/p/ffmbc/issues/detail?id=147

Can you also please upload your source file somewhere ?

[ff...@googlecode.com]

Comment #7 on issue 147 by gtrply...@gmail.com: rgb to yuv422p10 color

shift PRORES issue
http://code.google.com/p/ffmbc/issues/detail?id=147

After researching the issue further, my summary, findings, and solution are
as follows:

When encoding HD sized material in ProRes originating from an RGB-based
codec, there is a color shift due to some misinterpretation of color
primaries during RGB-YUV conversion.

This can be resolved during encoding by using the flag "-color_primaries
bt470bg". This avoids or mitigates a procedural color conversion based on
frame size achieved in lines 282-304 of proresenc.c (as of 0.7rc8). This
also seems to preserve full 10-bit fidelity.

Rather than writing a patch, it may be more beneficial to include this
flag's usage in documentation.

[ff...@googlecode.com]

Comment #8 on issue 147 by andrew.k...@gmail.com: rgb to yuv422p10 color

shift PRORES issue
http://code.google.com/p/ffmbc/issues/detail?id=147

It's not a proper "fix".

Default:
RGB->601 YUV (due to ffmbc bug)-> ProRes tagged as 709->decoding through
709=wrong RGB on display

With your tagging:
RGB->601 YUV (due to ffmbc bug)-> ProRes tagged as 601->decoding through
601=correct RGB on display (but this is not a proper fix)

This ProRes file has 601 color spaces, where it should have 709, as it's HD
file. Also some software don't read flags but use matrix based on frame
size and than your file will still look wrong.

Proper way (for HD file):
RGB->709 YUV -> ProRes tagged as 709->decoding through 709=correct RGB on
display (and proper color space)

[ff...@googlecode.com]

Comment #9 on issue 147 by troy.sob...@gmail.com: rgb to yuv422p10 color

shift PRORES issue
http://code.google.com/p/ffmbc/issues/detail?id=147

Related to http://code.google.com/p/ffmbc/issues/detail?id=114

The issue is the RGB to / from YCbCr conversion, all of which are hardcoded
to 601 in FFMPEG / FFMBC. Also applies to SSE / MMX optimizations.

Affected files:
swscale.c
swscale.h
utils.c

[ff...@googlecode.com]

Comment #10 on issue 147 by cy.thomp...@googlemail.com: rgb to yuv422p10
color shift PRORES issue
https://code.google.com/p/ffmbc/issues/detail?id=147

I can confirm that I'm also seeing this issue.

Using either full range DPX or full range v210 files at both 1920x1080 and
3840x2160 produces a ProRes 422HQ file with ITU-R BT.601 colourspace
(according to MediaInfo)