On 13/10/2009, at 7:07 PM, Sandy McGuffog wrote:
Well, that I think depends on your definition of "crappy software". :)
I think if it fails to function according to published guidelines,
makes wrong
assumptions instead of performing a very simple test, and consequenty
fails to
read a valid file format ... that's pretty crappy.
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.
Adobe should know better.
As I said above, the test is very simple. It doesn't have to read the
4th
channel if it doesn't want to, but there is no excuse for not reading
the
3 channels it does want.
This kind of software really annoys me because it just causes problems
and people end up blaming those problems on perfectly correct software,
in this case Apple. It's all the worse when there really is no excuse
for
writing such poor software. Doing it properly really isn't hard and
doesn't have any significant drawbacks.
Crappy really is a very good description as far as I'm concerned.
But on to more practical matters -
I would expect that when writing a tiff file, there should be a
mechanism
to control the output format. If there isn't, that would certainly
warrant
a feature request. https://bugreport.apple.com
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!).
paulm
Footnote:
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.
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
One other possibility is that the image in question is corrupt in some
way.
If you want to send me a sample image (preferably not too big) off list,
I can verify this.
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 <peterchan...@gmail.com>
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 (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
