Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

DaVinci Resolve 7 for Mac now shipping

jake blackstone said:
You need to drive the display with GT 120. If you try to drive the display with USB, which I don't necessarily believe will even work, you'll impact the performance of both real time playback and the colorist display. I believe, neither one will be real time. Also, I think you may have a problem with 2008 model. Resolve will run, but not necessarily in real time. Initially I had the same computer, but I was unable to play faster than 17 FPS at HD resolution, even with DPX, which makes me to believe, that you may will have the same problem even with RRocket installed. It's kind of shame to install Resolve and not be able to use it as a real time device...
Regardless, at this time Mac version doesn't allow to use more than one GPU for real time rendering. So, installing the second FX4000 or GTX 285 will not do you any good. GT 120 is used strictly for colorist display.
Click to expand...


Jake, i'm confused why this would be? There isn't a lot of difference is ther ebetween machines, in architecture?....2008-2009 changes, faster chip? Faster ram?.....i have a2008 8 core 3.2ghz i was hoping would be the machine to run resolve on,...is there any way we can be sure it won't run to speed on this machine?....
 
Robert Horwell said:
Jake, i'm confused why this would be? There isn't a lot of difference is ther ebetween machines, in architecture?....2008-2009 changes, faster chip? Faster ram?.....i have a2008 8 core 3.2ghz i was hoping would be the machine to run resolve on,...is there any way we can be sure it won't run to speed on this machine?....
Click to expand...

All I can tell you, is that my 2.8 GHz 2008 Mac couldn't do real time. 2.26 GHz 2009 does. Why? I suspect slower system architecture or no hyperthreding or... who knows... May be your faster computer will be able to do it, who knows...
 
Alexander Alexandrov said:
so, to confirm, the mac pro must have 2 gpu's to run resolve? there's no way to have only 1?
Click to expand...

Yes, you can run it with just one GPU, but then you will not get real time performance. If that's what you're after, then you may as well stay with Color.
 
The 2008 Mac Pro should run it just fine, but there are two major differences between it and the 2009 model. First and foremost, the 2009 Mac Pro is based on the i7 core or "Nehalem" series Xeon CPUs. This brings about a 15% overall speed increase to CPU operations and CPU bus transactions compared to the previous generation at the same clock speed. Additionally, the memory bus and RAM are clocked 25% faster. Virtual cores available through HyperThreading also helps load up the instruction pipelines on the CPUs, for properly multithreaded software, and can further boost performance.

My 2.93GHz '09 8-core is noticeably faster than my 3.2GHz '08 8-core. When rendering in Modo and Maya, the '09 Mac Pro is close to 25% faster overall. Same thing running Premiere Pro with RED clips, the '09 system can handle more and actually runs circles around my '08 system. But it's also not a fair comparison -- the '09 system is equipped with the GTX285, which makes a difference in Premiere. It also has the Rocket, so for overall RED workflow it stomps the older system into the dirt. The '08 box still has an nVidia 7800GT card and no Rocket and has been relegated to mostly CPU-bound tasks, backups, photoshop work, etc...
 
jake blackstone said:
Yes, you can run it with just one GPU, but then you will not get real time performance. If that's what you're after, then you may as well stay with Color.
Click to expand...

Really?

I'd thought that LUT implementation alone would be a reason to go with resolve, not mentioning node base, tracking and Rocket support.

But are you implying that one would get Color-like performance when not in realtime?
 
Gunleik Groven said:
Really?

I'd thought that LUT implementation alone would be a reason to go with resolve, not mentioning node base, tracking and Rocket support.

But are you implying that one would get Color-like performance when not in realtime?
Click to expand...
So in Resolve you can attach LUT to every node. Personally, I don't have much need for it. Some may disagree.
The way Resolve works at 1/4 to 1/2 debayer in real time, so far, I had no need for RR. But it's good to know, that in case I do, it's there.
Yes, Resolve has many high end features, that Color sorely lacks, like proper planar tracker, full editing and conforming package, real time performance, color fidelity, etc. Likewise, I'm not going to bash Resolve for it's shortcomings. It's a first iteration of the product and it's also a personal thing, really.
Said that, if real time grading is not at issue, one would be hard pressed to do something color grading-wise with Resolve, that would be difficult or impossible with Color. I'm talking about it from purely grading-wise point of view and not Import/Export or project management. If anything, right now Color has a distinct advantage in it's ability to be able to reprogram the Wave interface . I find Resolve's Wave interface at this point it's weakest link...
Once Resolve starts supporting CP-200 or Euphonics (I know, it's up to Tangent and Avid to do this) or ability to program the Wave, as well as addition of some, in my opinion, missing nodes (something like film grade, levels, simple six vector hue selector, noise reduction etc.), I'm ready to give it a second look.
I love what BM have done so far and even, if in my opinion, more work is needed, many Resolve users will be pleased.
 
How is versioning handled in Resolve as opposed to Scratch? One thing i love about Scratch is the ability to easily/quickly make layer stacks/versioning of "looks" in a clip and be able to pop through them for clients. Is Resolve similar at all in popping through 5-10 different looks on a clip quickly (minus the time it takes to create the actual look of course).
 
We've got Resolve up and running on a 2008 Mac Pro with Rocket + GTX285 + GT120 + Decklink Extreme 3. That configuration can't quite manage real-time playback in 1080p (using the on-the-fly proxies at 1600x900 works fine).

We're thinking of buying a new tower mostly just for Resolve, and I'm wondering if we should put the Rocket in it, or go for a RAID card instead. Is real-time 1/2 res decoding + 1080p playback solid on current 8 or 12 core machines without a Rocket?
 
mikeburton said:
How is versioning handled in Resolve as opposed to Scratch? One thing i love about Scratch is the ability to easily/quickly make layer stacks/versioning of "looks" in a clip and be able to pop through them for clients. Is Resolve similar at all in popping through 5-10 different looks on a clip quickly (minus the time it takes to create the actual look of course).
Click to expand...

Right click on the clip in the timeline and select "add version". The clip will show the number of alternative grade versions present. Right click to recall a version. Number of versions is unlimited. Not as slick as Scratch, but very usable nevertheless. Also, there is a way to render all different versions to different folders at once, if needed.
 
Jeff Kilgroe said:
Sanjin? You just mentioned using Macbook Pro... Will you be doing this?
Click to expand...

Jeff,

still not and just thinking about one really usable mobile solution with a combo that has Storm (pre-grade with a better white balance pick-up than buggy RCX) and Resolve (fast grade on the road).

In a couple of months should be probably much better situation with Apple/Intel hardware...
 
jake blackstone said:
So in Resolve you can attach LUT to every node. Personally, I don't have much need for it. Some may disagree.
Click to expand...

I am not really into attching a LUT ito every node, though that sounds interesting.

Thing is that with a properly working LUT implementation, you can stay log through your grade, and only render into rec 709 at the end, thus giving higher precission through the whole process.

In Color, if you apply a LUT in the beginning, it pretty much defies the purpose of going log in the firstplace, as it works as a pre-grade. In addition to that, all your metering is messed up, in case you want to render without the LUT burned in.

So, to me - if only the LUT implementation works right - it is a biggie - even without realtime.
 
Chris Kenny said:
We're thinking of buying a new tower mostly just for Resolve, and I'm wondering if we should put the Rocket in it, or go for a RAID card instead. Is real-time 1/2 res decoding + 1080p playback solid on current 8 or 12 core machines without a Rocket?
Click to expand...

Running it on a Nehalem 8-core 2.26 it gets close to 24fps for 1/2 res. Have to go to 1/4 for total reliability. Sorry, no info on faster machines yet.

BTW, wow, it is kicking the pants off of RedCine-X for Avid transcodes.

Like what takes DaVinci 8 seconds takes RedCine-X 2 minutes on our system (RedRushes would do it in about 30 seconds). Have to double-check this to make sure so don't quote me on it.

But yeah, I agree - DaVinci is single-handedly making me want to upgrade to the fastest damn 12-core out there.

The guys at my work are really impressed. Fingers crossed they build a DaVinci room with that nice $30k console!

Personally, I will stick it out with the 2009 8-core I have access to there... it's a ton faster and just stupidly more usable and time-saving than RedCine. I'm just gonna save up for a 12-core Sandy Bridge ultra-beast that'll hopefully come out at the end of 2011 with a next-generation Kepler graphics card from nVidia and a stack of SSDs.

Aaaaahhhh gonna be tough to hold out on getting a Quadro 4000 12-core DaVinci ultrastation though. Apple should really be giving Blackmagic a commission... or at least a USB3 port for their devices!

Bruce Allen
www.boacinema.com
 
Jeff Kilgroe said:
The 2008 Mac Pro should run it just fine, but there are two major differences between it and the 2009 model. First and foremost, the 2009 Mac Pro is based on the i7 core or "Nehalem" series Xeon CPUs. This brings about a 15% overall speed increase to CPU operations and CPU bus transactions compared to the previous generation at the same clock speed. Additionally, the memory bus and RAM are clocked 25% faster. Virtual cores available through HyperThreading also helps load up the instruction pipelines on the CPUs, for properly multithreaded software, and can further boost performance.

My 2.93GHz '09 8-core is noticeably faster than my 3.2GHz '08 8-core. When rendering in Modo and Maya, the '09 Mac Pro is close to 25% faster overall. Same thing running Premiere Pro with RED clips, the '09 system can handle more and actually runs circles around my '08 system. But it's also not a fair comparison -- the '09 system is equipped with the GTX285, which makes a difference in Premiere. It also has the Rocket, so for overall RED workflow it stomps the older system into the dirt. The '08 box still has an nVidia 7800GT card and no Rocket and has been relegated to mostly CPU-bound tasks, backups, photoshop work, etc...
Click to expand...

Thank Jeff,

I'll hang on to my 08 mac and give it a try when my GTX 285 gets here. If it's not cutting the mustard looks like i'll have to upgrade.....was hoping to wait until next year to do that though, hoping Apple finally get their finger out and builds a system that we have all been asking for for a long time now. It would be a shame not to use resolve to it's capacity....without breaking the bank that is!
 
Bruce Allen said:
Personally, I will stick it out with the 2009 8-core I have access to there... it's a ton faster and just stupidly more usable and time-saving than RedCine. I'm just gonna save up for a 12-core Sandy Bridge ultra-beast that'll hopefully come out at the end of 2011 with a next-generation Kepler graphics card from nVidia and a stack of SSDs.[/url]
Click to expand...

Hmm, yeah, if buying a current 12-core isn't going to get us real-time 1/2 res decoding without a Rocket (thus freeing up a slot for a RAID card), we'll probably just keep the current setup until next year. Next year's systems should solve this problem one way or another, via faster on-board external storage (USB 3 or Light Peak), enough CPU power to do software-based real-time decoding, or perhaps more slots.

Next issue is... I'm seeing a pretty major performance hit when the scopes are open. Disabling scope updates during playback would be fine, but there doesn't seem to be an option for this (just "Don't update interface icons in playback", which doesn't disable scope updates), and constantly opening and closing scopes gets old fast. Is there some workable solution to this problem, or should I plan on buying hardware scopes soonish?
 
Gunleik Groven said:
Thing is that with a properly working LUT implementation, you can stay log through your grade, and only render into rec 709 at the end, thus giving higher precission through the whole process.

In Color, if you apply a LUT in the beginning, it pretty much defies the purpose of going log in the firstplace, as it works as a pre-grade. In addition to that, all your metering is messed up, in case you want to render without the LUT burned in.
Click to expand...

That's not really the case, but one needs to understand the reason for log encoding in the first place.

If you're working from a Log encoded image, the chances are that you're working from some kind of file format, and further, that the file format is likely to be of lower precision than the original image. For instance, Cineon log files are 10 bits, but most scanners scan and do their math at a higher precision than that, often 16 bits. The same is true with R3d files, which essentially contain 12 bits of information directly from the sensor. In Red's demosaic process, this is expanded to 16 bits for better mathematical precision, and then reformatted based on the output format selected. Using log encoding allows for reduced precision in the areas of the image that will be relatively unaffected by that perceptually, say, the highest values. So by using log encoding, you can effectively fit 16 bits of information into a 10 bit container without seriously affecting the image integrity. When you take that into a color grading environment, the bit depth is promoted again, usually to 32 or 64 bits in most high end grading software, so that your manipulations can be carried out in a high bit depth environment, allowing very fine control. At the end of the process, you render and in almost all cases put the images into a lower bit depth environment again, often Cineon log for film recording, but in the future into a floating point file format like Open EXR that will maintain a lot of that precision. The use of an input LUT is no different than what the software is doing internally, which in many cases is putting the image into linear light values, doing the math to implement your corrections, and reformatting again for output. A proper input LUT will generally do the same thing, taking your 10 bit log values and expanding them to an equivalent 16 bit image.

I think you're looking at a logarithmic format in the wrong way. You seem to see it as a way to fit more information in the file, information which will somehow be "lost" if the file is then expanded. That would be true if the image was being converted into either an equivalent or lower bit death format. But in almost all cases with properly written color grading software, that is not the case. You seem to be looking at an input LUT as a "pre grade," but that is not really its purpose. In most grading software, its real purpose is to convert all sources that are in a different format than the primary project expects into a common format so that the grading software will see all of those images the same way, allowing the program to operate in one primary format and the colorist to "feel" all of those images in a similar way. If the software has a specific mode for dealing with log images, it's probably based on film scans, which in some high end correctors can be manipulated using specific controls that are designed to mimic film timing and yield a more film-like result. This is the case in both Baselight and Lustre, which have different types of controls for video and film images, with the video controls based on lift, gamma, and gain, and the film controls based primarily around exposure, contrast, and offset. In both cases, though, any image can be corrected using either type of control, it's just that the film controls are more tailored for images that are film sourced and film targeted.
 
Michael, as allways: Thank you!

So it is more a matter of perception, then...

Because I really think it's much easier (for lack of better words) to grade from a log image than a rec, and have thought that the higher precission in the input image was the reason for that, and it has felt "lost" with an input LUT - in Color, that is...

When Color is set to recognize the files as log, float works like it's supposed to (which it doesn't with RED RAW, for example. Thus I don't like grading from RAW in color).

When I use an input LUT in Color, it seems to just do a conversion which maps the image back to "lin/rec" and the files feels a lot less flexible and gradeable.

This might be a matter of perception.

I am currently going to play a bit with an eQ with redlogFILM DPXs. Again, a matter of perception, but from my initial session with it, it does feel "right" when applying an output LUT to that software. The resulting files seems to reflect that. But again - this is maybe just a perception with a "backward logic" applied. Allways risky... -:)

I will have some time with Nucoda and resolve too this fall, as it looks. Haven't yet. Baselight and lustres... I dunno who have them here. But I hope to sit in on a Scratch/dpx session soonly...

Yes you are right, I do think of log as a datacontainer in part. I'll try to stop doing that, though it has had a side-effect of being quite helpfull, so even if the rationale has been wrong, with redlog it has been rather effective...

I would think that "log as a datacontainer" would give the advantages for grading I do see in Color, but I have also figured your dislike for it.

Looking at how redlogFilm works - and resonating along the lines that redlogFilm is more "right/standard" I start to maybe see why you have expressed some dislike for redlog. RedlogFilm seems to handle the latitude in the files in a much "smarter" way, for one...

BTW. I don't look at an input LUT in general as a pre-grade. But the way Color handles input LUTS seems to work like a pre-grade, and I have that confirmed from other sources than my own observations. Without the LUT the grades feels a lot more stretchable, than with it.

If i am wrong about this, I'll accept that. I'm a bit more confused, but that's fine... -:)

I was specific about mentioning Color when I did the pre-grade remark.

Thanks again!

Cheers.
G
 
You must log in or register to reply here.
Back
Top