i am learning a lot about 32bpc floating point processing and HDR
and now have this question about PPRO.
AE has a 32bpc color pipeline. PPRO does not.
Todd Kopriva states from a thread in AE that
If you want to make a feature request for Premiere Pro to have a 32-bpc, high-dynamic-range color pipeline like After Effects, then you can submit a feature request. Be sure to articulate in your feature request why you think an NLE needs a complete 32-bpc, high-dynamic-range color pipeline. Usually, this is only considered important and useful for a compositing and visual effects application, and not as much for an NLE
and to be honest, i don't know whether NLEs like PPRO should or should not have a COMPLETE 32bpc pipeline.
i would think the more complete the better, unless someone in this forum can explain otherwise.
it probably is more expensive to have PPRO have a COMPLETE 32bpc color pipeline is the only thing i can think of myself.
this situation seems analogous to audio recording: mix in 24bit, mix down to 16bit...
any advice / info would be appreciated
Premiere Pro does support 32-bit per channel floating point video throughout the pipeline. I'm sure Todd was making reference to some certain capability AE has that isn't in PPro, but without seeing the original post, I'm not sure what he was referring to. However, Premiere Pro has supported 32-bit floating point rendering since version 2.0.
Premiere Pro renders in various pixel formats and depths depending on the input formats, but as a user you can always force 32-bit floating point rendering by checking the Maximum Bit Depth checkbox in the render / export settings. New in CS5, the Effects panel has various badges to show the capabilities of each effect, so if 32-bit rendering is important to you, you should stick with the effects that have the 32-bit badges.
originally i wanted to make a list of all the available 32bpc effects for PPRO and AE
after a little searching and asking, i found out that REvision's effects work as 32bpc for AE
but only 8bpc in PPRO and that adobe controls why it only works in 8bpc
Todd then added that AE has a COMPLETE 32bpc color pipeline and that PPRO (being a NLE) does not have a COMPLETE 32bpc pipeline
which led to the creation of this thread, asking if PPRO should have a COMPLETE 32bpc pipeline.
i am aware of the 32bpc and yuv badges
i do want to see if i can't find 32bpc effects for the effects i mostly use
because i read that if all of the effects in the sequence aren't 32bpc then the sequence gets rendered at the lowest bpc setting
(UNLESS: you turn on MaxBitDepth (like you said to do) forcing the 32bpc,
but then i also read that noticable differences can be seen in the final output...
thanks for your patience and any other advice...
In your original post, you made reference to a response that you got from the RE:Vision FX guys about how the SDK for Premiere Pro didn't allow them to create 32-bpc plug-ins. You asked why that was the case. I recommended that you bring that question here so that the Premiere Pro SDK folks (such as Zac) could answer that.
I'm late in coming back to this thread, but for anyone who is wondering where 32 bpc effect rendering stands in Premiere Pro, I wanted to clarify what's going on. As mentioned further up, Premiere Pro does contain a considerable number of effects that are 32-bit capable. This 32-bit rendering has been available since Premiere Pro 2.0. CS5 now provides badges in the Effects panel so that an editor can distinguish between which effects are 32-bit capable, which ones can process YUV natively, and which ones are limited to 8-bit or RGB.
The limitation RE:VisionFX is referring to here is in a specific function (PF_CHECKOUT_PARAM) in Premiere Pro's support for the After Effects API. That function provides a way for an effect plug-in to get frames at times other than the input frame. Most effects like color correction, displacement effects, and light effects, and dissolves don't need to get frames at other times. But plug-ins that provide time remapping or motion blur do need this function. This limitation is bug 1516663, and we planning on addressing it in a future version.
It sure would be nice if the badges said whether they natively support 601 and 709 color spaces.
It's frustrating that there are bugs in CS4 (and I think CS5 from what I've heard) that convert the 709 to 601 and back wrongly.