Re: NSImageRGBColorTable crash
Re: NSImageRGBColorTable crash
- Subject: Re: NSImageRGBColorTable crash
- From: Craig Hockenberry <email@hidden>
- Date: Mon, 26 Apr 2004 11:34:16 -0700
>
At 5:50 AM +0200 4/20/04, David Remahl wrote:
>
> On 20 apr 2004, at 05.26, Glenn Andreas wrote:
>
>> So I tried changing it to skip the CLUT, and take the NSData it
>
>> produces, and recreate the image and dump the clut from there.
>
>> Turns out it appears that "packed RGB" is actually suppose to mean
>
>> "packed ARGB" (or maybe RGBA), because if I do:
>
>>
>
>> python -c 'f=open("/tmp/clut","w");
>
>> f.write("\xff\xff\xff\xff"*256); f.close()'
>
>>
>
>> it seems to work.
>
>
>
> Oh, interresting...
>
>
>
> I was pretty certain the file should be RGB, 8 bit / component,
>
> because I found an old release note with the following text:
>
>
>
> http://www.geminisolutions.com/WebObjects_4.5/Documentation/Developer/YellowB
>
> ox/ReleaseNotes/AppKit.html
>
>
>
> "NSImageRGBColorTable: -- For GIF input and output. It consists of
>
> a 768 byte NSData object that contains a packed RGB table with each
>
> component being 8 bits."
>
>
Especially since that's matches how an 8 bit color table is specified
>
on a GIF file.
>
>
> Using a 1024 byte color table, I avoid the crash, but the image
>
> creation failes and I get the following on the console:
>
>
>
> 2004-04-20 05:41:58.734 App[12837] Unknown GIF label (0x00)
>
> 2004-04-20 05:41:58.736 App[12837] Inconsistent set of values to
>
> create NSBitmapImageRep
>
>
>
> Sigh...
>
>
I guess make a GIF without the explicit color table, extract it,
>
write it to a file, and use that file as the source for the explicit
>
color table the second time through. If you can't "round trip" the
>
color table, then it is definitely a bug. I'd say that at the very
>
least there's a bug in the documentation.
>
>
It might be interesting to see what sort of GIF file it actually
>
produces with the 1024 byte explicit clut as well (for example, can
>
you open it with photoshop?)
It appears that NSGIFImageWriter expects an NSData object that's 768 bytes
long when NSImageDitherTransparency is set to NO. When
NSImageDitherTransparency is set to YES, the length of the data object needs
to be 3 bytes less -- presumably so that there's room for the transparent
pixel in the color table.
So it's a documentation problem -- not a problem with the frameworks.
-ch
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.