Joakim Ziegler
Forum Replies Created
-
This has happened to me too occasionally, also on a Retina MBP. It doesn’t happen consistently after 10 seconds of inactivity like you describe, I think, but definitely the cursor freezes at times when running Resolve, and after trying to move it for a second or two, it unfreezes.
Now, I’m pretty sure this happened to me on 9.0.x as well, though I wouldn’t swear to it.
—
Joakim Ziegler – Postproduction Supervisor -
Also, for some reason, you’re starting your card number on 1 every day, which is also not such a great idea. Maintain a continuous numbering of cards throughout your production. The date is embedded in the card name anyway, so it’s easy to distinguish days.
—
Joakim Ziegler – Postproduction Supervisor -
The “A” and “B” at the beginning of the clip/card names are camera designators. I have no idea why you’re changing it to “B” for day 2, but the correct way to do it is to set up your cameras as A, B, C, etc., and this will just solve itself.
Also, using timecode like that is a bit useless. The clip names (and reel numbers) are unique (as long as you make sure to increment as needed). We’ve generally found that using time of day free run for timecode is the most useful, since it needs no setting beyond checking it at the beginning of the day, and it’s easy to match sound and image even if the camera and audio recorder should for some reason not be linked. You can even jam sync the audio recorder and camera a few times per day, and you’ll generally be fine for audio sync.
—
Joakim Ziegler – Postproduction Supervisor -
Is the 1920×1200-like resolution still recommended? The whole idea of Retina Display support is that you guys can scale the interface yourself to the size you need, so you don’t have to get the OS to emulate a higher (really lower) resolution display for you. But you might not quite be there yet.
The thing is, in terms of GPU memory, the OS obviously always allocates its buffers for the 2880×1800 screen. But when you use the emulated modes, it allocates an additional buffer of twice the emulated resolution (in the case of 1920×1200, the buffer is 3840×2400), draws the non-retina aware software’s UI into that, and then scales that whole buffer down to 2880×1800.
This obviously eats up GPU memory. I often get out of memory errors or other weird behaviour when using this resolution with Resolve, which is why I usually set everything up for render, and then lower resolution to native and restart Resolve to actually render stuff.
But I’m sure HiDPI displays are something you’re thinking about supporting more completely in the future.
—
Joakim Ziegler – Postproduction Supervisor -
Just to pick this back up, LTO-6 is shipping and the IBM LTFS implementation lists LTO-6 drives as supported, but still no Mountain Lion support. Just wondering if you’ve had a chance to test Mountain Lion and LTFS.
—
Joakim Ziegler – Postproduction Supervisor -
That page clears things up a bit, true 6-bit LUTs is indeed a very nice feature. Lack of a network port for remote control and no SDI not so much, but still, workable.
What LUT format does it use? I’d like to check if it’s something we can generate. I’m tempted to buy one to test. What’s the price for the main component of Light Illusion that you mention?
—
Joakim Ziegler – Postproduction Supervisor -
As Robert said, the signal is probably 8-bit, and most of the camera’s internal image processing is applied to both the compressed video and the HDMI out. So range and similar things should be the same, I assume that’s what you mean by “gradeability”.
However, what you should see improving are compression artifacts. If you try to record very shaky handheld on a dSLR, or generally very chaotic images like close-ups of fast-moving water, etc., there are usually a LOT of compression artifacts and blocking, and the ProRes shouldn’t show any of that.
—
Joakim Ziegler – Postproduction Supervisor -
While Gamma is, as many others have surely noted, not really standardized and can be between 2.2 and 2.4, in my experience, it might be better to use a higher gamma rather than lower, for instance 2.35 instead of 2.2.
This is because a higher gamma makes your image darker, and it’s generally better if your image looks a bit too bright on another (possibly non-calibrated, consumer grade) display than if it looks too dark. At least with an image that’s slightly too bright, you can see everything properly.
At the very least, even if you’re grading with your display set to 2.2, it might be a good idea to check things with it set to 2.35 or 2.4, just to see what happens when people watch it on a darker display. It seems a lot of consumer displays have higher gamma and/or crush blacks a lot, in an attempt to get a punchier, “better looking” image. So protect yourself.
—
Joakim Ziegler – Postproduction Supervisor -
I was answering Sascha’s assertion that this setting only affects QT player, as I know it affects other, third-party software. Sorry if that came across as rude.
—
Joakim Ziegler – Postproduction Supervisor -
What LUT format does this use? Anything that can be generated by something that’s not Lightspace? We use CineSpace, and it’d be interesting to test this.
Also, does the eeColor actually use 6-bit LUTs internally? I see mention that the LUTs generated are 65x65x65, that is, 6-bit, but does it use that internally, or subsample them? The main problem with the HDLink is that its LUTs are 4-bit, and most other systems are 5-bit at the most (including Resolve, if BMD would like to fix that). The Davio is 6-bit, which is part of why it gives such good quality, and a cheap box that can actually do 6-bit LUTs properly would be great.
The part about downsampling to 10-bit for LUTing is a bit disappointing, though. Not really good enough for XYZ and such.
—
Joakim Ziegler – Postproduction Supervisor