shoot 4:2:2 or 4:4:4

[PDR]

if anyone knows if this bug still exists in CS5?

yes bug still exists

Here's a relatively serious point of interest, especially to AVCCAM users, and I'd love to hear Barry Green's take on it.

I had a conversation with Adobe today in which they confirmed the video I'm going to link to below...

LINK: http://vimeo.com/13764135

They're saying that Premiere Pro CS5 upsamples all footage imported to 4:4:4 -- and that all color correction done with 32 bit plug ins are done in 4:4:4 -- including AVCCAM footage.

This statement is misleading , because Y'CbCr footage is converted to RGB anyways when color correction plugins are used. RGB isn't subsampled (4:4:4) . Adobe has been doing that for years as well, as do virtually all editors, even the free ones. There is no color management in Premiere (but there is in AE) , so you're stuck with the wrong RGB conversion (Rec 601 vs. Rec 709 workflow, the latter which is usually used with HD workflows)

The difference in CS5 is the part about 32-bit float, where intermediate calculations are more accurate (fewer rounding errors), and the few plugins that work in YUV (Y'CbCr) colorspace, before the RGB conversion (that video didn't mention that part, but it's important)

Not transcoding is great, provided the software can handle the various formats correctly. Adobe currently doesn't handle it properly for AVCHD, and formats such as Canon's DSLR aren't handled optimally either (decoded through Quicktime API)

 

[AGMedia]

yes bug still exists




This statement is misleading , because Y'CbCr footage is converted to RGB anyways when color correction plugins are used. RGB isn't subsampled (4:4:4) . Adobe has been doing that for years as well, as do virtually all editors, even the free ones. There is no color management in Premiere (but there is in AE) , so you're stuck with the wrong RGB conversion (Rec 601 vs. Rec 709 workflow, the latter which is usually used with HD workflows)

The difference in CS5 is the part about 32-bit float, where intermediate calculations are more accurate (fewer rounding errors), and the few plugins that work in YUV (Y'CbCr) colorspace, before the RGB conversion (that video didn't mention that part, but it's important)

Not transcoding is great, provided the software can handle the various formats correctly. Adobe currently doesn't handle it properly for AVCHD, and formats such as Canon's DSLR aren't handled optimally either (decoded through Quicktime API)

I'll forward your interesting answer to my contacts at Adobe and we'll see what they say.

 

[Barry_Green]

The original version of CS5 does indeed still have the bug. It just auto-updated though, so it's perhaps gone now. I'm on the road and can't test it, but if someone would be so kind as to update to the latest update to PPro CS5 and test it, it's my understanding that it's supposed to be fixed now.

 

[PDR]

Nope, problem still exists I'm not seeing any updates beyond 5.0.1

Did one of your contacts say it was fixed , Barry ?

 

[mcsmooth]

I'm pretty sure they Premiere Pro fixed the h.264 chroma bug in the recent 5.0.2 update. It was most noticeable with extreme colors like bright reds. I was usually able to replicate this by transcoding a clip to DVCProHD and comparing frames against the original in Premiere.

This was the first thing I checked after the update. Only did a quick test, but things look a lot more promising.