Wishlist/File Formats
From VFXPedia
Requests for support of any type of file - image, 3D, LUT etc.
Contents |
File Formats
Raster Image file formats
- OpenEXR support with all channels (or Fusion support for more channels). Currently there are not enough channels to assign or redirect multilayer/multi-pass OpenEXR channels in a meaningful way. Contemporary OpenEXR image can hold several RGB channel sets (AO, color, diffuse, specular, shadow etc) for convenient usage. In this thread OpenEXR devs discuss multilayer images (Blender supports this variant and others will too). In addition it might be useful to have file/import option for multi-pass/multi-layer OpenEXR to automatically construct basic flow.
- -- I'd like to see this brought a little bit futher- let's have the tools in Fusion capable of 'seeing' and utilizing all the channels from a loader going into it [like EXR channels] so a CC tool [as an example] might only be affecting the diffuse channel, the next tool in the flow might be a BC tool only affecting the reflection channel, etc. This would eliminate the need to add multiple loaders each with the same EXR file loaded but each loading a specific, seperate channel. Presently, many tools permit us to work in just a selected channel [like R,G,B, Luma, Alpha, etc.] but to expand that into whatever channels are all avaiable would be great. --andromeda_girl
- -- The problem with that is that it would pretty much break everything, including 3rd party tools. And it would change how memory and caching is handled, since you're now passing many times more data between tools. I agree that it would be useful at times, but I don't know if it's worth the cost. Perhaps there could be a compromise of sorts, like having say "Instance Groups" or "Related Underlays" or whatever where you tell two or more parallel flows (be they left/right or multipass or whatever) that always get the same tools and operations applied to them. So they get the same transforms, or warping or cropping or whatever. Maybe the tools themselves could read in metadata from input, so they know "Hey, the input RGBA data is labeled as 'Multipass=Diffuse' and I'm supposed to only operate on reflections, so I'll just pass this data through." or "Hey, the input RGBA data is labeled as 'Sterescopic=Left', and I have a partner tool that is getting an input of 'Sterescopic=Right'. Cool... Now we can sample each other's data to make better noise reduction." Such a setup wouldn't break any tools existing in Fusion now, and would get you most of the same benefits as a multichannel system. It would be trivial to have the EXR loader add the metadata tags (it already does that, actually, so maybe it just needs to have a manual override?). And eventually I suppose this wish will have to be moved out of this section. --Chad
- -- Perhaps there's a solution that's somewhere between what andromeda_girl and Chad are saying. Honestly, just a loader that recognizes all the channels that are in the file without limiting me to a particular few. From that single loader, I could branch off and send the individual channels wherever they belong in the flow, without having to load the same image sequence 10 times. Load the frame once, distribute the channels as needed, unload the frame and move on. That MUST be less memory intensive than loaded multiple versions of the same image sequence, just to pick out 3 or 4 channels out of 60+ each time, right?
- -- So you're suggesting that loading say, 9 channels from the file once, would be less memory intensive than loading 3 channels from the file thrice? In terms of memory usage, it'd be similar I would think. I/O usage would be different, and that would depend a lot on how the channels are stored/interleaved throughout the (EXR) file, and how much per-file vs. per-channel I/O there is. In any case, your suggestion doesn't solve anything. Fusion's OpenEXR support can easily identify all channels in the file, and does already to provide them all in the drop-down lists used to choose what channel from the file gets put in what channel in the Fusion image. A tool with a single output can only produce a single image (at each frame time), and that will be supplied to any and all tools connected to that output. So Loader can't load some channels for one connected tool, and other channels for some other connected tool, and given a Loader-centric method like that, trying to manage which channels go to which tool from a UI point of view would be a nightmare. Another alternative would be to load every channel at once. That would be a waste of memory if for example every connected tool only ever needed to process the first 4 channels, but all 20 in the file had been loaded. Even then, there is no method (internally) within Fusion to have an image with more channels than can already be specified in Loader's OpenEXR options, and changing that would break plugin compatibility. Stuart 19:11, 7 September 2010 (EDT)
- -- The I/O problem could be exacerbated if they channels are not needed concurrently. So with the as-is setup, if I'm working on filtering the specular pass over the length shot, I might have all of my cache dedicated to the part of the flow processing the specular pass, hundreds of frames even. Fusion will safely recycle the cache from the other passes without me knowing/caring. But with the proposed change, we'd be stuck either keeping the other passes in cache (at least in the LD) or having to do the I/O for ALL of the passes whenever we requested a new frame of the specular pass. We'd either lose realtime performance or require massive amounts of cache. --Chad 12:37, 8 September 2010 (EDT)
- -- So you're suggesting that loading say, 9 channels from the file once, would be less memory intensive than loading 3 channels from the file thrice? In terms of memory usage, it'd be similar I would think. I/O usage would be different, and that would depend a lot on how the channels are stored/interleaved throughout the (EXR) file, and how much per-file vs. per-channel I/O there is. In any case, your suggestion doesn't solve anything. Fusion's OpenEXR support can easily identify all channels in the file, and does already to provide them all in the drop-down lists used to choose what channel from the file gets put in what channel in the Fusion image. A tool with a single output can only produce a single image (at each frame time), and that will be supplied to any and all tools connected to that output. So Loader can't load some channels for one connected tool, and other channels for some other connected tool, and given a Loader-centric method like that, trying to manage which channels go to which tool from a UI point of view would be a nightmare. Another alternative would be to load every channel at once. That would be a waste of memory if for example every connected tool only ever needed to process the first 4 channels, but all 20 in the file had been loaded. Even then, there is no method (internally) within Fusion to have an image with more channels than can already be specified in Loader's OpenEXR options, and changing that would break plugin compatibility. Stuart 19:11, 7 September 2010 (EDT)
- -- Perhaps there's a solution that's somewhere between what andromeda_girl and Chad are saying. Honestly, just a loader that recognizes all the channels that are in the file without limiting me to a particular few. From that single loader, I could branch off and send the individual channels wherever they belong in the flow, without having to load the same image sequence 10 times. Load the frame once, distribute the channels as needed, unload the frame and move on. That MUST be less memory intensive than loaded multiple versions of the same image sequence, just to pick out 3 or 4 channels out of 60+ each time, right?
- -- The problem with that is that it would pretty much break everything, including 3rd party tools. And it would change how memory and caching is handled, since you're now passing many times more data between tools. I agree that it would be useful at times, but I don't know if it's worth the cost. Perhaps there could be a compromise of sorts, like having say "Instance Groups" or "Related Underlays" or whatever where you tell two or more parallel flows (be they left/right or multipass or whatever) that always get the same tools and operations applied to them. So they get the same transforms, or warping or cropping or whatever. Maybe the tools themselves could read in metadata from input, so they know "Hey, the input RGBA data is labeled as 'Multipass=Diffuse' and I'm supposed to only operate on reflections, so I'll just pass this data through." or "Hey, the input RGBA data is labeled as 'Sterescopic=Left', and I have a partner tool that is getting an input of 'Sterescopic=Right'. Cool... Now we can sample each other's data to make better noise reduction." Such a setup wouldn't break any tools existing in Fusion now, and would get you most of the same benefits as a multichannel system. It would be trivial to have the EXR loader add the metadata tags (it already does that, actually, so maybe it just needs to have a manual override?). And eventually I suppose this wish will have to be moved out of this section. --Chad
- you can import psd files in current compstion not on new comp and make it in floder you can reload and change in photoshop and the imorting file changes and all other files such omfand edl do that.
- Greyscale TIFF, in 8 and 16 bit. Initially could convert to L before saving, but it would be nice to also allow saving of individual channels (like alpha) with a dropdown or checkbox. Also, a greyscale option for PNG would also be nice. --Chad
- adobe flash swf files. Please include Flash SWF Support. This is the only reason we stay with After Effects to composite the shows we work on.
- For static files you can use this workaround http://superuser.com/questions/195668/a-command-line-tool-to-convert-swf-to-svg --bfloch
- 1.066(6)x1 pixel aspect for PAL by default. Of course, it's possible to create a custom frame format, but... --Gringo
- --Ata 16:54, 12 September 2007 (Central Daylight Time) - What is your problem with the recent PAL(D1) aspect? It uses 1:0.9375 which is reciprocal (1/x) of 1.0667 (4/3/1.25 to be exact). So it works great and we use it every day.
- --The problem is in proportions between square pixel images and PAL D1 images. Switching to PAL D1 should increase frame width and not decrease frame height. For example, if you use 720:576 PAL D1 and 768:576 PAL square pixel frames in a composition, they should have the same size. Not a great problem, but still... --Gringo
- Support for DEEP PIXEL avi/mov files, CineForm in windows with .LOOKS applied.
- --Fusion 6.2 loads movs with high bitdepths. Does this solve this wish? --Tilt 17:03, 3 March 2012 (EST)
- CinemaDNG support. New low-cost cameras are offering this now, like the Blackmagic Cinema Camera and the Ikonoskop A-Cam. --Chad 18:39, 17 July 2012 (EDT)
- When only one of the RGBA channels is selected in an EXR loader, make the image output mono. --Chad 13:20, 10 October 2012 (EDT)
- For EXR files, search the metadata on load for an entry, perhaps "ScriptOnLoad" or "ScriptFileOnLoad" and have the Loader execute the script string or file. This would let us, for example, modify metadata based on the usage of the file in Fusion or affect an asset managment system. --Chad 10:35, 19 April 2014 (EDT)
Other Data Import-Export
- MXF format support. Avid, as well as some other editors are using this format extensively. --Chad
- A possibility to import multiple animated Locators at once as the Locator3Ds. If you bind something to locators coming from 3D in Fusion and then animation in the 3D scene changes it can be a nightmare to re-import all the points one by one, especially meaning that you need to remember which locator from the 3D scene corresponds to what in Fusion. --Gringo 10:21, 11 August 2011 (EDT)
- might be related so a wish I've recorded elsewhere: make each 3D tool remember which file it has imported its data from. Not only to allow the file requester to pop up in the right directory but also to be able to read this value with scripts. Your wish could be scripted as well, if there was a way to trigger the "import" button with a comp script. --Tilt 15:13, 11 August 2011 (EDT)
- An update for the LWS import. It requires LightWave 6.0 scenes. The format has changed a little - five years ago - to LightWave 9.2. This is still a plain ASCII file so shouldn't be too hard to implement. It would be a great timesaver to be able to use LWS files directly again.
Plugin Support
Workarounds
- Adobe Photoshop PSD path/vector import
- --Fusion 6.2 imports SVG files.
Completed Requests
- COLLADA, a standard file format for cross-application 3d content. It's widely supported and would make integration to more 3d packages either possible or easier.
- --Izyk 09:28, 14 September 2007 (Central Daylight Time) Available in Fusion 5.2 and later.
- Not all collada files are working though. --Tilt 17:03, 3 March 2012 (EST)
- OpenFX for Plugins
- --Izyk 09:28, 14 September 2007 (Central Daylight Time) Available in Fusion 5.2 and later.
- 8/16/32 bpp mono support for .raw files. Right now only 24/48/64 bpp color is supported, making disk caching of modified masks impossible. --Chad 14:22, 16 April 2010 (EDT)
- I assume you mean that right now only 32/64/128 bpp is supported. --Stuart 17:18, 16 April 2010 (EDT)
- Oh right, yes. --Chad
- You can import drawing shape from Ai or Esp. files or 3d programs as motion splines. Available in Fusion 6.2 and later as the SVG Import.
- Adobe Illustrator/EPS/SVG vector file import - useful for easy logo importing and transformation.
- --I would like SVG, as it's a cross-application standard.
- --Bfloch is developing a script for SVG importing: discussion at Pigsfly --Gringo Available in Fusion 6.2 and later as the SVG Import.
- JPEG2000. No really, I'm not joking. --Chad
- --Daniel Apparently, there's this option.
- --Sweet! That's even more than I wanted. Can someone from Eyeon scoot over there to see what the details are at NAB? --Chad
- --Available in Fusion 6.31
- Alembic, as requested on the mailing list recently. -- 3 March 2012 (EST)
- -- available in Fusion 7 (alembic import only though).
Requests Which Aren't Going to Be Fulfilled
Please, explain the following requests' necessity further:
- File Saver with an Option to save files to previous version formats too. For instance...should save a F5.2 file (obviously if eligible) to open in F5.1 too. --Popo 83 04:38, 11 September 2007 (Central Daylight Time)Popo
- -- Fusion can already load comps from later versions and tries hard to keep compatibility as much as possible. Newer inputs and tools will never work in older versions so I don't think this wish makes much sense. --Tilt 03:20, 3 July 2014 (EDT)
