Hello
Have any of you ever exported a jpeg 2000 sequence from flame?
Flame does not export jpeg 2000. One option is to export as an uncompressed format, such as tif, dpx or exr, and convert in media encoder to jpeg2000 in an mxf wrapper, or using a Photoshop action to automate a frame by frame conversion to jpeg 2000.
1 Like
Not the answer you were looking for, but if you are a Mac and need it in a pinch, Automator has a convert formats option that you could use as a workflow/quick action.
2 Likes
ffmpeg could be used as well-
Another commonly used format that sadly Flame does not support.
Just curious, what’s the use case of needing to export jpegs from Flame? I do it for internal use like markup frames, but the exact codec isn’t important for that.
Some places use J2K as a delivery format, often wrapped with a mxf so not DCP or IMF (which are also J2K mostly). There are a couple of streamers I have had to deliver to that have an almost IMF like delivery format in everything bar it being delivered as a single mxf file, generally with Dolby Vision & HDR10 sidecar files.
JPEG2000 lossless, especially wrapped in a mxf container, would also be an excellent codec for integer based file transport so people working in Log instead of linear had something lossless to use. (H265 or Cineform are also lossless choices). Unfortunately there isn’t one for Flame.
Can’t say I love the idea that any internal rendering in Flame might be done to exr regardless of colourspace. I just hope it is saving them as linear under the hood.
1 Like
OpenEXR PIZ is lossless with a good compression ratio.
1 Like
No good for log though.
Sure, colour transform into linear for transport. Throws more than a few Flame Artists.
even @ 32bit? I thought the issue is not the container but the bit depth.
1 Like
Looked into that a few weeks ago, and I think this concern only applies to 16bit. Does make for bigger files though.
It is 16bit float that causes the issue. If the numbers are stored as 32bit then there isn’t an issue for integer in 32 bit.
A 32bit exr will roughly be double the size of a 16bit float so kind of defeats the purpose.
But not with PIZ compression.
A 32 bit float Piz compressed exr won’t save you much space compared with a 12 or 16bit uncompressed integer format such as dpx.
A lossless 16bit integer format such as J2K/H264/Cineform are going to be a shitload smaller than a 32 bit Piz exr too. Probably half the size.
1 Like
The other variable is the container. An image sequence with individual files is the worst case design in terms of overhead. It creates way more I/O operations in the OS, creates file system fragmentation and inefficiencies, screws up every single user interface, including OS file explorers. Usually takes 2x the time to copy. It’s a stupid way of storing video content.
Putting full / independent frames in an MXF container is orders of magnitude better.
The only downside is if you want to add a partial render you can’t just add files to the folder but have to redo the container. But that’s often a corner case.
1 Like
but it works well for burn, or any other flame situation that requires either one-to-many, or many-to-many transactions on bigger networks.
especially over cloud flames and cloud storage. $0.02
1 Like
Internal cache and managed media can make other tradeoffs as required for system design.