Re: image formats for rendering, etc.
Re: image formats for rendering, etc.
- Subject: Re: image formats for rendering, etc.
- From: "Pierre Jasmin" <email@hidden>
- Date: Fri, 8 Jun 2007 12:30:28 -0500 (CDT)
- Importance: Normal
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
> email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Pro-apps-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden