Hmm, I'll have to make a demo, but I seem to be able to get image info to CI or QCplugins in a way that totally borks the output, in a couple of scenarios. With multiple types of image sources, that I was associating as all being high res scenarios, I can make a CI image start flip flopping wildly, aside from something preferable like decimation of bit value. I have some workarounds, but this is getting OT, so I guess I'll just make samples and file bugs.
-GT On Tue, Dec 21, 2010 at 5:48 PM, Christopher Wright < christopher_wri...@apple.com> 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. > > > You can't (realistically) have a codec with more precision than CoreImage. > CI internally uses 128 bit pixels (32 bits of each component, floating > point), which is about as good as it gets (10-bit codecs and _maybe_ 12 bit > codecs are high-end). I suppose you could have 32 bit integer components > (floating point wins on dynamic range, but not monotonic range like ints > do), or 64 bit components, but virtually nothing will deal with that anyway. > > QC will use whatever GL allows -- in the editor, this is generally 32 bit > pixels (8 bits per component), but externally it can be deeper (With native > Core Image Rendering enabled on billboards, you should get CI's full > precision in the output if the destination can accept it). > > Color conversion is a more subtle topic -- there are 601 and 709 matrices > (that vade's alluded to) for YCbCr -> RGB and back, but there are also > RGB->RGB conversions when tristimulus values change, or gamuts change, or > when the source changes. This gets complicated more quickly than one might > thing. > > Years ago, color conversions were avoided because they were expensive. > They're still expensive, but now they're avoided because everyone needs to > be a good citizen, and the longer the processing pipeline gets, the more > unlikely it is that everyone does the right thing. > > When a source provides more data than QC can deal with (e.g., a floating > point image via OpenEXR or TIFF or something), it simply discards the low > bits. That's unrelated to color correction proper, but it can lead to > subtle shifts if other pieces of the pipeline are deeper. There's really > nothing QC can do to preserve this data; an 8 bit output context can only > store 8 bits. > > -- > Christopher Wright > christopher_wri...@apple.com > > > > -- George Toledo gtole...@gmail.com 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 (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
