Joakim Ziegler
Forum Replies Created
-
What’s your source format/frame rate?
—
Joakim Ziegler – Postproduction Supervisor -
I have one on order, it’s supposed to arrive next week. If you’re still interested, I can give you my impressions then, but it seems like you might be out of time…
—
Joakim Ziegler – Postproduction Supervisor -
The whole point is that there’s a new version of OpenCL coming in Mavericks, at roughly the same time as the new Mac Pro. Old (current) OpenCL is not particularly good, new OpenCL is (according to people who have used it) vastly more efficient.
And what hardware Apple chooses to make available on their platforms has always dictated software development on MacOS. That’s old news.
—
Joakim Ziegler – Postproduction Supervisor -
Apple usually comes out with new hardware along with new software.
In general, I’d say, OpenCL is probably the right way to go on all platforms and GPUs. It’s an open standard, it’s also supported on NVidia GPUs (indeed, NVidia is part of the OpenCL consortium) and others, and it’ll make more sense than CUDA for anyone wanting to abstract away more hardware.
This is one of those cases where faster hardware will make more general and higher-abstraction standards make sense. As CPUs got faster, we moved from assembly language to C to C++ and now to things like Java, C#, etc. They’re not quite as efficient, but we gained a lot of programmer productivity, which in the long run makes more sense. I predict the same thing will happen with a transition from CUDA to OpenCL. OpenCL doesn’t need to be quite as efficient, just in the same ballpark.
—
Joakim Ziegler – Postproduction Supervisor -
Very likely Apple and BMD have cooperated to bring support for the new and improved OpenCL to Resolve 10. That’s why you haven’t been using them before.
—
Joakim Ziegler – Postproduction Supervisor -
Rec.709 display gamma is “well known and common” only to the extent that it’s between 2.2 and 2.4. Common values are 2.2, 2.35, and 2.4. There’s no standard or consensus more exact than that, if someone’s telling you there is, they’re incorrect.
I was going to link to Charles Poynton’s excellent article on the subject, where he describes exactly this de facto standard, but I can’t seem to find it on his site at the moment… I might just not be looking properly.
—
Joakim Ziegler – Postproduction Supervisor -
I’m sure adding a gamma option to OpenDCP would be hugely useful. As I mentioned, you might want to look into white point correction too, I don’t know if you already do that.
We generally do all our grading in P3, and that’s much easier to convert to DCI X’Y’Z’, since it’s completely standardized, but it’s often useful to be able to convert from Rec.709 for material people bring in. For what it’s worth, EasyDCP is one of the better built-in conversions I’ve seen in DCP software, but we mostly make our own LUTs (we use CineSpace).
I think it might be time to look at OpenDCP again, maybe. DCP authoring is not really so complicated that we should be paying a bunch of money for the software, and most software is actually not great in functionality or UI. We use CineAsset, and it does the job, but I can’t say I love it.
—
Joakim Ziegler – Postproduction Supervisor -
To specify, I’m rendering the ProRes files on the Mac, over the network, from files that are on the Linux box.
There’s probably no speed benefit to the actual renders, but the Linux Resolve we have is vastly faster (and more stable) than the Mac system, and it’s what we have in our large suite with a projector, etc.
—
Joakim Ziegler – Postproduction Supervisor -
We used to do this by doing play out over SDI and capturing to ProRes. This was slow and error prone, however. Now, we have a Mac with Resolve on the same 10GbE network as the Linux Resolve, mount its disks over NFS, and just either do a render on the Linux box to DPX sequences and use the Mac to render that to ProRes.
You can also theoretically open the actual projects from the Linux box database on the Mac, and just render directly, as long as you make sure your mount points are identical on both boxes.
The advantage of this is that as long as your disks and your network are properly configured, you can get much faster than realtime renders, I can render HD ProRes files from 2k files on the Linux box at more than twice realtime speed.
—
Joakim Ziegler – Postproduction Supervisor -
Rec.709 does not have a defined gamma. It has a defined encoding curve, but the decoding gamma is non-defined, and the industry standard de facto curves for decoding vary between g2.2 and g2.4.
However, rec.709 material presupposes this decoding gamma for a dim surround (typical TV watching environment) while DCPs presuppose dark surround (movie theater). Thus, it’s often appropriate to adjust gamma even more when converting from one to the other, a “straight” conversion often ends up too dark looking when going from P3 to rec.709, and too punchy when going the other way.
And then there’s the white point. If you go straight through XYZ when converting between rec.709 to P3, you will experience a quite noticable green/magenta shift, and your whites won’t be pure in the destination space. Some LUT generation tools will let you do white point correction to avoid this, so that pure white in P3 (5800K) will end up being pure white in rec.709 (6500K).
Sorry to go on a rant. It’s just that from practical experience, this stuff is not quite as simple as the basic math and specifications make it look.
—
Joakim Ziegler – Postproduction Supervisor