Rob Mackintosh
Forum Replies Created
-
I think you may be right Craig.
All that Send To Motion requires is that FCP X generate a Motion project file referencing media in the Event/Project database. Alternatively you could export FCPXML to Motion which would convert that into a Motion project. Once you’ve done your work in Motion you would then send back to FCPX, much like you do with generators now, except the generator file would be “published” to the Event and Project (like a compound clip) rather than the Generators Browser.
What would be really useful is having an Event Library and Browser in Motion.
-
Thanks for testing this out Walter. It’s good to know FCP X is preserving the bit depth. I must have had create optimized media selected when I imported the 16 bit tiff. I’m going to do some further testing of FCP X’s handling of still images when I get back home next week. If I discover anything interesting I’ll post it here.
-
Thanks Walter for the comprehensive testing. I have gained a lot of technical knowledge from your posts over the last year.
As Oliver noted in an earlier post, FCPX optimizes all stills to ProRes 422. Do you think this may be influencing the results of your tests. I wouldn’t have thought FCPX was using these files an intermediate codec for rendering deep formats, but who knows. Starting with a 16 bit RGB file, transcoding it to a 10 bit YCbCr intermediate, processing it in 32 Bit float linear RGB then exporting as 16 bit RGB would seem less than optimal.
I noticed when rendering the BMCC dngs on a ProRes444 timeline that ProRes 422 optimized media was simultaneously created in the event folder. I think the same occurred on export except when using compressor. I’m away from my computer so can’t test this with tiffs.
-
I must have missed that thread Oliver.
Be interested to see if it works with 16bit tiffs. I exported a BMC dng (with adjustments) as a16 bit tiff from Aperture, imported into FCPX and compared it with the Aperture preview file (8 bit jpeg, quality 12, no chroma subsampling) that’s brought in when you drag from the media browser. FCPX optimised both to ProRes 422 files of about the same size. Images looked identical on my monitor, slight difference in waveform/histogram, you could push the exposure up and down on both images without much degradation. I noticed a difference when making a secondary color correction using the color board’s HSL keyer. It felt a little more precise pulling a key from the 16bit tiff.
So at the very least I think FCPX is processing 10bit plus media at 10bits.
-
That’s a useful workflow Oliver.
I found that when importing the raw dng files that FCPX created optimized media whether you selected this option on import or not.
ProRes 422 files at the original frame size were created during playback and skimming in the event or project. Perhaps it is doing the same with the ref QT and this explains the good playback performance you are getting.See here for more info https://forums.creativecow.net/readpost/335/40719
In fact I noticed this behaviour with a variety of stills: https://fcp.co/forum/4-final-cut-pro-x-fcpx/12820-color-correction-on-camera-raw-stills#13474
Sorry I am a few thousand miles from my computer so can’t test this out myself.
-
I’ve used Lightroom since version 1 but the integration with FCP X might see me spending more time in Aperture. To be clear, it’s Aperture that’s generating the 444 file as an 8 bit jpeg. When you bring it into FCP X there optimised to ProRes 422. You could always export 8 or 16 bit tiffs and import into FCPX.
-
Yes I noticed that and corrected it. Thanks. Young kids = not enough sleep.
Another workflow option is to use Aperture to perform an initial grade and pull the frames in via the media browser.
This imports the Aperture preview file, which if you have it set to the maximum quality of 12 results in a 3.5MB jpeg for each DNG. These are only 8 bit but there’s no chroma subsampling at jpeg quality of 12 (not sure about Aperture but kicks in round 7 in Photoshop) so they’re 444. They look pretty good.
Interestingly I noticed FCPX was creating the same ProRes 422 render files with these as well. Brought in a few tif and canon raw files and the same thing occurred.
It appears FCPX conforms all image files to ProRes 422 rec709 at their original raster. The file is created as soon as you click on the still in the event or on import if create optimised media is selected.
-
Thanks Rick.
I can’t run Resolve on this iMac hence the experimentation with FCP X. I bought it before falling back into the video world so it’s only the Core2 Duo model with the 256Mb graphics card. Still with 16GB ram it does surprisingly well with FCPX Motion and the Adobe CS6 suite.
I took a look at what FCPX is doing in the background with these DNGs. lt’s creating 2400 x 1350 ProRes 422 frames (about 1MB) on the fly as you play (when playback quality set to high) and skim the image sequence in the event and project. These are stored within the default Event/Render Files/High Quality Media. ProRes 422 is used even if you set the compound clip and project to ProRes 444. Seems to be some intelligent caching so if you’ve clicked on a bunch of individual frames within the event then when dropped into the timeline the playback will be smoother. I was getting realtime playback in the project timeline because I’d viewed most of the clips already in the event. When importing check the “create optimized media” checkbox to have these files created from the get go
[If you select a compound clip or an individual frame right click – transcode media – create proxy media ( optimised is greyed out) – then 500KB 2048 x 1152 jpegs are created within the proxy media folder along with a 2400 x 1350 ProRes frame in the High Quality Media folder.]
If you export without rendering the timeline any frames that haven’t been played/skimmed are created before export and exporting times will increase significantly. Even if you choose to export an image sequence as DPX or as ProRes 444 file (using export media) the frames are still created as ProRes 422.
If you render a ProRes 444 timeline then 1920×1080 ProRes 444 render files are created inside the project folder as well as 2400 x 1350 Pro Res 422 frames within the event. I think FCPX is using the Event ProRes 422 as an intermediate file to render the ProRes 444. If you then delete the event files the ProRes 444 are used on export. No ProRes 422 frames are created if you use Compressor to export ProRes 444 but they are when using compressor settings.
So my takeaway from this little bit of unscientific testing:
– if you want to follow the workflow in my original post stick with ProRes 422 compound clips and projects as FCPX appears to be processing internally with this codec (much like Smoke 2012 and earlier did with DPX). . You’re not going to want to grade and edit a feature like this, but I think it’s a viable option for smaller jobs.
– if you need ProRes 444 then transcode the Cinema DNGs prior to importing into FCPX. (You could try deleting all event render files, leaving rendering till export and using compressor).
Sorry this probably belongs in the techniques forum.
-
I’ve had this issue with a variety of footage on Mountain Lion. It is intermittent and a reboot fixed things.
I’ve also had the system graphics go completely screwy (patchwork quilt of various apps) when I open an effect in Motion via FCPX. Again a reboot fixed things. I won’t speculate on whether the graphics drivers need updating or AV foundation/Quicktime based apps but I’d hold off updating to Mountain Lion for anything mission critical. I’m running a late 2009 iMac with an ATI card. -
These two blog posts by Todd Kopriva give you the run down on what CUDA and Open CL can handle in Premiere Pro CS6:
https://blogs.adobe.com/premiereprotraining/2012/05/opencl-and-premiere-pro-cs6.html
To summarise: CUDA accelerates ( and in some cases produces higher quality renders): scaling, deinterlacing, blending modes, color space conversions and some effects, namely:
Alpha Adjust, Basic 3D, Black & White, Brightness & Contrast,Color Balance (RGB),Color Pass, Color Replace, Crop, Drop Shadow,Extract, Fast Color Corrector, Feather Edges, Gamma Correction, Garbage Matte (4, 8, 16), Gaussian Blur, Horizontal Flip, Levels, Luma Corrector, Luma Curve, Noise, Proc Amp, RGB Curves, RGB Color Corrector, Sharpen, Three-way Color Corrector, Timecode, Tint, Track Matte, Ultra Keyer, Video Limiter, Vertical Flip, Cross Dissolve, Dip to Black, Dip to White, Push transition
Open CL accelerates all of the above apart from: Fast Blur effect, Gaussian Blur effect, Directional Blur effect, Basic 3D effect.
This fxguideTV episode is also worth a watch: https://www.fxguide.com/fxguidetv/fxguidetv-145-ae-and-adobe-cs6/
Be interesting to see whether the degree of acceleration provided by Open CL cards matches similarly specced CUDA cards.