I will grant you that QC ought to have a QCPluginPixelFormat that is half
float 16 bit which would allow some nicer handling of other formats. Part of
the issue is that not all GPUs supported it earlier in QCs life time, but it
tends to have better hardware filtering support compared to straight 32 bit
float textures. Combine that with the fact that 3rd party plugins can only
support a limited subset of what QC can natively support, you can get into
situations where you go from a higher fidelity image in to a lower out (like a
16 bit per channel CI Image to an 8 bit per channel gl texture, if you say, use
a 3rd party blur filter that is not a CI Filter*
My understanding of how this works is that:
*QC internally has support for a variety of image types and pixel
formats (8 bpc, 16, 32 etc) and other types of images that proper public API
does not
*3rd party plugins that process images using the QCInputImageProvider
and OutputProvider have to use the provided QCPluginPixelFormats, which are 32
bit ARGB/BGRA, 8 bit ARGB or BGRA, then I8 and F8 formats,
*3rd party plugins only can support textures and pixel buffers, they
cant really output CVImageBuffers, CGImageRefs and the like from an output
image port.
*Core image filters will retain the precision of the input image. This
QC can say take in an image on a published image input port that is 16 bits per
channel, run a CI Filter on it, and render that into a 16 bits per pixel
rendering destination, without fidelity loss. This is due to QC using those
internal wrappers that support more image types and precision.
* If you do the above, but for example throw in a v002 Blur on the
input image, since it is a QC Plugin, and not a CI FIlter, you will lose
precision.
Granted, this is nuanced, but I think is an accurate enough description
of what is going on internally.
I would love to hear otherwise.
* for example, the v002 Blurs only output 8 bit RGBA images (or BGRA but...),
because 32 bit textures dont support linear filtering, and I cannot output a 16
bit pixel format.
On Dec 21, 2010, at 5:35 PM, George Toledo wrote:
> ...but what happens when I run an image codec that has higher bit value than
> the core image chain or QC can handle? I'm not aware of documentation of
> "what's going on" in that scenario.
>
> -GT
>
> On Tue, Dec 21, 2010 at 5:31 PM, vade <[email protected]> wrote:
> Its really not that nuts once you take some things into account.
>
> The only gotcha in this is that Final Cut Pro calibrates to a predetermined
> video gamma uses some standards based on whether or not you are running in SD
> or HD. HD sources use the 709 color correction values, SD use 601. This is
> because FCP is meant for pro output on calibrated monitors and for use with
> video output boards for playout and record (to honest to goodness video, not
> computer monitors).
>
> Quicktime and other apps calibrate to your display, which is the normal
> computer output and expects different gamma and color responses than video.
> Thus the optional pref in Quicktime to treat movies like FCP does, if thats
> something you want to deal with.
>
> Apps like AE and Photoshop have color management workflows that you can
> optionally enable, which take their best guess as to the source of a video or
> file, and the destination colorspace you work in. Core Image and Quicktime
> have similar input, working and output colorspace keys you can set to ensure
> that you get what you want.
>
> This is not to say its not nuanced and tricky, and rife with possible
> got-chas, but that its not really "nuts".
>
>
> On Dec 21, 2010, at 5:10 PM, George Toledo wrote:
>
>>
>>
>> On Tue, Dec 21, 2010 at 4:34 PM, Jason Belec <[email protected]> wrote:
>> You can also work the default QC output to match (closely) and apply that
>> to everything coming in. Ran into this in the past myself.
>>
>>
>>
>> What would be imminently useful is solid, factual, info from Apple about how
>> to work around the color issue correctly (if this is *even possible*),
>> instead of "fudge it til it looks right", or "buy product X".
>>
>> Colorspace issues, Quicktime, CI problems, etc., in OS X is totally nuts,
>> and it needs to be resolved.
>>
>> -GT
>>
>> On 2010-12-21, at 4:52 PM, vade <[email protected]> wrote:
>>
>>> FCP does not use ColorSync to display video, it has its own color
>>> correction and gamma correction routines depending if you are running 601
>>> or 709 formatted video. Quartz Composer, Quicktime and most other apps use
>>> ColorSync.
>>>
>>> If you have QT 7 installed on your system FCP installs a separate
>>> preference called Final Cut Studio Color Compatibility in to the QT prefs.
>>> Enable it, and Quicktime now uses the same color lookup as Final Cut Pro
>>> does. Open your comp, it should, hopefully, look the same.
>>>
>>> But this is almost certainly a color conversion routine.
>>>
>>>
>>> On Dec 21, 2010, at 1:32 PM, Patrick Sheffield wrote:
>>>
>>>> The original image came from a BetaSP tape, but it doesn't matter - I see
>>>> the same difference in all material.
>>>>
>>>> I didn't include a composition as all I'm doing is taking an input image
>>>> and the Screen blend node and running it into both inputs, then the result
>>>> to a billboard. If I do the same thing in FCP/Motion (place an image on
>>>> V1/V2 with V2 set to Screen composite mode), the result is considerably
>>>> different. I don't think Quartz is doing it wrong, I just need to figure
>>>> out what FCP/Motion are actually doing...
>>>>
>>>> regards,
>>>>
>>>> Patrick
>>>>
>>>> On Dec 21, 2010, at 10:16 AM, George Toledo wrote:
>>>>
>>>>> No composition?
>>>>>
>>>>> This makes it hard to discern.
>>>>>
>>>>> Try using Billboard, and adjusting native core image in settings, to see
>>>>> if that makes a difference.
>>>>>
>>>>> Where are these images coming from? They both have edge crud... is this
>>>>> from the screengrab? It looks like a gamma difference (but maybe not). Is
>>>>> that happening because the FCP image is coming from something that is
>>>>> already run through a codec?
>>>>>
>>>>> -GT
>>>>>
>>>>> On Tue, Dec 21, 2010 at 1:08 PM, Patrick Sheffield
>>>>> <[email protected]> wrote:
>>>>>
>>>>> ...between how Quartz Composer processes the Screen blend mode and how
>>>>> Final Cut Pro and Motion do it?
>>>>>
>>>>> This is an image screened over itself in Final Cut Pro/Motion:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> And in Quartz Composer:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> In Quartz Composer it's flatter and considerably more red than FCP.
>>>>>
>>>>> If I perform a Screen Blend (the inverse of the multiplication of the
>>>>> inverse), I get the same result as Quartz, but I need to figure out what
>>>>> FCP/Motion are doing differently.
>>>>>
>>>>> Does anyone have any insight?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Patrick Sheffield
>>>>> Sheffield Softworks
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Quartzcomposer-dev mailing list ([email protected])
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com
>>>>>
>>>>> This email sent to [email protected]
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> George Toledo
>>>>> [email protected]
>>>>> www.georgetoledo.com
>>>>>
>>>>> The information contained in this E-mail and any attachments may be
>>>>> confidential.
>>>>> If you have received this E-mail in error, please notify us immediately
>>>>> by telephone or return E-mail.
>>>>> You should not use or disclose the contents of this E-mail or any of the
>>>>> attachments for any purpose or to any persons.
>>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Quartzcomposer-dev mailing list ([email protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
>>>>
>>>> This email sent to [email protected]
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Quartzcomposer-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/quartzcomposer-dev/jasonbelec%40rogers.com
>>>
>>> This email sent to [email protected]
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Quartzcomposer-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com
>>
>> This email sent to [email protected]
>>
>>
>>
>> --
>> George Toledo
>> [email protected]
>> www.georgetoledo.com
>>
>> The information contained in this E-mail and any attachments may be
>> confidential.
>> If you have received this E-mail in error, please notify us immediately by
>> telephone or return E-mail.
>> You should not use or disclose the contents of this E-mail or any of the
>> attachments for any purpose or to any persons.
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Quartzcomposer-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
>>
>> This email sent to [email protected]
>
>
>
>
> --
> George Toledo
> [email protected]
> www.georgetoledo.com
>
> The information contained in this E-mail and any attachments may be
> confidential.
> If you have received this E-mail in error, please notify us immediately by
> telephone or return E-mail.
> You should not use or disclose the contents of this E-mail or any of the
> attachments for any purpose or to any persons.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
