Topics

multi-frame EXR?


Paul Miller
 

Is the idea of extending EXR to support multiple frames too crazy an idea?


Larry Gritz
 

It's not crazy, but exactly what is the design goal? I mean, what is it that you hope to accomplish beyond what is already supported by multi-part exr?


On Thu, Jul 11, 2019 at 9:55 AM Paul Miller <paul@...> wrote:
Is the idea of extending EXR to support multiple frames too crazy an idea?







--
Larry Gritz
lg@...


Paul Miller
 

On 7/11/19 11:56 AM, Larry Gritz wrote:

It's not crazy, but exactly what is the design goal? I mean, what is it that you hope to accomplish beyond what is already supported by multi-part exr?

Mostly as a way to streamline schlepping around sequences of EXR frames, admittedly as a potentially ludicrously-large file.

I envision it not directly built on multi-part exactly, as all of the frames in a sequence would share the same header.


On Thu, Jul 11, 2019 at 9:55 AM Paul Miller <paul@...> wrote:
Is the idea of extending EXR to support multiple frames too crazy an idea?







--
Larry Gritz
lg@...


Michael Wolf
 

Hallo Paul,

On Thursday, July 11, 2019, 6:59:23 PM, you wrote:

Mostly as a way to streamline schlepping around sequences of EXR frames,
admittedly as a potentially ludicrously-large file.
I envision it not directly built on multi-part exactly, as all of the
frames in a sequence would share the same header.
But then you couldn't decompress a single image without decompressing everything.

Cheers,
Mike

--
db&w Bornemann und Wolf GbR
Seyfferstr. 34
70197 Stuttgart
Deutschland

@LightWolf

http://www.db-w.com

tel: +49 (711) 664 525-3
fax: +49 (711) 664 525-1
mob: +49 (173) 66 37 652

skype: lupus_lux
Support us on Patreon: https://www.patreon.com/dbw


Paul Miller
 

On 7/11/19 12:01 PM, Michael Wolf wrote:

Hallo Paul,

On Thursday, July 11, 2019, 6:59:23 PM, you wrote:

Mostly as a way to streamline schlepping around sequences of EXR frames,
admittedly as a potentially ludicrously-large file.
I envision it not directly built on multi-part exactly, as all of the
frames in a sequence would share the same header.
But then you couldn't decompress a single image without decompressing everything.
I was thinking there would be an index of frame offsets for each part, so fetching a frame would be a simple seek. I haven't looked too much into the internals of EXR yet to see how feasible this is, but I'd want it to be as efficient as possible. Just trying to gauge general interest before diving in more.

Cheers,
Mike


Hồ Châu
 

In Taiwan at Qing Hua University (清华大学), year 2017, I create very short plan for develop HDR video/movie format use OpenEXR file for frames, WAV audio, and OGG container. I think need HDR video/movie format for high quality production but not want lose files like Paul's idea. In this plan, HDR video/movie format is separate project, not part of OpenEXR.

For quality/speed/keep it simple, this format:
• only use NO, RLE, ZIPS, ZIP compression
• scan line or tile file
• only use file have BGR, BGRA, Y, YBYRY channels
• each frame is independent for easy edit

Qing Hua University reject this plan and we never build it.

Châu
Vào 00:04:39 GMT+7, Thứ Sáu, 12 tháng 7, 2019, Paul Miller <paul@...> đã viết:


On 7/11/19 12:01 PM, Michael Wolf wrote:

> Hallo Paul,
>
> On Thursday, July 11, 2019, 6:59:23 PM, you wrote:
>
>> Mostly as a way to streamline schlepping around sequences of EXR frames,
>> admittedly as a potentially ludicrously-large file.
>> I envision it not directly built on multi-part exactly, as all of the
>> frames in a sequence would share the same header.
> But then you couldn't decompress a single image without decompressing everything.
I was thinking there would be an index of frame offsets for each part,
so fetching a frame would be a simple seek. I haven't looked too much
into the internals of EXR yet to see how feasible this is, but I'd want
it to be as efficient as possible. Just trying to gauge general interest
before diving in more.
>
> Cheers,
> Mike
>




Rodney Baker
 

There is the MOT file format that Brendan Bolles worked on for awhile.
The format has working plugins for AfterEffects and Premiere.
Technically the format is currently NOT as the MOT format never quite got out of Alpha... but I can confirm it worked!

Sadly, not much movement in years...

You can read more about the Indiegogo project here:


I suppose the downside of the implementation (as it was/is) is that it is plugin based.

All the best,
- Rodney
 
 


kevin.j.wheatley@...
 

sound like you want OpenEXR wrapped in MXF or a zip/tar file or
something similar. I'd avoid mixing in multiple time frames in the
same OpenEXR file.

Kevin


Peter Hillman
 

Weta developed a simple multiframe OpenEXR container format that stores
multiple independent EXRs in a ".xrm" file. This has a frame index table
so frames can be read in any order, and tools to pack/unpack the frames.
The individual frames can also be read and written directly using the
standard OpenEXR library: the library provides a stream object that can
be passed to Input/Output file constructors to read/write frames. The
idea was to make it simple to add support for XRM files in code that
already reads or writes sequences of separate OpenEXR files.

We used this in production on a recent feature. We found reading
consecutive frames from an ".xrm" file in the DI package was much more
efficient than reading separate OpenEXR files, since the file access
pattern is more predictable.

We will have to take a more careful look at the state of the code before
making any firm promises but we might be able contribute this as open
source code if there is sufficient interest.

Peter

On 12/07/19 8:01 PM, kevin.j.wheatley@... wrote:
sound like you want OpenEXR wrapped in MXF or a zip/tar file or
something similar. I'd avoid mixing in multiple time frames in the
same OpenEXR file.

Kevin


Joseph Goldstone
 

So the .xrm file serves a purpose much like the SMPTE ST 2065-5, the ACES-in-MXF container, except the files that are wrapped are not constrained to an OpenEXR subset in the same way as files compliant with the ACES container spec (SMPTE ST 2065-4:2013)?

On Jul 17, 2019, at 4:42 PM, Peter Hillman <peterh@...> wrote:

Weta developed a simple multiframe OpenEXR container format that stores
multiple independent EXRs in a ".xrm" file. This has a frame index table
so frames can be read in any order, and tools to pack/unpack the frames.
The individual frames can also be read and written directly using the
standard OpenEXR library: the library provides a stream object that can
be passed to Input/Output file constructors to read/write frames. The
idea was to make it simple to add support for XRM files in code that
already reads or writes sequences of separate OpenEXR files.

We used this in production on a recent feature. We found reading
consecutive frames from an ".xrm" file in the DI package was much more
efficient than reading separate OpenEXR files, since the file access
pattern is more predictable.

We will have to take a more careful look at the state of the code before
making any firm promises but we might be able contribute this as open
source code if there is sufficient interest.

Peter

On 12/07/19 8:01 PM, kevin.j.wheatley@... wrote:
sound like you want OpenEXR wrapped in MXF or a zip/tar file or
something similar. I'd avoid mixing in multiple time frames in the
same OpenEXR file.

Kevin


Peter Hillman
 

Hi Joseph,

Yes, I think that's basically correct, though I'd have to track down the
standard and dig into it a little more to see what the other differences
might be.

We needed to carry multipart stereo OpenEXR files using different
compression schemes for each part, potentially with different
dataWindows per frame. That might be out of scope of ACES-in-MXF. There
is deliberately no way of adding metadata to the container itself: the
only metadata is carried by the contained OpenEXR files, so that
expanding the xrm file into a bunch of separate exr files, processing
them, then repacking them into a new file, won't lose any data, and
there's no ambiguity between, say, timecode in the container and
timecode in the EXR headers.

Having a generic EXR-in-MXF format which can be specialized to SMPTE ST
2065-5 ACES-in-MXF might be an alternative solution, and would be a
single code path for writing both files. On the other hand, doing that
might open the way for abuse and dilution of the standard, with MXF
files being created which are "SMPTE ST 2065-5 except in AlexaWideGamut"
Having MXF files for ACES-compliant OpenEXRs, and a different container
format for everything else, might be a clearer way to go.

Peter

On 18/07/19 8:55 AM, Joseph Goldstone via Lists.Aswf.Io wrote:
*Originates outside of Weta Digital



So the .xrm file serves a purpose much like the SMPTE ST 2065-5, the ACES-in-MXF container, except the files that are wrapped are not constrained to an OpenEXR subset in the same way as files compliant with the ACES container spec (SMPTE ST 2065-4:2013)?

On Jul 17, 2019, at 4:42 PM, Peter Hillman <peterh@...> wrote:

Weta developed a simple multiframe OpenEXR container format that stores
multiple independent EXRs in a ".xrm" file. This has a frame index table
so frames can be read in any order, and tools to pack/unpack the frames.
The individual frames can also be read and written directly using the
standard OpenEXR library: the library provides a stream object that can
be passed to Input/Output file constructors to read/write frames. The
idea was to make it simple to add support for XRM files in code that
already reads or writes sequences of separate OpenEXR files.

We used this in production on a recent feature. We found reading
consecutive frames from an ".xrm" file in the DI package was much more
efficient than reading separate OpenEXR files, since the file access
pattern is more predictable.

We will have to take a more careful look at the state of the code before
making any firm promises but we might be able contribute this as open
source code if there is sufficient interest.

Peter

On 12/07/19 8:01 PM, kevin.j.wheatley@... wrote:
sound like you want OpenEXR wrapped in MXF or a zip/tar file or
something similar. I'd avoid mixing in multiple time frames in the
same OpenEXR file.

Kevin


Olaf Matthes
 

I found this discussion while looking for "movie file" alternatives to EXR image
sequences without having to trade in all the nice things about EXR.

Among other things, I'm author of a software that converts DSLR RAW files to
EXR for stop motion and time-lapse use. Every now and then some users will
ask about a movie file format that can hold compressed half-float image data
and per-frame metadata. Just looking around I found that SGO Mistika lists
.xrm as supported input format, but at that time I couldn't find any more
information about it. Now, thanks to Peters post, it looks even more intersting.

During my work as freelance software-developer for Assimilate I've come across
many movie files (mp4, mov, and even mxf) where the information in the container
didn't really match what was actually stored in there. There are containers
specifying a different image size or you can find a container indicating two
channels of audio and once you decode, it turns out to be 5.1 audio....
So having a file format that simply wraps existing EXR images into a "bundle"
without adding any extra information (apart from a frame table that would store
the offsets into the file for each individual frame) sounds very temping. And
as Peter mentioned, you can even un-wrap such a file without loosing any
information.

Given the fact that .xrm is already "half" out there in the wild (by Mistika reading
it), I'd very much appreciate if the file format details could be published.

Olaf