Re: [Openexr-devel] OpenEXR <-> Cineon/DPX

[Kevin Wheatley]

Some thoughts... as a Service provider for Film images ....

When you shoot a film as a DoP, you do all sorts of things to get the
look you want, sometimes this involves film. If you go to all the
trouble to make a look on your film, you don't want somebody undoing
it back to scene light exposure unless they are going to rebuild it
back again.

As such we can't do anything to the images comming out of our scanner
that looses the look. Thus we have a desire for simplistic "container
conversion" in out Cineon/DPX <-> OpenEXR suggestion. But openEXR is
not a log file format, so you want to in some way linearise it, but
not loose the look.

Besides as a service bureau we don't have enough information to do
this, e.g. any scene mesurements, filter choices, spectral readings of
the lens+filters used etc.

Going in the forwards direction (i.e. to a print) the choice of print
stock is also part of the look the DoP is going for, but often this is
also not available to us, so we can't forward transform into the real
world either.

Add to this that the scanning and recording of images could be done by
more than just ourselves, we couldn't even rely on a closed loop
system approach to figure out anything better.

All this together means that we can't transfer back to any real world
metric. If there is a desire to maintain the purity of the file
format, that's cool, we'll just not be able to offer OpenEXR as a
service without a large amount of additional info - which in the real
world productions just don't care about at the time!


Some thoughts... as an "Image Scientist" ...

I think its a great idea to have things stored in files based upon
real world measurements, to this end I don't like the printing density
space, it is not sufficently defined out side of Kodak, (this includes
Cinesite not having the info BTW). There is a great missunderstanding
about what printing density is, what I can say is that it is not
Status-M, nor is it Status-A.

Given this we wanted reversable transforms that don't do anything you
don't want. so no gamut remapping/compression/expansion should be
involved, suggesting mostly linear operators that don't loose too much
due to precision.

This is why we were happy to look into the request from Ken, but in
order to save our costs, we really wanted a standardised method for
describing this, that won't result in images comming back with
something that is "our fault" particularily as not everybody
(anybody?) truly understands all the possible issues.

I'd love to have something that worked correctly every time, but I
don't think that is possible whilst at the same time is 'perfectly
correct' I hope Drew, Florian et al, can come up with something that
meets these requirements so that we don't fragment, or that at least
we could agree to allow for both options in the file format.

Kevin - these really are not the opinions of anybody but me...

Person A: "How can you hate a file format?"  
Person B: "Please meet Mr TIFF..."

-- 
| Kevin Wheatley                   | These are the opinions of |
| Senior Do-er of Technical Things | nobody and are not shared |
| Cinesite (Europe) Ltd            | by my employers           |