[Bf-vfx] Formats and Color

[Andrew Hunter]

Hey Peter,

On Sun, Apr 8, 2012 at 2:39 PM, Peter Schlaile <peter at schlaile.de> wrote:
> Hi Andrew,
>
>> Call me crazy but I feel that Blender should only accept image
>> sequences rather than movies. That ideological but it simplifies many
>> things.
>
> Yes, I actually *do* call you crazy at this point :), since I personally
> like Blender for the fact, that you can throw any video file on it and
> it will work.

Call it differences in origins :) High end vfx always has been and
will always work on the paradigm of separate, discreet frames to
create motion (a film strip scanned). Modern video efficiency and
compression is all about interdepenance among frames.

> If you like to work with image sequences, that works nevertheless, too.
>
> And sure: I know, why most people start at some point to use image
> sequences in other software packages - but that says actually more about
> the inability of those software packages to handle input files properly...
>
> (frame exact seeking comes to mind...)

Or the appropriateness of formats for random seeking and data
manipulation rather than sequential playback (H264 I'm looking at you
:P).

>> Furthermore, the color management system needs to be able to chain
>> arbitrary transforms at any stage of the process.
>
> sure, should be easy to add.
>
>> What about the internal working space of Blender? Modern motion
>> picture cameras have gamuts that greatly exceed the SRGB primaries
>> enforced by the image loading code.
>
> but shouldn't Blender actually just work in float space, only clamping the
> value at the final rendering step and everything should be fine
> and dandy? (still scratching my head on this one)
>
>> What I am suggesting is that the image loading code should just serve
>> the data. Nothing more :)
>
> Half agreed :) I read a little bit more in OCIO documentation. It really
> looks pretty nice. Probably we can replace all the swscaler mumbo jumbo code
> with OCIO.
>
> Still, I think that main blender should have to deal with either RGBA byte
> or RGBA float and *not* the full detailed list of color coding formats
> ffmpeg (or any other image input library you can name) supports...

Agreed. Part of the API design of OpenImageIO is to _only_ provide RGB
values (not limited to but at a minimum). Like Blender, the image
loading code is responsible to converting pixel formats to what the
user requests.

[...]
>
> Nevertheless: noone says, that you can't generate proxy files as a first
> step to work on. But I don't want to *force* people to generate proxies.
>
> As I said: usually you first build a proxy and do all your work on that
> and use the original file for the final conforming step.
>
> But: if you can get away without that, why bother?

You can get away with a proxy so long as your proxy doesn't mess with
the color data. ProRes is notorious for this with "Automatic gamma
correction" applied.

> (Only to make the OpenImageIO folks proud? Naaah...)
>
[...]

Sincerely,

Andrew