Adam Berk
Forum Replies Created
-
This probably would be the best course of action here. It’s just a matter of finding time between bookings in that suite.
-
As I’ve noted, the WTG prores import method very sporadicly works, even with smoke for mac. 99% of the time it does not. This is one of those times.
-
Ok. So theoretically, as long as we export using the same settings as what’s in the sequence, we should be fine. We could then theoretically take an EDL from the edited sequence, preconform in resolve with no grading and render out to DPX in source mode to get the individual shots in a format that’s compatible with our pipeline.
This sounds like a plan that may be worth a try.
-
Sorry if I wasn’t clear in my last post. The reason for conversion is that prores files can’t be reliably imported into the autodesk systems. This is a flame job.
-
Has it been confirmed/tested/proven by anyone that it’s possible to do a cuts only edit of 10bit RGB material and export from FCP without modifying the picture data? Has apple confirmed this in a tech paper somewhere?
If so, does this rule also apply when exporting to a different codec than the source/sequence? In this example, I’d like to cut the PR4444 and export to a discreet readable 10bit RGB format. The prores import features on the discreet systems are highly unreliable and basically don’t work. If they did, we could avoid all of this.
Thanks so much for all the weekend responses.
-
It certainly would be silly. So even though we’re talking 10bit RGB here, you’re saying that PR4444 is a situation where the 8-bit limitation of FCP’s RGB implementation and gamma shift issues no longer apply?
-
Enterprise drives are never a bad idea (unless they’re green power drives) but I’ve had much success with desktop class drives as well. 15k rpm drives don’t have much advantage in 8 disk or more raid sets on color correction systems that demand high sequential throughput and not much random read throughput. 15k drives make a difference on compositing systems or editing systems where there is a higher demand for random read performance (lots of layers in a comp or fast edits). They’re also good in file servers or san configurations where multiple clients need fast access to data that’s spread out all over the disks. I’ve had these systems running flawlessly in direct attached configurations for several months:
8x Hitachi Desktar 2tb / Areca arc-1220X raid 5
8x Seagate ES.2 1tb / Areca arc-8040 raid 5
4x hitachi deskstar 1tb / highpoint rocketraid 4322 raid 5
4x hitachi deskstar 2tb / highpoint rocketraid 4322 raid 5
15x Seagate barracuda XT 2tb / LSI megaraid 9280-e raid 6
12x Seagate Constellation 2tb SAS / xyratex 5402-F4 dual raid 5 fibre -
I actually answered my own question with our scope. It appears that FCP (or maybe quicktime underneath?) does in fact scale 0-255 YUV data on output, but does a terrible job at it. Running a QC report out of our Resolve system with the same material in scaled output mode passes QC flawlessly. FCP’s output does not, yet when loading pre-scaled material into FCP, it is apparent on our scope and visually on a monitor that FCP is doing an additional scale on output. In most other finishing systems, one has the ability to switch between scaled output and full range output. Does a setting of this sort exist anywhere in FCP? If not, seems like the last resort would be to apply some sort of clipping filter to get rid of the extra illegal luminance value’s on FCP’s “mostly” scaled output. Would be sort of a band-aid method but may do the trick.
R. Adam Berk
Managing Director
Creative Technology San Francisco
http://www.CT-SF.com -
The material is actually YUV Quicktime (Prores HQ), not RGB.
R. Adam Berk
Managing Director
Creative Technology San Francisco
http://www.CT-SF.com -
Sorry, meant 16 not 64. Mind was elsewhere…
R. Adam Berk
Managing Director
Creative Technology San Francisco
http://www.CT-SF.com