site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Importance: Normal User-agent: SquirrelMail/1.4.8-4.0.1.el4 Are you linearizing when it's 32 bit and not when it's 8 bit? If so, quick note on the issues of linearization : 1) there is a class of image one could define as "non color data" which should not be linearized, alpha being the most common (right an alpha should be considered already linear), other more exotic but not that much examples would include for example a Zbuffer or UV map. If you play with the public beta of AE8 you will see now that per source footage you can turn off color management so one can properly handle "non color image data" (by properly I mean it does not get gamma transform baked, is assumed to already be linearized)... so such class of images is not affected. 2) A usual problem that derives from this linearized/delinearized thing (which does not work in 8 bits, especially on top of a cascade of premult-unmult) is not understanding as a plugin where mid-grey is, and it can be problematic if say a slider set to threshold 0.5 which is 127-128 in 8 bit becomes 0.18 (0.5 * 1/gamma2.2) in one pixel path and stays 0.5 in another pixel path... (make a greyscale ramp in 8 bit within the app, although the round trip to float with linearization might be non-destructive, I am hoping it won't shift 0.5 to be if I am rgb motion gamma 0.5 X 1/gamma2.2, and to be if I am yuv fcp to 0.5 X 1/gamma1.8). A possible solution is to provide an inverse gamma value associated with the image node (not unlike the premult flag, or like QT does with gamma on Mac but not on Windows). In the case of an internally generated greyscale ramp (any synthetic image) what do you do, it's already linear (it needs to get the same already linear tag as the UV map or the matte). Knowing the inverse gamma would allow one to internally always produce the same result independent of pixel path by adapting the meaning of color related parameters. Pierre
On Jun 6, 2007, at 5:32 PM, Peter Litwinowicz wrote:
And then there's this question: if my input image is given in a particular format, will all clipwells for the plugin ALSO be converted to the same format, or do they each have their own formats we need to deal with?
In Motion, since all images are RGB, you only have to worry about bit depth, and we take care of that for you by promoting everything to the same bit depth. I'm not sure about FCP.
Okay, good to know. So I get floating point images within Motion if the image that my effect is applied to is 8 bit, and the image in my clipwell is floating point (can this happen with Motion? Im unclear whether floating point/8Bit is a project setting or a per- clip setting). Can this go into the doc?
It's a project setting. If the project is 8-bit, everything you receive should be 8-bit. If the project is 32-bit, everything you receive should be 32-bit. And yes it can go into the docs. :)
Darrin -- Darrin Cardani dcardani@apple.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/jasmin%40revisionfx.com
This email sent to jasmin@revisionfx.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... This email sent to site_archiver@lists.apple.com