Re: NSBitmapImageRep scaling/copying issue

[Riccardo Mottola]

Hi,

Josh Freeman wrote:
> Hi Riccardo,
>
>    Ran PRICE 1.3.0 on OS X and saw some discoloration in an image's 
> partially-transparent region after flipping it horizontally.

Thanks for taking the time out and giving the tip!
>    The issue seems to be due to mismatched bitmap-formats: Bitmaps 
> loaded from external data can be either premultiplied- or 
> nonpremultiplied- alpha (in -[MyDocument 
> loadDataRepresentation:ofType:], there's some Mac-only code that 
> checks whether the loaded bitmap is nonpremultiplied, but the result 
> is unused), and bitmaps generated by PRICE for pixel-data operations 
> are always in the default premultiplied-alpha format (PRICE only uses 
> the version of the -[NSBitmap initWithBitmapDataPlanes:...] 
> initializer that doesn't include the bitmapFormat parameter). Copying 
> pixel data directly from a nonpremultiplied to a premultiplied bitmap 
> without reformatting the data can cause discoloration in 
> partially-transparent areas.

I had that suspect, but I didn't know it would look like that! Thus I 
didn't check that.

I expanded the on-load conversion to pre-multiply alpha, since 
converting all filters would be an extreme effort. Also, pre-multiplied 
should be filter-invariant, so it is the right thing.

If you used PRICE from CVS or an updated mirror, you can update and try out.

The interesting question is now if GNUstep handles that? What happens if 
a non-pre-multiplied image gets loaded in GNUstep: does it get converted 
on the fly? does it behave like on the mac that the format is returned? 
Or do we just handle it wrong.
That could explain certain issues I am thing in GWorkspace thumbnailer.

Do you know if e.g. GIMP reports can report which format one is loading 
and convert them? I have seen no such options. I want to check some of 
our GUI files.

>    The horizontal-flip issue disappeared after switching the 
> NSBitmapImageRep initializer call in -[PRTransforms flipImageHoriz:] 
> to the version with the bitmapFormat: parameter (passing [srcImageRep 
> bitmapFormat] as the value so the formats matched). Not counting 
> flipImageHoriz:'s call, there are 20 more bitmap-initializer calls 
> throughout the rest of the app - they'd need to be switched as well to 
> fix format-mismatches in other operations.

This is why I convert on-the-fly. For flipping or cropping, moth formats 
are fine, but for scaling not.
>    Another thing that can cause discoloration on OS X are mismatched 
> bitmap color profiles (color management is currently unimplemented on 
> GNUstep, so it's not affected): When copying pixel data directly 
> between bitmaps, the bitmaps should have the same color profile, 
> otherwise they'll render on the screen in different colors (despite 
> identical pixel data).
Yes, that is clear. I do handle that now in the conversion code. 
However, it should be probably preserved in all filters maintaining 
colors (e.g. scale or crop) however something like grayscale conversion not.

Riccardo