Re: Motion Color parameter round-tripping
Re: Motion Color parameter round-tripping
- Subject: Re: Motion Color parameter round-tripping
- From: Darrin Cardani <email@hidden>
- Date: Thu, 01 May 2014 15:29:25 -0700
On May 1, 2014, at 3:18 PM, Paul Miller <email@hidden> wrote:
> On 5/1/2014 4:56 PM, Darrin Cardani wrote:
>> It’s converting them between color spaces. I believe that the values you send to -addColorParameter: are in sRGB because that’s the color space that the user interface operates in. But your filter will process them in either linear or gamma-corrected RGB (depending on your -properties) with Rec. 709 primaries rather than sRGB primaries.
>
> But if I say I work in rec709 shouldn't it assume my default colors are also in rec709 and not convert them for me? It seems wrong to munge my default colors and give me different ones.
>
> Can you give me an implementation of the reverse of your function so I can pre-reverse-munge my defaults (when I define the parameter) so I get back what I gave you initially?
Yeah, I agree that it’s weird for setting some parameter values. I think the assumption is that you’ll pick a default via the color picker. Like, you’ll make a version of the plug-in with the color picker, and you’ll either play with it, or give it to a designer or beta tester, and they’ll pick some value from it that they think should be the default. In that case, you’d want to be able to just enter the numbers from the UI into your code without converting from sRGB to Rec. 709.
But that’s obviously not always the case. I’ll see if I can find a conversion routine.
Darrin
_______________________________________________
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