Well, that I think depends on your definition of "crappy software". :)
The practical issue for me is that that Adobe Lightroom (at least on
the PC) won't read an RGBA TIFF file, and if one of Adobe's premier
packages won't read the file, then the current Apple implementation of
the TIFF writer is, practically speaking, useless to me.
Sandy
On Oct 12, 2009, at 11:24 PM, Paul M wrote:
On 13/10/2009, at 4:39 AM, Sandy McGuffog wrote:
Actually, that occurred under 10.5 as well - what happens is that
some operations, it would seem those involving Core Image, cause
the internal representation to go to RGBA. Which is fine, but there
doesn't seem to be a way to write a plain RGB format TIFF. I had to
incorporate a third-party TIFF module to do that, as RGBA TIFF
files aren't very compatible with anything other than Apple.
Sandy
I think what you mean to say is "RGBA TIFF files aren't very
compatible with
crappy software".
A tiff file has tags in the header identifying the number of colour
planes
and their arangement within the file. Any half decent tiff importer
will
simply skip the alpha channel, if it has no use for it, and only
read the RGB
data.
On Oct 12, 2009, at 5:07 PM, Ken Ferry wrote:
On Mon, Oct 12, 2009 at 4:36 AM, Peter C <[email protected]>
wrote:
I just stumble into a feature (or a bug ?), NSImage
TIFFRepresentation
produce RGB TIFF with a layer (when open under Photoshop).
Previously it
produce plain RGB TIFF under OS 10.5 and below. This cause some
part of my
programs interpret wrong RGB data, expecting 3 bytes instead of 4
bytes for
a RGB pixel. There is no mention in the documents about this
"feature".
Is there a way to restore the previous behavior of
TIFFRepresentation ?
There's 2 ways to solve your problem.
1) Use Cocoa APIs to specify 3-plane RGB image output (I'm sorry I
have no
further information here).
2) Throw away your crappy tiff readers and get something better.
paulm
You can look at CGImageDestination to get more options, but I
don't think
there's anything that provides control at that level.
In many cases there _must_ be data munging between the in memory
pixel
format and the on-disk file format. The precise munging is not
defined on
either input or output.
That is, don't make pixel format assumptions. The AppKit release
notes<http://developer.apple.com/mac/library/releasenotes/Cocoa/AppKit.html
>discuss
how to avoid making pixel format assumptions in the section
"NSBitmapImageRep: CoreGraphics impedence matching and performance
notes".
-Ken
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com
This email sent to [email protected]
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
