Re: accessing bitmap representation, NSImage

[Dr. H. Nikolaus Schaller]

Hi,

Am 04.11.2014 um 01:24 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:

> Hi,
> 
> trying to debug certain stuff in PRICE, I found out that a certain assumption 
> I made is perhaps not true or only conditionally true. I'm investigating on 
> Mac 10.4, not yet on GNUstep, so this is not a bug, I ask what to do best.
> 
> In PRICE all filters need to access the "raw data", that is, they manipulates 
> pixesl directly or even their components. To do that, I need to access the 
> data in  the NSBitmapImageRep.
> 
> NSImages are allocated in the standard way, by opening TIFFS or jpegs.
> 
> What I always did is get the first representation of the representation. It 
> has always been an NSBitmaImageRep and it is very fast, it is already there.
> I had the suspect that this assumption was fragile and only found in quick 
> examples, although it always worked for TIFF or JPEGS or PNGs.
> 
> However I have a consistent way of proving it wrong: Open a 16bit depth image 
> on Mac. Be it grayscale or RGB. What happens is:
> - after loading I have an NSimage, with a single 16-bit depth bitmap rep with 
> either 1 or 3 samples (that is, 16bit or 48bit)
> - as soon as i want tor un the filter, the only representation present is a 
> CachedImageRep, which is unsuitable for my purpose, it is the image used for 
> rendering to the screen. Pixel size changed and most notably, it is an 8bit 
> image, it can even be a color image instead of a grayscale image
> 
> I understand I can have more representations, I expected to find BOTH the 
> cached representation but also he original image. How can I get the original 
> image data, as I had after opening the file? Instead I end having only the 
> screen representation, this confuses me.
> 
> Perhaps by playing with the cache use options?

I don’t know the details and full answer, but IMHO NSImage is just a container 
for several NSImageReps that adds methods for loading, finding the best one for 
a given display and draw that.
And, it runs some caching mechanism (which is AFAIK not well documented and 
can’t be influenced).

So you should simply open the NSImageRep directly, i.e. load it from a file.

What you of course have to rebuild is the way how NSImage tries to load the 
file with different NSImageReps until it can be loaded. I.e. the automatic 
format detection.

But then you have the NSImageRep for modification as you like. Ah, I see that 
this search for supported formats is built into +[NSImageRep initWithData:].

Finally, you can alloc+init an NSImage and use addRepresentation to add exactly 
this rep. And then you can draw. Even if it then magically converts it into a 
NSCachedImageRep, you still have access to the original.

Maybe this caching is triggered by the first draw operation, so if you get the 
representations before doing any draw operation on the NSImage, you could also 
get the uncached version first and retain it…

Just some thoughts…
Nikolaus