[FFmpeg-user] Levels and Primaries

[Robert Krüger]

On Wed, Feb 12, 2014 at 4:47 PM, Thomas Worth <dev at rarevision.com> wrote:
> On Mon, Feb 3, 2014 at 6:35 AM, Rio Kierkels <riokierkels at gmail.com> wrote:
>>
>> I hope you're still with me and if you are I hope you have anything to say
>> about it. May it be some experience with the same issues or even the answer
>> to this debacle. Use the materials in this post as you like to do your own
>> tests and you can ask me anything you want be it to run certain tests on
>> the equipment I have available or maybe even contacting our broadcasters
>> for some specific information.
>>
>> We want FFmpeg to be as good as it gets and I really think we can get this
>> one right!
>
>
>
> *Big breath*
>
> Okay, I haven't read this entire thread so I apologize if ay of what I'm
> about to say has already been mentioned. But I'll just give my take on this
> issue, since it was a big one for me during the development of 5DtoRGB and
> other in-house tools.
>
> First off, I could never trust the swscale library to do its job properly.
> Its scaling was just plain not right in every circumstance, and the color
> was never right either meaning something is fundamentally wrong with the
> combination of scaling/matrices. This is all probably okay for pirating
> movies, but for critical color work like we do here in the film industry it
> just isn't good enough. In the end I wrote my own scaler from scratch. It
> works perfectly, with perfectly repeatable results and with all the options
> a post house would want for this sort of thing. But it wasn't easy...
>
> When I say "combination" of scaling/matrices, I mean that even though
> you're performing your BT.709 matrix math on an RGB source, this doesn't
> mean it's going to come out right on the other end. For example, if the
> image is matrix encoded and then scaled, that won't give the same result as
> scaling and then matrix encoding. Also, you have to scale luma (Y) and
> chroma (CbCr) separately, and using different ranges (0-235 and 0-240
> respectively). And then encode them. Or vice-versa. See all the potential
> for problems here? Anyone, and I mean anyone trying to write a scaler and
> color space converter needs to read the relevant portions of Charles
> Poynton's book. Don't even waste your time (and everyone else's), until
> you've fully digested those chapters. It's what anyone else who knows what
> they're doing has already done, and the only way to ensure your output
> looks the same as Apple's, Avid's and Adobe's.

Did you file bug reports with reproducible cases were you had
incorrect numbers (just asking, no subtext intended)? I mean it is
completely legitimate to come to the conclusion to do it yourself and
build a product upon that competitive advantage but I would be
surprised if such a bug report proving that swscale did indeed produce
incorrect numbers (which may very well be the case) would be ignored
but I may be wrong here.

> projects have contributors from around the world. So, I don't know how much
> of this applies to the FFmpeg project but I would keep this in mind when
> asking for features that only satisfy a relatively small portion of the
> user base.

Again, it would be worth a try if a bug report proving that swscale
produced incorrect colors or inferior scaling quality for a certain
conversion (which may very well be the case) with a reproducible test
case would get ignored. It is of course not an easy task to set one up
because one needs to have all the theory figured out that you mention
above.

Cheers,

Robert