• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [inputImage origin] incorrect for .moef?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [inputImage origin] incorrect for .moef?


  • Subject: Re: [inputImage origin] incorrect for .moef?
  • From: Darrin Cardani <email@hidden>
  • Date: Wed, 30 Nov 2011 13:34:31 -0800

Paul,
	This seems familiar to me. I think this is something I worked on recently, and I believe will be fixed in a future release. If you could send me a sample plugin – it can just print to the console, doesn't need to do much of anything – I can figure out if it's been fixed, or if we need to do additional work on it.

Thanks,
Darrin

On Nov 30, 2011, at 10:50 AM, Paul Young wrote:

> I'm trying to make sense of an apparent upside-down buffer issue in an
> FxPlug2 plugin I'm developing.
>
> I'm of course still looking for things I may be doing wrong on my end,
> but here's what I think I'm seeing:
>
> In Motion 5 (5.0.1), when my renderOutput: method is called, the
> inputImage & outputImage return 0 (kFxImageOrigin_BOTTOM_LEFT) for
> origin and the first row of pixels, upon inspection, is indeed the
> bottom row of the image.
>
> In FCPX (10.0.2), using a .moef for the same plugin, when my
> renderOutput: method is called, the inputImage & outputImage return 0
> (kFxImageOrigin_BOTTOM_LEFT) for origin but the first row of pixels,
> upon inspection, is the TOP row of the image.
>
> (The same is true for FxImageInfo.origin in the various places I've checked it.)
>
> In both cases, FxHostCapabilities indicates that Motion is the host.
> (I guess this almost makes sense in this .moef model... but it's a bit
> of a head scratcher... might rather have "Motion-Inside-FCPX")
>
> This is software-only rendering (32-bit float bitmaps). I've confirmed
> that I can create new bitmaps stamped as kFxImageOrigin_TOP_LEFT.
>
> There's plenty of mention in the docs about FCP buffers being top
> down, but perhaps they're getting stamped incorrectly on their way
> through the Motion rendering engine?
>
> Has anyone else seen this? Any ideas on how to work around it?
> (Including a reliable way to detect that FCPX is the host? Not ideal
> but workable in the short term.)
>
> Many thanks,
>
> paul
> _______________________________________________
> 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

  • Follow-Ups:
    • Re: [inputImage origin] incorrect for .moef?
      • From: Paul Schneider <email@hidden>
References: 
 >[inputImage origin] incorrect for .moef? (From: Paul Young <email@hidden>)

  • Prev by Date: [inputImage origin] incorrect for .moef?
  • Next by Date: Re: [inputImage origin] incorrect for .moef?
  • Previous by thread: [inputImage origin] incorrect for .moef?
  • Next by thread: Re: [inputImage origin] incorrect for .moef?
  • Index(es):
    • Date
    • Thread