Forum Replies Created

Page 21 of 41
  • Mike Most

    March 28, 2012 at 9:39 pm in reply to: REDcolor3?

    [Gabriele Turchi] “Mike i 100% disagree with you (maybe for the first time :)”

    Which part?

    It is absolutely true that we all talk from our own particular perspective, and that’s always influenced by the particular market we work in and the type of work we encounter. What I said about the work I encounter is true about that work, not necessarily about everyone’s. But I’d also stand by what I said about Assimilate being a rather Red-centric company, and Blackmagic being a bit more format agnostic. I would add that integration of code from a third party is never straightforward, certainly not as straightforward as Red would like you to think it is. It needs to be QC’d and tested quite heavily by companies like Blackmagic before it’s pushed out to users who won’t understand when problems occur and Blackmagic can’t solve them because it’s not their code, especially if they see it “work” in a program like Redcine X, which is designed for it. Blackmagic is a bit more reticent to release these things as quickly as, say, Assimilate because they have a wider user base that is not solely Red-centric. So they take a bit more time in order to avoid being the guinea pig. Personally, I don’t have a problem with that. However, YMMV, and probably does.

    From what I’ve seen, the Redcolor3 change from Redcolor2 is not particularly dramatic and most definitely not a “big deal.” The combination of Redcolor3 and Redgamma3 is more significant if you’re talking about the on set monitor feed, which is what is was designed for. For those of us in post production, “big deal” is a bit of an overstatement. But once again, that’a only my opinion.

    As for disagreeing with me, that’s what these discussions are for. If everyone agreed on everything, or if everyone worked on the same projects and therefore had the same perspective, there wouldn’t be any need for these forums and the discussions would be much less interesting. I not only welcome the fact that you disagree with me, I appreciate it and try to learn from it.

  • Mike Most

    March 28, 2012 at 3:57 pm in reply to: REDcolor3?

    [Gabriele Turchi] “i quite don’t get why you guys are not updating …Assimilate SCRATCH took 4 days to update the red SDK …

    That’s a pretty unfair statement. Assimilate has always been much more “Red-centric” than any other company, in part because their connection with Red is a major factor in how they re-established themselves in the marketplace (they co-authored the original Redcine, remember?). Every company has its priorities, its particular strategic alliances, and its own specific coding/updating issues. You can say that Scratch had Redcolor3 support first, but then again, they took a few years to introduce Avid MXF support, which Resolve has had for some time, and which to many is far more important than the “latest and greatest” Red stuff that’s only been available – even in Red’s own software – for a few weeks. Besides, Scratch is marketed as an all around processing tool, not necessarily a grading system. It’s used for conforming and particularly for dailies creation, including double system synching and simultaneous multiple deliverables. They even have a lower cost version created specifically for that market (Scratch Lab). That is NOT Resolve’s focus, even though some people here and elsewhere might want it to be. “Instant Results” are useful in a dailies system. They’re not so useful in a final grading system.

    Red is not the only camera in the world. In fact, in a number of markets that many of us work in, the Alexa is far more widely used and critical to have direct support for. In the television world in which I currently live, frankly we’re now seeing much more interest in the Canon C300 (supported by Resolve 8.2) than we are Red. That’s not a personal bias (I happen to like Red), it’s just fact. Just because Red likes to completely change their software every couple of months doesn’t mean Blackmagic should.

  • [dermot shane] “color tools are much the same, reslove’s UI is mile ahead, but ablity to elegantly do changes – well it exists in DS, Mystika, Pablo, and soon Fluster…”

    I would add Assimilate Scratch to that list. And it costs a lot less than everything else you’ve mentioned with the exception of DS.

  • While I don’t necessarily disagree with your conclusion about finishing tools becoming more comprehensive, I would also point out that the cheapest tool of the three you mentioned (DS) still costs 10 times what a Resolve license costs. I’m not saying that Resolve doesn’t compete with these things – in some circles it does – but to some degree, you’re comparing things that are aimed at very different markets at vastly different price points. And you’re comparing a tool that actually exists (Resolve) to one that doesn’t (your theoretical Lustre/Flame integrated combination, which actually has been shipping for almost 1 1/2 years as Flame Premium, which also includes Smoke). And unless I’m mistaken – and I might be – I believe that DS already works with the Avid Artist panel series.

    As for “everything” headed towards a more comprehensive tool set, I would probably dispute that. At the higher ends of the industry, specialization is still very prevalent and highly desirable. Good conforming and finishing artists are not expected to be great colorists, and vice versa. In the “one man band” world of smaller operations and individuals, that is not the case. But then again, you’re not likely to find a Baselight, Flame Premium, or Pablo setup in those places…

  • Mike Most

    March 26, 2012 at 7:26 pm in reply to: monitor out?

    That’s a bit of an overly simplistic answer, and not entirely accurate. 422 and 444 as monitoring modes differ primarily in how you feed them, what your monitor device is, and what you’re proposing as a processing pipeline. There are a lot of “indie” projects that are graded in Rec709 and put through a simple transform when the DCP is made. In that scenario, 422 monitoring is perfectly acceptable provided the monitor itself is properly set up. Monitoring in 444 RGB using dual link is preferable, but for most scenes really isn’t going to make any appreciable difference. If you’re working in P3 on a proper monitoring device (say, a 2K DLP Cinema projector) that changes the situation, but if you’re looking at a video monitor, it’s not a simple answer like “422 is unacceptable” or “444 is acceptable.” There’s a lot of room between the two depending on who’s doing the work, what they’re doing it on, and the level of expectation with regard to an exact visual match to final deliverables, especially when you’re talking about no-budget “indie” projects.

  • Mike Most

    March 22, 2012 at 8:24 pm in reply to: resolve render compressions

    I didn’t say they were using H.264. I said they are using DNxHD 115. That’s quite different.

    As far as PVR goes, a PVR doesn’t really do anything to the image. Ir records the off air compressed data and plays it back, in most cases.

  • Mike Most

    March 21, 2012 at 4:28 pm in reply to: resolve render compressions

    220X is only for 60i material. 175X is the same level of compression for 24p material.

    There are network shows that shall remain nameless that are posting, coloring, and delivering using DNxHD115, so if you think 175X has problems, consider that fact. I certainly don’t recommend using something as heavily compressed as 115 for mastering, and I certainly don’t recommend it for color correction purposes, but it’s being done anyway, appalling though it may be. And on some very major projects. The race to the bottom continues….

  • Mike Most

    March 21, 2012 at 4:05 pm in reply to: resolve render compressions

    Any image processing must of necessity take place on an uncompressed RGB frame. You can’t perform transforms and other manipulations on compressed data because there’s no real image information to use when it’s in that form. So the short answer to your question is yes, everything that goes through Resolve – or any other grading system, VFX compositing software, or any effects creation (and that would include a simple dissolve in any editing software) gets decompressed, transformed, and then recompressed on output. The only way to do a “pass through,” as you describe in Final Cut, is to do nothing to the image other than trim it. This eliminates the need to decompress because you’re not manipulating any of the image information. That’s also why a mixdown on an Avid can be done so quickly, because it’s basically just rewrapping the already compressed information. But as I said, as soon as you want to do anything to the image itself that goes out the window.

  • Mike Most

    March 18, 2012 at 6:45 pm in reply to: Thunderbolt Expansion Chasis

    >>Just think if we could add a Cubix to a MBP… who would need a Mac Pro ever again?

    Anyone who wants PCIe expansion with full 16 lane capability and full bus speed.

    Unless Thunderbolt is seriously re-engineered, this is only capable with bus mounted HBAs.

  • Mike Most

    March 18, 2012 at 6:04 pm in reply to: OUTPUT LUT – Banding Issues During Playback

    Well, as a hack you might want to try creating a track node and attaching the output LUT to it to see if you still have the same problem.

Page 21 of 41

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy