August 2012 - Pro-apps-dev - lists.apple.com

OpenGL Shader software fallback does not render
by Christoph Vonrhein 28 Aug '12

28 Aug '12

Hello List, I'm currently writing a FxPlug plugin, where I need to use an OpenGL shader. The shader compiles and renders just fine on my Mac Pro. On an older MacBook Pro however it happens that the graphics card cannot do certain things of the shader and this causes OSX to use the software shader to do the rendering. However when OSX decides to use the software shader, then it will not render anything in my plugin. The original texture is just passed through and the shader does not do anything. The vertex and fragment shader compiles without any problem on both machines. I can even pull all used Uniform variables, which also shows that the shader was compiled correctly. The shader works perfectly with the OpenGL Shader Builder application on both machines. This shows me that the software renderer of OSX is functional. The OpenGL Shader Builder application also shows me when OSX falls back on the software renderer. When this happens with a certain shader, then my plugin does not work. My test environment for this is OSX 10.6.8 on a MacBook Pro with ATI X1600 graphics with Motion 5. To do the actual rendering I use a standard glBegin() glEnd() loop with a glFlush() at the end. I wonder if I just forgot to (gl)enable anything that needs to be enabled to make the software renderer run. Somehow I thought that the fallback to software renderer is decided by OSX and I don't have to do anything to "help" OSX. Thanks! Christoph Vonrhein _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: what to do about plugin linkage collisions in FCPX
by Darrin Cardani 27 Aug '12

27 Aug '12

On Aug 26, 2012, at 7:14 AM, Paul Miller <paul(a)fxtech.com> wrote: > I have a plugin that links statically with a third party library. When it is used while another third-party (hi Jim!) plugin (that happens to link DYNAMICALLY with a different version of the *same* library) is present in the Plugins folder, FCPX crashes. > > The crash stack trace follows my code down into my static copy of the third-party library, then it jumps into the dynamic version of the library that is present in the other plugin (which is not applied to the clip, it's just present in the plugin folder). > > This all happens because of the extremely lazy binding going on by default in Objective C programs. I would expect it to call into my *statically linked* version of the code, but it ends up in what I suspect is the first code it encounters with the same function signature, which in this case is in someone else' (incompatible) library. I've got a question into the linking people to see if they have any suggestions. I'll let you know what I find. > Is there any way to work around with XCode linker options to more permanently bind the function addresses of my code? And although I like having verbose stack traces, I wouldn't mind turning off the option that exposes all of my function names. I'm sure users do not want to see functions such as "WellBleepMeWithaBagOfDildos()" in their crash reports. For this, you could probably strip symbols from your plug-in, couldn't you? I'm pretty sure I've seen stack traces where 3rd party plug-ins show up as just addresses with no names in them, so I think some people are doing this already. Note however that it can be helpful to us at Apple to know that a particular plug-in was involved in a crash. If it's one we have on hand, we can just drop it in and see if we can reproduce the problem, and if it's on our end get to fixing it, or notify you if we think it's on your end. If there's no indication of what plug-in it was, we have to try to contact the customer, and if we're lucky they'll be able to tell us which one it was, and then we can finally get to work on it. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

what to do about plugin linkage collisions in FCPX
by Paul Miller 26 Aug '12

26 Aug '12

Thanks! _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com I have a plugin that links statically with a third party library. When it is used while another third-party (hi Jim!) plugin (that happens to link DYNAMICALLY with a different version of the *same* library) is present in the Plugins folder, FCPX crashes. The crash stack trace follows my code down into my static copy of the third-party library, then it jumps into the dynamic version of the library that is present in the other plugin (which is not applied to the clip, it's just present in the plugin folder). This all happens because of the extremely lazy binding going on by default in Objective C programs. I would expect it to call into my *statically linked* version of the code, but it ends up in what I suspect is the first code it encounters with the same function signature, which in this case is in someone else' (incompatible) library. Is there any way to work around with XCode linker options to more permanently bind the function addresses of my code? And although I like having verbose stack traces, I wouldn't mind turning off the option that exposes all of my function names. I'm sure users do not want to see functions such as "WellBleepMeWithaBagOfDildos()" in their crash reports.

1 0

Re: Linear Color ( or not? )
by Darrin Cardani 24 Aug '12

24 Aug '12

OK, if the input images are in a format like .png, .tiff, .jpg, .psd, etc. then you probably want to treat them as gamma-corrected RGB. One thing that would be nice is if we could allow your plug-in to tell the host app that a particular image input is really data, or something like that, so we wouldn't touch the data. But right now, there's no way to do that other than you displaying a dialog to the user to select the file and reading it in yourself. If you are ever in a situation where you need some inputs to be linear and some to be gamma-corrected, you can convert between the 2 using square & sqrt(). The small amount of difference between that and doing the actual gamma 2.2 conversion will be negligible visually. Darrin On Aug 24, 2012, at 1:49 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: > Sorry, I should have just come clean about what I am trying to do. > > I am porting a series of FxPlugs that need to decode data encoded in images. Those images could be rendered procedurally in an FxPlug or come from an external source. For instance, if I import an 8bit image that was created in PS and all pixels were set to 127,127,127 I would like the fragment shader to see 0.49803 are there abouts. > > The first FxPlug is stupid simple. It takes an input image and tries to decode it as vectors 0.0 == -1.0, 0.5 == 0.0, 1.0 = 1.0. > > When I think linear - 8bit 0-255 is 0.0-1.0 discarding any color profiles. > > > On Aug 24, 2012, at 3:38 PM, Darrin Cardani wrote: > >> David, >> >> You shouldn't have to compensate for any gamma correction. I was just using that as an example to clarify how it works. Either your plug-in should work in linear, if that's appropriate, or it should work in gamma corrected space, if that's appropriate. It sounds like in your case, maybe working in a gamma-corrected space makes more sense. If that's the case, simply use the kFxImageColorInfo_RGB_GAMMA_VIDEO instead of kFxImageColorInfo_RGB_LINEAR in your -properties dictionary. >> >> As a rule of thumb - color correction filters usually need to work in gamma-corrected RGB, whereas anything simulating lighting or light-related effects needs to work in linear RGB. Another way to look at it: if your filter is based on how people perceive color, make it work in gamma-corrected space, whereas if it's based on physically simulating light, make it work in linear RGB. The host app will take care of converting it to the proper output space after you're done with it, you just need to tell us which space your code is working in. Does that make sense? >> >> In your example below, it's kind of hard to tell you what you should do because an RGB value of (0.5, 0.5, 0.5) is meaningless without knowing the color space. So when you say "I need an input image that was rendered 0.5, 0.5, 0.5 to evaluate to 0.5, 0.5, 0.5 in a fragment shader," you need to say in what space the rendered 0.5, 0.5, 0.5 is. If you mean that when it is displayed that a tool like Pixie shows an on-screen value of 0.5, 0.5, 0.5, then your input is in gamma-corrected RGB. But if it's an OpenEXR that has linear RGB in it, then a value of 0.5, 0.5, 0.5 will mean something different. What are your inputs? HD Video? How are you getting the "0.5, 0.5, 0.5"? From Motion's color display in the canvas? If so, that's gamma-corrected. >> >> Darrin >> >> On Aug 24, 2012, at 1:26 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: >> >>> >>> Hmm. It isn't really linear output then right? The outputimage says it is in linear color space. How would I know what gamma to compensate for? Seems like there could be custom gamma curves for each channel in some cases? >>> >>> I digress, the real issue is that I need an input image that was render 0.5,0.5,0.5 to evaluate to 0.5,0.5,0.5 in a fragment shader. Right now it does not seem that the input image is transformed to linear space. >>> >>> Appreciate the patience. >>> >>> >>> On Aug 24, 2012, at 3:16 PM, Darrin Cardani wrote: >>> >>>> David, >>>> >>>> It sounds like you get the basic concept. You are correct that you need to include that value in your properties dictionary to get inputs that are linear and to output your results in linear RGB. >>>> >>>> What's not so obvious is that if you output (0.5, 0.5, 0.5, 1.0) in linear RGBA, a couple of things happen. Before displaying your output to the screen or exporting it to a file, we need to convert it from linear to gamma-corrected RGB as a final step. The gamma-corrected value of linear 0.5 will be about 0.72. (That's 0.5 ^ (1.0 / 2.2).) This works as expected, but can be confusing. If you want the gamma-corrected result to be 0.5 (and for it to look like "middle gray") you need to use (0.21, 0.21, 0.21, 1.0) for your RGBA value in linear RGB. >>>> >>>> If you've ever heard of "18% gray" being middle gray, that's in linear RGB. As you can see, 0.21 is just a little more than 0.18, so they're pretty close. >>>> >>>> Darrin >>>> >>>> On Aug 24, 2012, at 12:44 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I apologize if the following has been addressed and I missed it. If so, just slap me and please point me in the appropriate direction. >>>>> >>>>> I have just begun updating several of fxplugs from 1.2. Many of them are based on data encoded into the images. I understand that colorspaces are now used and I need to request linear color outputs. >>>>> >>>>> In properties I am returning "[NSNumber numberWithInteger:kFxImageColorInfo_RGB_LINEAR], kFxPropertyKey_DesiredProcessingColorInfo," in the dicitonary. >>>>> >>>>> When I query the output image for the color space it returns "kFxImageColorInfo_RGB_LINEAR". I understand this to map the image colors from 0.0 to 1.0. >>>>> (FxImage*)outputImage.colorInfo equals kFxImageColorInfo_RGB_LINEAR >>>>> >>>>> The issue occurs when rendering to the output image ( or read from the input image ). The following code outputs a much brighter luminance value than 0.5. >>>>> glClearColor( 0.5, 0.5, 0.5, 1.0 ); >>>>> glClear( GL_COLOR_BUFFER_BIT ); >>>>> >>>>> Is there somewhere else I need to request linear color? Am I not understanding linear color correctly? >>>>> >>>>> Regards, >>>>> David Patrick Farmer >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com >>>>> >>>>> This email sent to dcardani(a)apple.com >>>> >>> >>> David Patrick Farmer >>> >> > > David Patrick Farmer > _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Linear Color ( or not? )
by catchall＠davidpatrickfarmer.com 24 Aug '12

24 Aug '12

Sorry, I should have just come clean about what I am trying to do. I am porting a series of FxPlugs that need to decode data encoded in images. Those images could be rendered procedurally in an FxPlug or come from an external source. For instance, if I import an 8bit image that was created in PS and all pixels were set to 127,127,127 I would like the fragment shader to see 0.49803 are there abouts. The first FxPlug is stupid simple. It takes an input image and tries to decode it as vectors 0.0 == -1.0, 0.5 == 0.0, 1.0 = 1.0. When I think linear - 8bit 0-255 is 0.0-1.0 discarding any color profiles. On Aug 24, 2012, at 3:38 PM, Darrin Cardani wrote: > David, > > You shouldn't have to compensate for any gamma correction. I was just using that as an example to clarify how it works. Either your plug-in should work in linear, if that's appropriate, or it should work in gamma corrected space, if that's appropriate. It sounds like in your case, maybe working in a gamma-corrected space makes more sense. If that's the case, simply use the kFxImageColorInfo_RGB_GAMMA_VIDEO instead of kFxImageColorInfo_RGB_LINEAR in your -properties dictionary. > > As a rule of thumb - color correction filters usually need to work in gamma-corrected RGB, whereas anything simulating lighting or light-related effects needs to work in linear RGB. Another way to look at it: if your filter is based on how people perceive color, make it work in gamma-corrected space, whereas if it's based on physically simulating light, make it work in linear RGB. The host app will take care of converting it to the proper output space after you're done with it, you just need to tell us which space your code is working in. Does that make sense? > > In your example below, it's kind of hard to tell you what you should do because an RGB value of (0.5, 0.5, 0.5) is meaningless without knowing the color space. So when you say "I need an input image that was rendered 0.5, 0.5, 0.5 to evaluate to 0.5, 0.5, 0.5 in a fragment shader," you need to say in what space the rendered 0.5, 0.5, 0.5 is. If you mean that when it is displayed that a tool like Pixie shows an on-screen value of 0.5, 0.5, 0.5, then your input is in gamma-corrected RGB. But if it's an OpenEXR that has linear RGB in it, then a value of 0.5, 0.5, 0.5 will mean something different. What are your inputs? HD Video? How are you getting the "0.5, 0.5, 0.5"? From Motion's color display in the canvas? If so, that's gamma-corrected. > > Darrin > > On Aug 24, 2012, at 1:26 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: > >> >> Hmm. It isn't really linear output then right? The outputimage says it is in linear color space. How would I know what gamma to compensate for? Seems like there could be custom gamma curves for each channel in some cases? >> >> I digress, the real issue is that I need an input image that was render 0.5,0.5,0.5 to evaluate to 0.5,0.5,0.5 in a fragment shader. Right now it does not seem that the input image is transformed to linear space. >> >> Appreciate the patience. >> >> >> On Aug 24, 2012, at 3:16 PM, Darrin Cardani wrote: >> >>> David, >>> >>> It sounds like you get the basic concept. You are correct that you need to include that value in your properties dictionary to get inputs that are linear and to output your results in linear RGB. >>> >>> What's not so obvious is that if you output (0.5, 0.5, 0.5, 1.0) in linear RGBA, a couple of things happen. Before displaying your output to the screen or exporting it to a file, we need to convert it from linear to gamma-corrected RGB as a final step. The gamma-corrected value of linear 0.5 will be about 0.72. (That's 0.5 ^ (1.0 / 2.2).) This works as expected, but can be confusing. If you want the gamma-corrected result to be 0.5 (and for it to look like "middle gray") you need to use (0.21, 0.21, 0.21, 1.0) for your RGBA value in linear RGB. >>> >>> If you've ever heard of "18% gray" being middle gray, that's in linear RGB. As you can see, 0.21 is just a little more than 0.18, so they're pretty close. >>> >>> Darrin >>> >>> On Aug 24, 2012, at 12:44 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: >>> >>>> Hi all, >>>> >>>> I apologize if the following has been addressed and I missed it. If so, just slap me and please point me in the appropriate direction. >>>> >>>> I have just begun updating several of fxplugs from 1.2. Many of them are based on data encoded into the images. I understand that colorspaces are now used and I need to request linear color outputs. >>>> >>>> In properties I am returning "[NSNumber numberWithInteger:kFxImageColorInfo_RGB_LINEAR], kFxPropertyKey_DesiredProcessingColorInfo," in the dicitonary. >>>> >>>> When I query the output image for the color space it returns "kFxImageColorInfo_RGB_LINEAR". I understand this to map the image colors from 0.0 to 1.0. >>>> (FxImage*)outputImage.colorInfo equals kFxImageColorInfo_RGB_LINEAR >>>> >>>> The issue occurs when rendering to the output image ( or read from the input image ). The following code outputs a much brighter luminance value than 0.5. >>>> glClearColor( 0.5, 0.5, 0.5, 1.0 ); >>>> glClear( GL_COLOR_BUFFER_BIT ); >>>> >>>> Is there somewhere else I need to request linear color? Am I not understanding linear color correctly? >>>> >>>> Regards, >>>> David Patrick Farmer >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com >>>> >>>> This email sent to dcardani(a)apple.com >>> >> >> David Patrick Farmer >> > David Patrick Farmer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Linear Color ( or not? )
by Darrin Cardani 24 Aug '12

24 Aug '12

David, You shouldn't have to compensate for any gamma correction. I was just using that as an example to clarify how it works. Either your plug-in should work in linear, if that's appropriate, or it should work in gamma corrected space, if that's appropriate. It sounds like in your case, maybe working in a gamma-corrected space makes more sense. If that's the case, simply use the kFxImageColorInfo_RGB_GAMMA_VIDEO instead of kFxImageColorInfo_RGB_LINEAR in your -properties dictionary. As a rule of thumb - color correction filters usually need to work in gamma-corrected RGB, whereas anything simulating lighting or light-related effects needs to work in linear RGB. Another way to look at it: if your filter is based on how people perceive color, make it work in gamma-corrected space, whereas if it's based on physically simulating light, make it work in linear RGB. The host app will take care of converting it to the proper output space after you're done with it, you just need to tell us which space your code is working in. Does that make sense? In your example below, it's kind of hard to tell you what you should do because an RGB value of (0.5, 0.5, 0.5) is meaningless without knowing the color space. So when you say "I need an input image that was rendered 0.5, 0.5, 0.5 to evaluate to 0.5, 0.5, 0.5 in a fragment shader," you need to say in what space the rendered 0.5, 0.5, 0.5 is. If you mean that when it is displayed that a tool like Pixie shows an on-screen value of 0.5, 0.5, 0.5, then your input is in gamma-corrected RGB. But if it's an OpenEXR that has linear RGB in it, then a value of 0.5, 0.5, 0.5 will mean something different. What are your inputs? HD Video? How are you getting the "0.5, 0.5, 0.5"? From Motion's color display in the canvas? If so, that's gamma-corrected. Darrin On Aug 24, 2012, at 1:26 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: > > Hmm. It isn't really linear output then right? The outputimage says it is in linear color space. How would I know what gamma to compensate for? Seems like there could be custom gamma curves for each channel in some cases? > > I digress, the real issue is that I need an input image that was render 0.5,0.5,0.5 to evaluate to 0.5,0.5,0.5 in a fragment shader. Right now it does not seem that the input image is transformed to linear space. > > Appreciate the patience. > > > On Aug 24, 2012, at 3:16 PM, Darrin Cardani wrote: > >> David, >> >> It sounds like you get the basic concept. You are correct that you need to include that value in your properties dictionary to get inputs that are linear and to output your results in linear RGB. >> >> What's not so obvious is that if you output (0.5, 0.5, 0.5, 1.0) in linear RGBA, a couple of things happen. Before displaying your output to the screen or exporting it to a file, we need to convert it from linear to gamma-corrected RGB as a final step. The gamma-corrected value of linear 0.5 will be about 0.72. (That's 0.5 ^ (1.0 / 2.2).) This works as expected, but can be confusing. If you want the gamma-corrected result to be 0.5 (and for it to look like "middle gray") you need to use (0.21, 0.21, 0.21, 1.0) for your RGBA value in linear RGB. >> >> If you've ever heard of "18% gray" being middle gray, that's in linear RGB. As you can see, 0.21 is just a little more than 0.18, so they're pretty close. >> >> Darrin >> >> On Aug 24, 2012, at 12:44 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: >> >>> Hi all, >>> >>> I apologize if the following has been addressed and I missed it. If so, just slap me and please point me in the appropriate direction. >>> >>> I have just begun updating several of fxplugs from 1.2. Many of them are based on data encoded into the images. I understand that colorspaces are now used and I need to request linear color outputs. >>> >>> In properties I am returning "[NSNumber numberWithInteger:kFxImageColorInfo_RGB_LINEAR], kFxPropertyKey_DesiredProcessingColorInfo," in the dicitonary. >>> >>> When I query the output image for the color space it returns "kFxImageColorInfo_RGB_LINEAR". I understand this to map the image colors from 0.0 to 1.0. >>> (FxImage*)outputImage.colorInfo equals kFxImageColorInfo_RGB_LINEAR >>> >>> The issue occurs when rendering to the output image ( or read from the input image ). The following code outputs a much brighter luminance value than 0.5. >>> glClearColor( 0.5, 0.5, 0.5, 1.0 ); >>> glClear( GL_COLOR_BUFFER_BIT ); >>> >>> Is there somewhere else I need to request linear color? Am I not understanding linear color correctly? >>> >>> Regards, >>> David Patrick Farmer >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com >>> >>> This email sent to dcardani(a)apple.com >> > > David Patrick Farmer > _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Linear Color ( or not? )
by catchall＠davidpatrickfarmer.com 24 Aug '12

24 Aug '12

Hmm. It isn't really linear output then right? The outputimage says it is in linear color space. How would I know what gamma to compensate for? Seems like there could be custom gamma curves for each channel in some cases? I digress, the real issue is that I need an input image that was render 0.5,0.5,0.5 to evaluate to 0.5,0.5,0.5 in a fragment shader. Right now it does not seem that the input image is transformed to linear space. Appreciate the patience. On Aug 24, 2012, at 3:16 PM, Darrin Cardani wrote: > David, > > It sounds like you get the basic concept. You are correct that you need to include that value in your properties dictionary to get inputs that are linear and to output your results in linear RGB. > > What's not so obvious is that if you output (0.5, 0.5, 0.5, 1.0) in linear RGBA, a couple of things happen. Before displaying your output to the screen or exporting it to a file, we need to convert it from linear to gamma-corrected RGB as a final step. The gamma-corrected value of linear 0.5 will be about 0.72. (That's 0.5 ^ (1.0 / 2.2).) This works as expected, but can be confusing. If you want the gamma-corrected result to be 0.5 (and for it to look like "middle gray") you need to use (0.21, 0.21, 0.21, 1.0) for your RGBA value in linear RGB. > > If you've ever heard of "18% gray" being middle gray, that's in linear RGB. As you can see, 0.21 is just a little more than 0.18, so they're pretty close. > > Darrin > > On Aug 24, 2012, at 12:44 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: > >> Hi all, >> >> I apologize if the following has been addressed and I missed it. If so, just slap me and please point me in the appropriate direction. >> >> I have just begun updating several of fxplugs from 1.2. Many of them are based on data encoded into the images. I understand that colorspaces are now used and I need to request linear color outputs. >> >> In properties I am returning "[NSNumber numberWithInteger:kFxImageColorInfo_RGB_LINEAR], kFxPropertyKey_DesiredProcessingColorInfo," in the dicitonary. >> >> When I query the output image for the color space it returns "kFxImageColorInfo_RGB_LINEAR". I understand this to map the image colors from 0.0 to 1.0. >> (FxImage*)outputImage.colorInfo equals kFxImageColorInfo_RGB_LINEAR >> >> The issue occurs when rendering to the output image ( or read from the input image ). The following code outputs a much brighter luminance value than 0.5. >> glClearColor( 0.5, 0.5, 0.5, 1.0 ); >> glClear( GL_COLOR_BUFFER_BIT ); >> >> Is there somewhere else I need to request linear color? Am I not understanding linear color correctly? >> >> Regards, >> David Patrick Farmer >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com >> >> This email sent to dcardani(a)apple.com > David Patrick Farmer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Linear Color ( or not? )
by Darrin Cardani 24 Aug '12

24 Aug '12

David, It sounds like you get the basic concept. You are correct that you need to include that value in your properties dictionary to get inputs that are linear and to output your results in linear RGB. What's not so obvious is that if you output (0.5, 0.5, 0.5, 1.0) in linear RGBA, a couple of things happen. Before displaying your output to the screen or exporting it to a file, we need to convert it from linear to gamma-corrected RGB as a final step. The gamma-corrected value of linear 0.5 will be about 0.72. (That's 0.5 ^ (1.0 / 2.2).) This works as expected, but can be confusing. If you want the gamma-corrected result to be 0.5 (and for it to look like "middle gray") you need to use (0.21, 0.21, 0.21, 1.0) for your RGBA value in linear RGB. If you've ever heard of "18% gray" being middle gray, that's in linear RGB. As you can see, 0.21 is just a little more than 0.18, so they're pretty close. Darrin On Aug 24, 2012, at 12:44 PM, "catchall(a)davidpatrickfarmer.com" <catchall(a)davidpatrickfarmer.com> wrote: > Hi all, > > I apologize if the following has been addressed and I missed it. If so, just slap me and please point me in the appropriate direction. > > I have just begun updating several of fxplugs from 1.2. Many of them are based on data encoded into the images. I understand that colorspaces are now used and I need to request linear color outputs. > > In properties I am returning "[NSNumber numberWithInteger:kFxImageColorInfo_RGB_LINEAR], kFxPropertyKey_DesiredProcessingColorInfo," in the dicitonary. > > When I query the output image for the color space it returns "kFxImageColorInfo_RGB_LINEAR". I understand this to map the image colors from 0.0 to 1.0. > (FxImage*)outputImage.colorInfo equals kFxImageColorInfo_RGB_LINEAR > > The issue occurs when rendering to the output image ( or read from the input image ). The following code outputs a much brighter luminance value than 0.5. > glClearColor( 0.5, 0.5, 0.5, 1.0 ); > glClear( GL_COLOR_BUFFER_BIT ); > > Is there somewhere else I need to request linear color? Am I not understanding linear color correctly? > > Regards, > David Patrick Farmer > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com > > This email sent to dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Linear Color ( or not? )
by catchall＠davidpatrickfarmer.com 24 Aug '12

24 Aug '12

Hi all, I apologize if the following has been addressed and I missed it. If so, just slap me and please point me in the appropriate direction. I have just begun updating several of fxplugs from 1.2. Many of them are based on data encoded into the images. I understand that colorspaces are now used and I need to request linear color outputs. In properties I am returning "[NSNumber numberWithInteger:kFxImageColorInfo_RGB_LINEAR], kFxPropertyKey_DesiredProcessingColorInfo," in the dicitonary. When I query the output image for the color space it returns "kFxImageColorInfo_RGB_LINEAR". I understand this to map the image colors from 0.0 to 1.0. (FxImage*)outputImage.colorInfo equals kFxImageColorInfo_RGB_LINEAR The issue occurs when rendering to the output image ( or read from the input image ). The following code outputs a much brighter luminance value than 0.5. glClearColor( 0.5, 0.5, 0.5, 1.0 ); glClear( GL_COLOR_BUFFER_BIT ); Is there somewhere else I need to request linear color? Am I not understanding linear color correctly? Regards, David Patrick Farmer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: fcpxml bug - breaking apart clip items
by Thomas - Mindtransplant 22 Aug '12

22 Aug '12

Hi Rainer, thanks for your reply. I filed a bug (#12151320) for both issues. Thomas. MINDTRANSPLANT Audio & Video Produktion www.mindtransplant.com clipexporter.mindtransplant.com Am 21.08.2012 um 23:03 schrieb Rainer Standke: > Hello Thomas, > > > On Aug 21, 2012, at 12:57, Thomas - Mindtransplant <thomas(a)mindtransplant.com> wrote: > >> Hi, >> >> there is a strange behavior that I´m not sure if it is intended or not. It would be nice if a Apple employee could provide some feedback: >> >> When I use the right-click command "Break Apart Clip Items" on a video clip (not a compound clip) the <video> Node loses it´s <clip> parent Node. >> For example, this: >> <clip> >> <video> >> <audio/> >> </video> >> </clip> >> >> Turns into this: >> <video> >> <audio lane="-1"/> >> </video> >> >> >> The video node inherits the attributes from it´s previously deleted parent clip node and the audio node get attached to the video node. Now, if I delete the audio item in FCP X and select the video item and choose "New Compound Clip" it behaves as expected and creates a compound clip. The fcpxml equivalent now looks like this: >> <clip> >> <video/> >> </clip> >> >> >> In FCP X I double click the newly created compound clip and take a look inside. Now I duplicate the video item inside the compound clip by holding alt and dragging it up to the 1st lane. If I leave the compound clip content view and return to the main timeline, the clip is no more a compound clip and I´m not able to view it´s contents. The fcpxml look like this: >> <clip> >> <video> >> < video/> >> </video> >> </clip> >> >> >> My questions are: >> 1.) Is it a bug or is it intended that the parent clip node is deleted when using "Break Apart Clip Items" on a video clip? Since this behavior only occurs when breaking apart clip items I assume it´s a bug. This does not occur when appending or inserting video-only media from the Event Browser! > > This seems to be no bug in the sense that Apple has recognized it as such. As a matter of fact, in my opinion, this is a bug in the sense that the same node (<video>) can have two different meanings, i.e. <video>, as in: video inside a clip, as well as <clip>, as in: it carries the relevant timing info. In my opinion this needlessly complicates parsing, and thus is also a dangerous thing. You might want to file a bug. > > > >> 2.) If this behavoir is intended how do I differentiate a <video> node that is inside a compound clip and one that is inserted from the Event Browser? Both cases have the same xml structure. This differentiation is important to my app since it decides whether to create a comp layer in After Effects or not. > > I guess you'll have to look at the XML structure several levels deep. It may suffice to check if your video node has a clip ancestor that itself has a clip ancestor. > > > >> 3.) I assume that not being able to open the compound clip (as mentioned in the last part) is a bug, right? > > That looks a lot like a bug to, although I haven't tried it myself. You should file a bug about that. > > Hope this helps, > > Rainer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0