[Jef Huey]

I am not sure, but I THINK that you could put a Kona 3 or 3G in an expansion chassis. They do not use that much of the PCI bus.

I might be wrong on that. But I think Sonnet shows just such an arraignment with their Thunderbolt expansions.

And on a somewhat related note, I am finding the new AJA Kona3G drivers are actually making my old Kona3 perform much better than it did with the previous drivers.

So I think that war horse will fight on!!

Thank you AJA for such a great product.

Jef

[Jef Huey]

I am having a very different experience. In fact a very good experience!

I am finding that the 10.4.5 drivers in conjunction with AE CS6 are giving me much better performance on my Mac Pro 3,1 with OSX 10.7.5. With the older drivers, I could not get a realtime ram preview with a 1080 29.97 composition. Now, all is good!

Don’t know how that might or might not help you.

Jef

[Jef Huey]

Or try exporting an AAF. I have had good luck with that version of “washing” a PrP project for Resolve. Not perfect, but better than nothing.

Jef

[Jef Huey]

You are correct it is not really a Dynamic Link problem. But it does make Dynamic Link a lot less useful if you are always fighting the Kona card.

Jef

[Jef Huey]

The way I would do this is to load the “source sequence” in the source window, Mark In and Out, go to the record window, Mark In, set track patching the way you want and then insert or overwrite as needed. Unlike other systems, this does not make a nested segment, it does what you asked to do. Many advantages of this method in my opinion.

Jef

[Jef Huey]

Hi Juan,

I want to be sure we are discussing the same thing here as I feel we may be missing some things.

I am talking about working inside an NLE with a source file of uncompressed YUV material where any rendering will be YUV based. FCP seems to fall into that category assuming projects setting are set so.

Also, one note from Marco’s codec test. “Please also note that these are RGB to YUV render tests and NOT a native YUV render test.” So any comments he makes are not pertinent to this discussion.

Ok, all that said, in the case where a YUV file is brought into FCP and a black mask is added and NO image interpolation is performed, you say that the entire frame must go through processing path. No argument from me. Where I do not understand you is that it seems as if you are saying that pixels in the middle of the frame – far away from the mask area – have been changed merely by the processing path. Is that correct? If so, then either FCP is doing something that most other NLEs do NOT do or I disagree with you.

I have talked with developers of several NLEs (though not FCP) about this issue in the past. They assured me that in an uncompressed environment only the pixels that needed to be changed by a process WERE changed. All others were left unaffected. If you have documentation to prove otherwise I would love to read it.

Thanks,
Jef

[Jef Huey]

Hi Joe,

I understand the issues of compressed codecs. My comments have been about the use of an uncompressed codec. Sorry if I was not clear enough about that.

Cheers

Jef

[Jef Huey]

Hi Juan,

Of course you are correct about the YUV to RGB to YUV conversions.

But the OP asked about the director doing the work INSIDE FCP. At that point given that he was talking about presenting the director with 4:2:2 files from color grade to do the final work there. Working inside FCP or any other NLE if you stay in the same uncompressed codec (as I noted in my response) and no transforms, a crop should not incur any change to pixels. Adding a title will only change the pixels where the title is added. Which is the goal.

Jef

[Jef Huey]

Juan,

I think you need to be more specific about your comment that even an uncompressed codec cycle is lossy. You did qualify that by mentioning resampling. But I don’t think you went deep enough with this.

In the case of the OPs question, if the image is not re-sized or repositioned at all and the codec type was not changed (same frame size, frame rate and codec type) – then there will be no “loss” because there is no resampling of unaffected pixels. Adding black at the top and bottom of the frame will not change the pixels in the inside of the black mask. That is the nature of an uncompressed codec. Each pixel is handled individually.

In a compressed codec, pixels are handled as a group. With any codec using any compression type, to change any material, the whole frame must be decompressed, the change made and the whole image recompressed. In a situation such as was described, there should be minimal change in the image when adding a black mask if the rules of no other picture change are followed.

But I would start to be worried about color accuracy issues seeing as Quicktime will be involved (ProRes) within multiple devices. Not saying it will occur, but many variables can get in the way of a perfect codec cycle with Quicktime.

Good luck,
Jef

[Jef Huey]

On the issue of speed changes. If the Avid editor just leaves the speed changes (Timewarps in Avid speak) on the clips, Resolve will not burn the speed effects into the material it renders. And as an editor I say that is generally good. Mainly because Resolve’speed changes are incredibly basic compared to the options available inside Avid. (Fluidmotion on a ramped speed effect?) So what you see is by design and rightly so. If the editor really does not want to do any work on the material you are color correcting after you are done, then I can say they should bake those effects that Resolve will not understand into those clips and cut them into the sequence / AAF they send to you. Timewarps being one of the most obvious.

As an editor I look at the AAF workflow as a great way to have a colorist do what they do best to individual clips while giving ME the editor the ability to tweak / refine the cut once they are done. I do not look at Resolve as a finishing tool. It is to limited.

Ready to be flamed ….

Jef