On Mon, Oct 12, 2009 at 11:48 AM, Sander Stoks <[email protected]> wrote:
> I have a related question. The various image file formats have their own > options and settings (compression levels, color space, interlacing, etc.); > is there a generic way to access these from within my application? > > For those who still remember BeOS (where the grass was green and the girls > were pretty), there was a concept called "Translators" (which BeOS, in turn, > borrowed from the Amiga). Each Translator was basically an Image I/O codec, > but you could also query them for a "configuration view" which you could > simply show in your own application. That way, the app doesn't have to know > the ins and outs of all the file formats. > > Does something like this exist on MacOS or do I have to create these > settings views myself? > Yes, though I'm sure it isn't precisely the same. Take a look at IKSaveOptions. Ken Ferry Cocoa Frameworks > > Regards, > Sander > > > 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 >> >> >> 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 ? >>>> >>> >>> >>> 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/kenferry%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]
