🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.next.programmer
2 messages
2 total messages Started by Daniel Filiberti Tue, 27 Oct 1992 21:25
Device independent cached images?
#18
Author: Daniel Filiberti
Date: Tue, 27 Oct 1992 21:25
49 lines
2601 bytes
Hi Everybody!

I'm having problems doing the following...

1)  I load a 24-bit TIFF image into an NXImage with the initFromFile: method.   
I assume that this method automagically creates an NXBitmapImageRep for you and  
adds it to the images representation list.

2)  A region is traced in the image via the user interface and stored as a  
postscript user path.

3)  I now want to "etch" out the region traced by the user from the image and  
get at the data.  So, I create another NXImage, lockFocus on it, and use some  
postscript magic to set the clipping path and copy from the original image into  
the new one.  This new image is created with the initSize: method, and so I  
assume that it creates a NXCachedImageRep to hold the image.

4) Finally, I need to get at the bitmap data in the etched image.  One way to  
do this is to use the NXReadBitmap() function to read the image into a chunk of  
memory.

Now, when I do this on our NeXTDimension system, everything works fine.  But,  
if I'm running the application on a monochrome slab, NXSizeBitmap() and  
NXReadBitmap() always treat the image as 2 bps, and 4 spp (RGBA)!  Furthermore,  
even if I try to save out the etched image with writeTIFF:, it gets saved as a  
monochrome TIFF!

So, how do I manage to get at the color bitmap data in this situation?  I've  
tried everything that I can imagine to do this, and nothing seems to work.  The  
debugger shows the cached image rep as being 8 bps and 3 color...so its  
obviously stored as color, why does it always get converted to monochrome?


Any help greatly appreciated!

Daniel

---
************************************************************
Motto for a monitor, "It's better to burn out, than to fade
 away..."  [8?)}
************************************************************
 
Daniel Filiberti
Oregon Health Sciences University
Biomedical Information Communication Center (BICC)
3181 Sam Jackson Park Road
Portland, Oregon  97201-3098
email:  filibert@ohsu.edu
Re: Device independent cached images?
#105
Author: Ali Ozer
Date: Mon, 02 Nov 1992 21:31
29 lines
1881 bytes
In article <1992Oct27.212529.12565@ohsu.edu> filibert@ohsu.edu writes:
> ... So, I create another NXImage, lockFocus on it, and use some  
>postscript magic to set the clipping path and copy from the original image into  
>the new one.  This new image is created with the initSize: method, and so I  
>assume that it creates a NXCachedImageRep to hold the image. ...
>Finally, I need to get at the bitmap data in the etched image.  One way to  
>do this is to use the NXReadBitmap() function to read the image into a chunk of  
>memory. ... when I do this on our NeXTDimension system, everything works fine.
>But, if I'm running the application on a monochrome slab, NXSizeBitmap() and  
>NXReadBitmap() always treat the image as 2 bps, and 4 spp (RGBA)!

Hmm. Do you set the depth limit of this second NXImage to 24 bits? If you don't,
then the NXImage you get is the same depth as the default depth of the system.
You should do:

    NXImage *myImage = [[NXImage alloc] initSize:...];
    [myImage useCacheWithDepth:NX_TwentyFourBitRGBDepth];
    if ([myImage lockFocus]) {
         ... draw the image ...
         ... now read it back ...
         [myImage unlockFocus];
    }

Also please don't use the NXReadBitmap()/NXSizeBitmap() functions. Use the
NXBitmapImageRep method initData:fromRect:, which is a lot more efficient,
especially if you let the NXBitmapImageRep allocate and manage the data.
You can use the writeTIFF: method to save it out.

Ali, Ali_Ozer@NeXT.com
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads