• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Is this a bug in Tiger's NSBitmapImageRep?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is this a bug in Tiger's NSBitmapImageRep?


  • Subject: Re: Is this a bug in Tiger's NSBitmapImageRep?
  • From: Andrew Platzer <email@hidden>
  • Date: Mon, 2 May 2005 18:31:59 -0700

On May 2, 2005, at 3:06 PM, Marc Liyanage wrote:
I noticed today that a piece of code I wrote for Jaguar/Panther no longer works right in Tiger. I didn't change anything, and the exact same code still works flawlessly on Panther.

I am using the method

initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPe rPixel:hasAlpha:isPlanar:colorSpaceName:bytesPerRow:bitsPerPixel:

to create the NSBitmapImageRep, and then I fetch the bitmap base address and fill it with data. On Tiger, the resulting image looks like garbage when displayed or serialized to TIFF. It looks like there's something wrong with the data length calculations, depending on the target width the rows are skewed. It seems to work correctly when the image width in pixels is a multiple of 24 which is the number of bits per sample times the number of channels.

The test case below produces correct results on Panther, and the exact same binary run on Tiger will show the problem. For comparison, the ".raw" file can be opened in Photoshop.

Is this a bug in Tiger or have I been doing something wrong all along without getting into trouble?


I see there's a new, similar method in Tiger but I'd rather not use that one because my code needs to run on Jaguar and Panther too.

This is a change to the semantics of -initWithBitmapDataPlanes:...
It is now possible for the bitmap to not have packed bytesPerRow in order to speed up drawing (something that was always possible, but just didn't happen). Your code assumes that the bitmap data is packed and so as you fill up the bitmap, you start getting skewed rows. Either pass in an explicit bytesPerRow value instead of zero to - initWithBitmapDataPlanes:... to explicitly indicate packed values or change your loop to be something like:


    unsigned char* row = destbuffer;
    int i, j;
    for (i = 0; i < height; i++, row += [imageRep bytesPerRow]) {
        unsigned char* p = row;
        for (j = 0; j < width; j++) {
        *p++ = c;
        *p++ = c;
        *p++ = c;
        c++;
        }
    }

Note that in Panther compiled apps, we should still alloc packed bytesPerRow for compatibility. I assume you recompiled on Tiger.

Andrew Platzer
Application Frameworks
Apple Computer, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Is this a bug in Tiger's NSBitmapImageRep?
      • From: Rick Hoge <email@hidden>
    • Re: Is this a bug in Tiger's NSBitmapImageRep?
      • From: Marc Liyanage <email@hidden>
References: 
 >Is this a bug in Tiger's NSBitmapImageRep? (From: Marc Liyanage <email@hidden>)

  • Prev by Date: Re: When is (NSColor) black not black?
  • Next by Date: Re: Core Data XCode issue
  • Previous by thread: Is this a bug in Tiger's NSBitmapImageRep?
  • Next by thread: Re: Is this a bug in Tiger's NSBitmapImageRep?
  • Index(es):
    • Date
    • Thread