bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSBitmapImageRep


From: Mark Tracy
Subject: NSBitmapImageRep
Date: Mon, 30 Oct 2006 00:02:04 -0800

I noticed while porting my chromatogram viewer from Mac to GNUstep that NSBitmapImageRep -representationUsingType:properties: didn't do anything. I thought I would try to get it working. This patch is a beginning on that. At the moment, it only supports NSTIFFFileType, but stubs for PNG, GIF and JPEG now exist. Along the way, I implemented a few TODO and FIXME items.

As I have time and energy, I will work on adding the real support for the other formats. If one of the original authors, or someone else wants to do it, that is OK with me.

System details: Suse Linux 10.1 running on Parallels Virtual Machine on MacOSX 10.4.8(intel). Gcc 4.1.0, libc 2.4, gnustep-make-1.13.0, gnustep-base-1.13.0, gnustep-gui-0.11.0, gnustep-back-0.11.0, libtiff-3.8.2, libart_lgpl_2-2.3.17 with the default art backend.

I have attached the patch file and a test application I used to validate the changes (rough piece of work, but not for public consumption).

Cheers,
Mark Tracy

ChangeLog

Sun. 29-Oct-2006 Mark Tracy <tracy454 at concentric dot net>

        1. NSBitmapImageRep attribute global strings were not defined.
Fix: add definitions to externs.h. and declarations to NSBitmapImageRep.h Comment: Two strings defined in Cocoa were commented out. One because ColorSync is Apple's own data format, and one because there is no EXIF support in GNUstep, yet. I propose adding GSICCProfileData if and when GNUstep supports color management.

2. LZW compression in TIFF was disabled for lack of a test to determine its availability
        Fix: Implemented NSTiffIsCodecConfigured(codec) in tiff.m
Comment: As of libtiff-3.7.0 there is a function call to determine whether or not a compressor is configured at runtime. For libtiff-3.6.0 (earlier?) there are macros #defined in tiffconf.h. The implementation checks library version at build-time and uses one of the two methods. I don't have an installation of version 3.6, so I have not been able to test the second method.

        3. -canCompressUsing:  relied on a static list of capabilities
Fix: In NSBitmapImageRep.m used the new NSTiffIsCodecConfigured (codec) to check for available compressor Comment: The static list could be wrong, as it was on my installation. The default libtiff-3.8.2 no longer supports oldJPEG. Also, libtiff depends on libjpeg to provide that compression service. The pay-for edition of Suse does include the patented LZW features for TIFF and GIF. (Mercifully that patent expired this year.)

4. +getTIFFCompressionTypes:count: relied on a static list of capabilities Fix: In NSBitmapImageRep.m used the new NSTiffIsCodecConfigured (codec) to check for available compressors. Also changed the private methods _localFromCompressionType: and _compressionTypeFromLocal to private class methods so that they could be used within other class methods. Altered -initFromTIFFImage:number: and - TIFFRepresentationUsingCompression:factor: to use the new class methods. Comment: Probably a sub-optimal implementation of checking, but it works.

        5. -setProperty:toValue: and -valueForProperty: were not implemented
Fix: in NSBitmapImageRep.m added a new instance variable NSMutableDictionary * _properties and implemented the accessors. Patched -initFromTIFFImage:number: to set the properties NSImageCompressionMethod and NSImageCompressionFactor. Comment: This feature is used to pass options to/from TIFF, PNG, GIF and JPEG in Cocoa. This is not clear from the documentation, but that is clearly the behavior for PNG, JPEG and GIF. I have not implemented the use of properties in PNG, GIF or JPEG; that will have to wait for a future patch. (Probably by someone better than myself.) The - setCompression:factor and -getCompressionFactor methods seem to be independent of the properties in Cocoa. In one case, the Cocoa docs said that reading a TIFF would set the compression property, but the framework did not work that way; I implemented the properties for TIFF.

        6. Checked and updated NSBitmapImageFileType in NSBitmapImageRep.h
Fix: confirmed the enumeration values against Cocoa, and added NSJPEG2000FileType = 5
        Comment: JPEG2000 is not implemented, just reserved a spot for it.

        7. -representationUsingType:properties: was not implemented.
Fix: Partly implemented in NSBitmapImageRep.m with support for NSTIFFFileType. Added stubs for _PNGRepresentationWithProperties: to NSBitmapimageRep+PNG.h and .m. Added stubs for _GIFRepresentationWithProperties: to NSBitmapImageRep+GIF.h and .m. Added stubs for _JPEGRepresentationWithPropertie: to NSBitmapImageRep +JPEG.h and .m. Comment: All the unimplemented formats issue an NSLog() and return nil. It is not clear from Cocoa docs, but if you pass nil for the properties, it uses the values stored internally by - setProperty:toValue:. I suppose there are some reasonable defaults if those have not been set. That is the behavior I implemented.

8. +representationOfImageRepsInArray:UsingType:properties: was not implemented Fix: Incomplete implementation in NSBitmapImageRep.m by borrowing code from the corresponding TIFF method. I have yet to find the explanation of how that actually ought to work.

Attachment: gnustep-gui-0.11.0-bitmap.patch
Description: Binary data

Attachment: TestApp.tar.gz
Description: GNU Zip compressed data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]