FORUMS: list search recent posts

Why Smoke may never export FCP7 XML, and what to do about it.

COW Forums : Autodesk Smoke

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Juan Salvo
Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 3:29:38 am

One of my highest hopes for the new 'we've changed everything' Smoke was having XML export as an option along with the excellent XML import capability. Unfortunately it seems this will not be happening. Which got me to thinking about why that must be.

One of Smokes great strengths as a finishing tool is that it's based on a Framestore architecture for its media, even though it now allows and references native media, anytime it processes something it does so to an image sequence. Whether that be a series of dpx or a series of single frame prores qts, as is now supported.

I was amazed to see this with my own eyes at NAB, but sure enough within its folder structure Smoke creates a series of 1 frame MOVs when using prores as an intermediary codec.

This is actually one of the strengths of Smoke, so when you change a few frames of a clip, it just replace literally those frames. It doesn't have to keep a render scratch with a bunch of discarded frames in a container file. It's very efficient.

But this is also why fcp7 XML out could hardly work. While smoke is built around handling image sequences, FCP is not... And FCP7 XML is particularly not. If you managed to get an image sequence imported natively in fcp, something which is a feat onto itself, and you exported out an XML, you see that every single frame is a unique media event. It doesn't recognize the sequential relationship of the media. It just sees a bunch of stills.

This would be nearly useless for going to DaVinci Resolve for example. Each frame would be treated as a clip, it would be a nightmare to grade. But Resolve itself is all too happy to work with image sequences. As is After Effects or Nuke, or many other apps I'm anxious to be able to get in and out of with smoke projects.

One thing I've learned watching the Resolve software develop is how anxious and eager they are to support any NLE that wil let them. So the answer here could be simple... rather than try to twists Smoke media handeling to suit an FCP7 XML export (as Adobe has done with Premiere & 3rd party tools allow with Avid) why not just create a Smoke XML schema? I'd call it SMAXML! Build it however you'd need, so that it could reference Framestore media as well native container files. Put additional metadata in about how the media is handled. Maybe some information about how effects and transforms are applied. But mostly, give us the ability to create something resembling our sequence in other apps, and then give us a way to refresh our sequence on the way back.

Autodesk doesn't have to find a way to export fcp7 XML, they can roll their own. Just make it open and watch all the 3rd parties come out of the woodwork to support you. It would open up many other potential uses, software like predit, plural eyes, Boris soundbite would have a much easier time getting media and metadata into and out of smoke.

Just a thought.

Online Editor | Colorist | Post Super | VFX Artist | BD Author

http://JuanSalvo.com


Return to posts index

Matt Penn
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 3:40:59 am

I would think it could be pretty easy for Autodesk to have Smoke create a quicktime reference movie that refers to all the other files for a lean xml out, which solves a bunch of issues.

Matthew Penn
Post Production Supervisor
New York City


Return to posts index

Juan Salvo
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 3:45:20 am

Some apps (Resolve, I'm biased) don't support reference qts. But a clever idea.

Online Editor | Colorist | Post Super | VFX Artist | BD Author

http://JuanSalvo.com


Return to posts index


David Jahns
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 4:35:37 am

Interesting idea. I was just thinking about something similar regarding Smoke & XML...

In the traditional offline/online workflow, you are generally just making the decisions for what pieces of media you want to use in finishing, right? So your FCP XML to Smoke for finishing references the same pieces of media that FCP did, with in & out points and basic size, position, etc...

If you limited yourself to vertical (timeline/layer) compositing in Smoke, you probably could do a similar thing - just exporting pointers to the same source media. Smoke 2012 can export EDLs, after all - why not XMLs with a bit more information? But who wants to use Smoke that way?

The issue arrives when you use Smoke to it's full potential in Action (and soon Connect FX), because you are actually creating new pieces of DPX media that often do not have raw sources, or they are combining many different sources into a new composite. I don't think there's any way in hell you'll ever take an Action Composite, and get that out in an XML that can be read by a non-Autodesk app.

But why would you want to do that anyway? To send to Nuke? I doubt that would be very common... but I could see wanting to send it out to Resolve for grading.

But it's POSSIBLE that with "nested" Connect FX, it could retain source time codes for each of the elements within an FX Comp, and it's possible it could export a basic XML that simply stacked them vertically - so you might be able to get the media into Resolve for grading as separate elements, but it would certainly not look like it did in Action. The question would be - could you then re-link your sequence, and all of the "nested" composites to the new graded material? Again, possible - probably not easy.

Another potential way to deal with it would be to export an XML that references source media if it is in a traditional layer based timeline, and anything that uses a complicated Connect FX could be rendered out as a new piece of media in DPX or ProRes (a la Premiere-SpeedGrade), and referenced by the XML. Then in Resolve, you could grade the source media for normal shots, and the Smoke comp for the FX shots. Obviously, those would be entirely flattened, and maybe not the best way to grade them - but for many shots, it would be fine.

Personally - I would rather they put their energy into improving the Color Warper to make Resolve unnecessary. There are very simple fixes they could do quite easily before the fall launch that would help tremendously, and then maybe for 2014, add in some Lustre features that would truly make round tripping unnecessary.

June 4th, baby!!!! Bring it!!!!

David Jahns
---
Joint Editorial
Portland, OR


Return to posts index

Yevgeniy K'banchik
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 4:39:46 am

I think it's it's very unlikely, as it's not in their philosophy to let cut out of the Smoke-flame-lustre environment


Return to posts index

Juan Salvo
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 5:09:18 am

Sadly it's hard to argue that point. Though this is what I'd hoped they meant when they said "Smoke is changing. everything." if they want to play in the nle game, they can't be a walled garden. The needs of the broad market they seem to be aiming for are much too diverse and sometimes complex for one app to handle it all as best as a possible. This is why avid, adobe & even apple all allow project interchange.

Online Editor | Colorist | Post Super | VFX Artist | BD Author

http://JuanSalvo.com


Return to posts index


Brian Mulligan
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 5:57:16 am

To be fair.... Just getting the software redesigned to this point, and the changes made has been quite a feat for Autodesk. It is amazing how much detail and thought goes into some of th most simplest things. I have had quite a few emails wie the design team over things like "snapping". If that much effort is paid to snapping and changes tweaked over several Alpha versions then I am sure that XML interchange is no small task.... Especially on a box and system that has buy past design been an end result finishing solution.

The pre release public beta will be out June 4th, 2012. I am sure that Autodesk will be overwhelmed with feedback.
Even if XML doesn't make the fall release... There will be others release after that. The great thing is that Autodesk is listening and are making huge changes to Smoke. Those changes will be ongoing. There are a lot of exciting things about Smoke as and editor and compositor and effects toolbox that are wonderful for the right user. There is no denying Smoke's quality and mature toolset. The timeline centric effects abilities and node based workflow with ConnectFX is awesome....so much is possible....beyond editorial.

Here is a quick thing i did as an FXPHD.com tutorial, in a current class I taught.. It was all done with jpg stills using ConnextFX.






So this was a bit of 3d compositing, 3d text as a motion graphic element design as part of the overall edit I did with video as part of a :30 sec promo spot

Brian Mulligan
Senior Editor - Autodesk Smoke
WTHR-TV Indianapolis,IN, USA
Twitter: @bkmeditor


Return to posts index

walter biscardi
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 24, 2012 at 12:09:09 pm

[Yevgeniy K'banchik] "I think it's it's very unlikely, as it's not in their philosophy to let cut out of the Smoke-flame-lustre environment"

I think it was also very unlikely that they would have dropped the price by 2/3 and made a very powerful system for the iMac a few years ago.

Never say never, XML out or some other path from Smoke to Resolve is one of my major requests for the Autodesk team. Not sure if something like that would be possible by the time the software releases in the fall, but I would not say it's "unlikely" to ever happen.

Walter Biscardi, Jr.
Editor, Colorist, Director, Writer, Consultant, Author, Chef.
HD Post and Production
Biscardi Creative Media

"This American Land" - our new PBS Series.

Blog Twitter Facebook


Return to posts index

Shawn Larkin
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 26, 2012 at 10:45:04 pm

I would prefer they do this:

1) Add in the extra functionality of Flame -- 3D Tracker, multiple secondaries, etc.

2) Add in a Lustre Module

Then you won't need XML.

Wouldn't you rather Autodesk do this in, say, the 2014 release than make a compromised XML out?

If they could literally make each part of Smoke be as good as it could be, then this is better than leaving the application. This means the editing and trim tools are rock solid and the the codec support going in and out is comprehensive.

This might happen at some point once there is no more market demand for their high end all-in-ones that solely work with DPX.


Return to posts index


walter biscardi
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 27, 2012 at 1:59:37 pm

[Shawn Larkin] "Wouldn't you rather Autodesk do this in, say, the 2014 release than make a compromised XML out?"

Not really.

Walter Biscardi, Jr.
Editor, Colorist, Director, Writer, Consultant, Author, Chef.
HD Post and Production
Biscardi Creative Media

"This American Land" - our new PBS Series.

Blog Twitter Facebook


Return to posts index

Kevin Johnson
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 28, 2012 at 12:31:20 pm

I don't think the Flame Premium guys would be too happy that the tools in their $100K+ turnkey systems were being given away to the masses for $3K.

Kevin Johnson

Autodesk Smoke Artist
FCP Editor
Washington, DC


Return to posts index

Shawn Larkin
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 28, 2012 at 2:35:29 pm

I don't think that Company 3 or any other house using Resolve was too happy when it dropped 100K in price a few years back either. Right now, you can get arguably the world's greatest color application for free and it has a way better tracker than Smoke built in.

The hiccup for everyone on this new Smoke system is going to be doing great color and using great tracking -- the way you would in Resolve.

The other hiccup is having all your source material become DPX image sequences which necessitates a lot of fast storage (hence the promo picture of a Thunderbolt RAID next to the iMac). BTW: you can't get 160+ MB/s from GbE for shared storage to handle using this system over GbE network the way most shops like Walter's are using nowadays. DPX image sequences are bandwidth intensive. So that means fast local storage -- not GbE for working on a project in Smoke.

Smoke 2013 is a move by Autodesk to stay relevant. It looks like a great start. It's a dreamy idea to stay in the timeline and switch between modules. I am looking forward to testing it. But it's a matter of time before Autodesk will have to give up even more.

I do hope they will let users get XML out so you can go to Resolve. But it will be less powerful than having all your layers separated so you don't have to track and create as many secondaries. And who wants to deal with the media management of going to another application? I think the promise of Smoke is not having to do this.


Return to posts index


Brian Mulligan
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 28, 2012 at 2:45:16 pm

In Smoke 2013 your framestore does not have to be DPX as it once was. You can import and create project media as Prores and render as the same prores. So you can work with lesser hardware requirements.

Brian Mulligan
Senior Editor - Autodesk Smoke
WTHR-TV Indianapolis,IN, USA
Twitter: @bkmeditor


Return to posts index

Shawn Larkin
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 28, 2012 at 4:47:12 pm

Thanks for the reply Brian. I have read a few contradictory things about how Smoke 2013 handles media. I'll know know for sure in a week :)

If I can import any media file -- say H.264 up to DPX -- and it creates ProRes as in intermediary codec / container which I can work off of AND THEN I can export any format out and dump the ProRes intermediary files once the project is finished (if I want to) while retaining the original source media for archive -- THEN that is ideal. And Smoke becomes a true NLE replacement + VFX solution.

For color work and advanced tacking, I'm pretty sure Autodesk will have to decide where they want customers to do this work -- in application using Lustre and Flame tools -- or outside using Resolve and other manufacturer tools. It's just a matter of time.


Return to posts index

Brian Mulligan
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 28, 2012 at 5:10:13 pm

[Shawn Larkin] "If I can import any media file -- say H.264 up to DPX -- and it creates ProRes as in intermediary codec / container which I can work off of AND THEN I can export any format out and dump the ProRes intermediary files once the project is finished (if I want to) while retaining the original source media for archive -- THEN that is ideal. And Smoke becomes a true NLE replacement + VFX solution."

YES. You can use Prores from proxy to 4444 as an intermediate. You can also link natively to your files, edit... renders would be prores, and you can then output in many standard files.

You decide how you want to work and Smoke will work with you.

Brian Mulligan
Senior Editor - Autodesk Smoke
WTHR-TV Indianapolis,IN, USA
Twitter: @bkmeditor


Return to posts index


Shawn Larkin
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 29, 2012 at 3:56:32 pm

Thanks again Brian. Can you confirm for sure a few things for the 2013 release:

1) I understand the renders are single frame ProRes QTs (if you choose that for your intermediary codec). However, you can edit off of your native media directly -- even H.264/AAC wrapped in QT? Or does this have to be transcoded going in first? The only NLE I know of that doesn't have to create a cache or transcode for AAC audio is FCPX so I have a feeling this won't work.

2) You can export an H.264/AAC QT or say an XDCAM EX QT -- OR -- You are limited to exporting as a ProRes QT or DPX and then you have to do a transcode afterward?

I realize it is not advisable to edit compressed A/V like AAC or H.264. I'm just curious how locked into a flavour of ProRes you are going in and out.


Return to posts index

Brian Mulligan
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 29, 2012 at 4:23:02 pm

[Shawn Larkin] "1) I understand the renders are single frame ProRes QTs (if you choose that for your intermediary codec). However, you can edit off of your native media directly -- even H.264/AAC wrapped in QT? Or does this have to be transcoded going in first? The only NLE I know of that doesn't have to create a cache or transcode for AAC audio is FCPX so I have a feeling this won't work.

2) You can export an H.264/AAC QT or say an XDCAM EX QT -- OR -- You are limited to exporting as a ProRes QT or DPX and then you have to do a transcode afterward?
"


#1. Yes the prores intermediate renders are 1 frame QT's, and you want it this way for smart rendering. Transcoded clips are a bit more magic. I don't have the details but they aren't .mov files.

You can import natively and edit with .h264 with AAC Stereo Quicktimes.

2. You can export a wide variety of formats.. in both QT and MXF.
h.264 / prores / DNxHD / DVCPROHD / Animation / IMX / uncompressed / YUV v210, 2vuy

AVC-Intra and DNxHD and XDCAM in MXF

You can't export AAC audio - might be a licensing issue.

Brian Mulligan
Senior Editor - Autodesk Smoke
WTHR-TV Indianapolis,IN, USA
Twitter: @bkmeditor


Return to posts index

Shawn Larkin
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 29, 2012 at 5:40:33 pm

In the words of Vader:

Impressive, very impressive.

Thanks again for the reply, Brian.


Return to posts index

Brian Mulligan
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 29, 2012 at 5:46:55 pm

Actually it's "Impressive. MOST impressive." - Vader
If there is one thing I know more than Smoke, it's Star Wars. :)

NERD!






Brian Mulligan
Senior Editor - Autodesk Smoke
WTHR-TV Indianapolis,IN, USA
Twitter: @bkmeditor


Return to posts index

Shawn Larkin
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on May 29, 2012 at 5:53:42 pm

Hah! My bad.

It just occurred to me that IF Smoke 2013 is successful and becomes widely adopted, Autodesk might release a higher-tiered version -- maybe branding it "Flame 2014" -- designed for OSX with those additional high-end tools: a real Lustre module, a real 3d tracker, etc.

Or not.

Either way, I'm jumping on SMAC 2013 next week!


Return to posts index

Jon Howard
Re: Why Smoke may never export FCP7 XML, and what to do about it.
on Nov 9, 2012 at 8:09:15 pm

I love this thread, for the record. Thanks to everyone who's contributing to this discussion.

I'd really love to see some XML format be able to handle image sequences. I'm currently working at a shop using Premiere as a finishing timeline, which I know sounds ridiculous, but it's actually really, really excellent. It's a more full-featured, traditional cutter than Smoke 2013 and can play back 10 bit DPX sequences in realtime without rendering (with the help of a Quadro 4000). I've delivered several national commercial campaigns this year, including a behemoth with 150 versions, with it and have had no problems a simple reboot couldn't fix. Also, using DPX sequences our color is rock solid consistent from the time we ingest our graded clips to laying off to HDCAM-SR.

One of the big reasons why we're using Premiere is that we do our compositing in NukeX, which gives you some things that Smoke 2013 doesn't have and that I use on nearly every job - primarily camera solving and camera projection. Also, I can very quickly bounce a shot from the Premiere timeline into After Effects to send to Mocha Pro for planar tracking and roto, all without creating one new frame of media. As a compositing package, NukeX is fast, stable and sensical in a way that, from my admittedly limited experience using and assisting on it, Smoke is not. For shot-based compositing, NukeX feels right now like the end of the road (for now). It lacks nothing except a timeline. There's even a free XML import python script that turns my Premiere sequences into ready-to-go Nuke scripts, so bouncing a shot from Premiere to Nuke takes less than 5 minutes. I run this script as soon as my conform is done so any shot my clients want to tweak is already Nuke ready.

The major bottleneck in the above pipeline is the conform. We've been using the Immigration script for After Effects to reconnect offline clips from Premiere to graded DPX sequences. Immigration doesn't read the DPX timecode and only tries to match filenames, which is nutty, especially since Adobe has such powerful metadata handling abilities. It almost always comes down to rebuilding - rather than reconnecting - the cut using the DPXs you import via Immigration.

Smoke 2013 and, even moreso Hiero, absolutely flies through conforming. It's lovely. If there were a means of exporting a timeline consisting of DPX sequences from either Hiero or Smoke into Premiere, or, better still, having the ability to conform to DPX directly within Premiere itself, then Nuke would effectively have a timeline from which you could deliver a job. The main thing here is the soft importing. I don't want to wait for new DPX files to be generated, nor chew up the space on the SAN when I've already got everything I need, with handles, from the graded DPXs I just conformed. You could be freely bouncing between Hiero or Smoke, Premiere, After Effects, Nuke, Mocha Pro, etc. without creating one redundant frame of media.

I'd be interested in switching from Premiere to Smoke 2013 just for the time savings in conform. However, being limited to AJA I/O is a killer (we use Blackmagic I/O because we color in Resolve) and I'd need to export clips to comp in Nuke, chewing up time and SAN space and creating a media management headache (albeit probably a lesser headache than my current conform situation).

I understand the idea of using different applications to handle different tasks is a turnoff. However, from this view - and I understand it's just an opinion, not a fact - you generally improve the quality of the tool you're using if that tool is specialized. Resolve is an excellent grading tool, but doesn't pretend to be an NLE or compositor. NukeX is a better compositing package than Smoke. Premiere is a better NLE than Smoke. However Smoke and Hiero are WAY better conforming tools than Premiere. Image sequence-friendly XML would allow you to marry all of these exceptional tools into quite a lovely pipeline. And you could have all of these apps working harmoniously on a system connected to a fast SAN for 25% of the cost of a Flame seat.

All of this is my horribly inefficient way of saying that I REALLY hope either Autodesk or The Foundry develops an XML standard that can handle image sequences. I wouldn't put it past someone in the Nuke user community doing it on their own and posting it as a free script on Nukepedia. Very exciting times these days!

Thanks again for the excellent discussion. Really enjoyed reading everyone's postings. Thanks for starting the conversation, Juan!

Jon


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]