Forum Replies Created

Page 175 of 196
  • Joseph Owens

    March 3, 2011 at 2:36 am in reply to: Will Resolve work on the New Macbook Pro?

    My impression of the Macbook implementation is that it is intended to be a technology demonstrator, and field-grade preview -quickie/dailies director/dP utility. You do need some very specific configurations (memory is a biggie) to even get the application to stay running with media, and until Blackmagic actually approves/qualifies/recommends a hardware configuration (which would then be the law), its not anything that I would assume to be hunky-dory okey-dokey. And you still might only wind up with something that just barely works.

    Resolve is not an Apple ProApp, just like Final Touch wasn’t, either. The activity that I do see, the slight move toward ATI (approving the 5770) for User Interface, is interesting. Actually, wait a month or so, which is what I’m doing. Right now is no time to jump into anything.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    March 1, 2011 at 4:21 pm in reply to: Off-topic random question?

    Not really really way off topic, as the shooting format does influence workflow. You might get more results polling a cinematography forum — there are several.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    February 16, 2011 at 6:23 pm in reply to: 29.97 to 2k scan and filmout

    Reconforming to the original 23.98 might be worth the effort if this is going to filmout. A reverse-telecine on non-coherent 2:3 pull down from the 2997 xfr is not going to be pretty from either a workflow or end-yield perspective.

    You are also going to have to compensate the audio track so that it will stay in sync with a 24.000 frame rate, which is what you’re going to get as standard in the projection world. Its just something to stay aware of. Usually the house pulling the print composites take care of this.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    February 16, 2011 at 6:08 pm in reply to: QuickTime Pro and FCP Key

    Snow Leper 10.6.6

    Funny how QT7 becomes available in the Applications/Utilities folder on some systems, though.

    QTX? No idea.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    February 15, 2011 at 10:09 pm in reply to: Edit to Tape off by approx 10 seconds

    There are those who will roll their eyes when they see me joining the discussion. I hate the ETT module with a passion and fury so purple that no colorist on earth will ever be able to fix it.

    I wonder if your “miss” factor varies with pre-roll? Would it be different with a 10-, 5-, or 3- second preroll? In any event, though, I did experience a pre-roll oriented issue with Log&Capture about a year ago. To save some time, and because there were issues with broken time code on a source tape, I changed the pre-roll duration to something shorter — I can’t recall at the moment if it was much less than 3 seconds. What resulted is that about every eighth clip contained audio that was many frames out of sync. I suspect that it was a problem with ProRes, and its lead-time compression window. But everything with Final Cut is a deep, dark and un-addressed mystery.

    Frankly, gamers get better service and support for their toys.
    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    February 8, 2011 at 5:03 pm in reply to: Pulldown wrong in Final Cut

    I used to think it was an issue with ProRes (HQ) that FCP wouldn’t generate a proper 2:3 field cadence, since only 2:2:2:4 is offered, even in the RT settings. Using plain-vanilla ProRes brings back the options, but FCP still doesn’t change its ways and does not seem to be able to generate 2:3 at all. You can play back a 23.98 sequence through a Kona card, but it only generates 2997 2:3 field cadence on downconverts to SD, but not cross-convert to 1080i2997.

    Neither Export Quicktime, not Quicktime Conversion do it correctly, either. The only method that I’ve been able to glean is a very time-consuming trip through Compressor, Fast conversion, top-field first. Trying to achieve A-, or B- field dominance is another trick.

    Interestingly enough, the FCP/Compressor does seem to respect the SMPTE convention where it produces a C-frame at 10hours Drop Frame, which is somewhat ironic considering that it fails miserably at every other core task in a frame-conversion workflow.

    AVID does this like falling out of bed, but it came out of a broadcast environment where editing pull-down media was a given. Until FCP becomes field-aware, and I doubt that it can be built into the architecture, we’re on our own, doing the math.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    February 6, 2011 at 5:05 pm in reply to: Feature Request :Multilayer Timeline and XML is a must

    I think the confusion here is “what is the difference between a ‘feature’ and the internal system architecture”?

    If you want multiple video streams, with compositing migration between streams, all with real-time value remapping (color correction), then we’re probably a generation or so away from that, where the Mac platform is concerned.

    This is like buying a bungalow (a ‘single-story house’ where I live), and then complaining that there is no swimming pool on the third floor. Not only is there no third floor, the foundation was never built to accommodate extra stories, let alone the weight of a couple of tons of water way up in the air.

    When daVinci EdWin was introduced, the complaint was — only 4 pixels of softness? Well, err, the reply was, we’d have to rebuild the software. And so the ‘feature’ was next to useless, but it did introduce the concept of the User Shape, and Power Windows/ Power Tiers and so on enjoyed success in dV2K+. All well and good.

    Originally, daVinci operating systems were predicated on either telecine (single-source) real-time data throughput or tape-to-tape serial stream — in other words, no “layers” whatsoever. And somehow, we made a living with it, and for some reason, clients were prepared to live with the results.

    Believe me, if Resolve could do these things, it would be another reason why I would consider rejoining the daVinci grade approach. I just hope Blackmagic can make enough margin on the product that it justifies the development — and we have seen what happens with packages like these where its value gets marginalized. Like “COLOR”, nee Final Touch. But even in that case, although the product was specifically designed from concept to trade sequences via EDL and XML with Final Cut, it did not work until Apple took it on, and it is still not bullet-proof.

    I should add that that problem is not just a point-source deficiency. The observed sloppiness and total indifference to core technical requirements seen in contemporary editorial completely defies description. I’m not just referring to the “story-teller” editors who don’t know (and don’t care) the difference between 2398PsF and 5994i or that there may even be a difference; it even goes as far as the software developers themselves who, for example, have no respect whatsoever for even something as intrinsic as SMPTE field cadence.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    January 30, 2011 at 8:21 pm in reply to: Tangent cp100

    The only Tangent device that works with Resolve is the Wave, and it is fairly unlikely that any others will be qualified. Its a USB/Ethernet thing.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    January 10, 2011 at 8:51 pm in reply to: I Bar/Fleshtone Line on Ultrascope

    [Alex Borges] ” something that lets you compare several points though.”

    Actually available in COLOR… but this is BM Resolve…

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Joseph Owens

    January 9, 2011 at 8:33 pm in reply to: I Bar/Fleshtone Line on Ultrascope

    [Robbie Carman] “I would also like to see BM adapt a Diamond type display for RGB gamut errors”

    That would be lovely, but Tektronix holds the patent on that type of display — but its not, in fact, totally valid as a gamut warning in the Y’CbCr system as there are legal values in both that do not translate directly into the other, or to baseband composite which has its own gamut envelope in Y+C.

    As far as the In-phase axis (“I-bar”) graticule goes… it really should be part of any scope system that can synthesize or simulate a baseband composite video signal. But strictly speaking, that’s really all that its valid for. The Y’IQ/Y’CbCr transform is not a direct arithmetic rescale, its a matrix transform, and there is plenty of opportunity for round-off and phase errors to creep in. I agree, its a nice signpost, but its not an absolute, or bulletproof reference. I suppose its okay for B, Ed&I straight-up talking heads, but for drama, almost useless, dPs are always using theatrical lighting, so fleshtone can be almost anything. What’s hilarious is the cyan/amber “action” palette, where, just because you can, everybody is “normal”, even in an over-the-top blue wash. There has been some discussion about this, and one observation was made that some movies could be “dated” by the color design.

    jPo

    You mean “Old Ben”? Ben Kenobi?

Page 175 of 196

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