Re: TIFFRepresentation, different TIFF format under Snow Leopard
Re: TIFFRepresentation, different TIFF format under Snow Leopard
- Subject: Re: TIFFRepresentation, different TIFF format under Snow Leopard
- From: Sandy McGuffog <email@hidden>
- Date: Tue, 13 Oct 2009 17:52:26 +0200
Ken,
Just for clarity here, my problem, although not the original poster's,
is not around internal representation - I'm happy with with whatever
comes along in that regard. My problem is that if you want to write
out a Core Image rep as TIFF, there is no obvious way to specify that
you want the written representation to be RGB, not RGBA. Maybe there
is a way, but I couldn't find it.
Sandy
On Oct 13, 2009, at 5:33 PM, Ken Ferry wrote:
On Tue, Oct 13, 2009 at 12:39 AM, Paul M <email@hidden> wrote:
Note especially this quote:
"Adobe supports TIFF issues that directly relate to Adobe products.
If a
TIFF file is incompatible with an Adobe product ... our goal is to
isolate
and understand the problem so that it may be corrected in future
releases"
Taken from this page:
http://kb2.adobe.com/cps/000/13da4f4.html
This hedge is probably in there because TIFF is designed to allow
random extensions. There's no hope of supporting anything anyone
could possibly put in a TIFF file.
However, hopefully a program won't put semantically necessary data
in private extensions unless the files aren't supposed to escape
management by that program.
That an Adobe product is so "Crappy" in this regard is surprising.
I'm not
100% cretain, but I was under the impression that Adobe owns the
Intelectual
Property that is the TIFF standard. They certainly support and
foster it
to a high degree.
I agree. Of course one should file a bug with Adobe, but I would be
inclined to think that this problem was misdiagnosed. Lightroom
really ought to be able to read TIFF files with an alpha channel.
If there is indeed no api to do this, It would be reasonable to
expect that the output format may be determined by the data comming
in (to the image IO subsystem). If CoreImage is associating an alpha
channel with the image, then try looking at CoreImage to either not
add the alpha, or else to remove it prior to exporting your image.
If you cannot do this with CoreImage, try looking at NSImage or
other imaging components (Ken suggested CGImageDestination) to see
if the alpha can be removed prior to writing it to disk. (Basicly,
if you cant tell it not to write the alpha, try removing the alpha
then write it out - then file an enhancement request!).
ImageIO (i.e. CGImageDestination) is the reading and writing
framework used by everything else. Please do file a bug, but
please do understand: The contract today is that ImageIO makes no
promises about the relation between in-memory pixel format and on-
disk format on either reading or writing. You need to code such
that you don't depend on it, as discussed earlier in this thread.
In particular, there has been talk of unilaterally standardizing
everything to ARGB when it's read in to simplify CoreGraphics and
avoid future conversions.
-Ken
Cocoa Frameworks
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden