Dan Karron@UCBVAX.BERKELEY.EDU (03/29/91)
I am using ipaste format to store medical images, and I am getting
core dumps when I use pixels with a color map index > 255. In medical pix
processing, the images are 12 bits, and I have to rescale (histogram equ and
divide) them to get them to fit in your image format.
Now what is the meaning of the arguments to iopen, and why are short pixels
with 16 bits of storage bombing out with more than 8 bits of value ?
I am guessing now, but the BPP(value) is Bytes Per Pixel ?
Here is the code from GyroPaste.c, which converts Phillips Gyroscan Magnetic
Resonance Images to sgi ipaste format. As it stands now, I have to scale
pixels to get ipaste and movie to work properly, but I don't scale pixels
to use my own 3d reconstruction program. I would really like ipaste to work
properly so that I can use it as a standard to put all of my work with
12 bit medical pictures.
Here is the code:
if(getenv("COMPRESS_8_BITS"))
for ( i = 0; i < npixels ; i++ )
sp_pbuf[i] /= 16;
/* a hack to use sgi image tools */
pixture=iopen(SgiImgFileTitle,"w",VERBATIM(2),3,xres,yres,Zsize);
/* what are the arguments to VERBATIM(value) ? */
/* what is the dim argument, no. 4 and what is the meaning of zsize ? */
for(i=0,j=yres-1; j>=0; j--)
{
putrow(pixture,sp_pbuf+xres*j,i,0);
if(rgb)
{
putrow(pixture,sp_pbuf+xres*j,i,1);
putrow(pixture,sp_pbuf+xres*j,i,2);
}
i++;
}
iclose(pixture);
-------------------------------------------------------------------------------
Here is an example of converted files that crash ipaste and movie
xsize ysize zsize min max bpp type storage name
256 256 1 0 771 2 NORMAL verb 01.sgi
256 256 1 0 2570 2 NORMAL verb 02.sgi
256 256 1 0 2570 2 NORMAL verb 03.sgi
256 256 1 0 3084 2 NORMAL verb 04.sgi
256 256 1 0 3084 2 NORMAL verb 05.sgi
256 256 1 0 2570 2 NORMAL verb 06.sgi
256 256 1 0 2827 2 NORMAL verb 07.sgi
256 256 1 0 2827 2 NORMAL verb 08.sgi
256 256 1 0 3341 2 NORMAL verb 09.sgi
256 256 1 0 3855 2 NORMAL verb 10.sgi
256 256 1 0 3341 2 NORMAL verb 11.sgi
256 256 1 0 3084 2 NORMAL verb 12.sgi
256 256 1 0 3084 2 NORMAL verb 13.sgi
256 256 1 0 2056 2 NORMAL verb 14.sgi
256 256 1 0 1285 2 NORMAL verb 15.sgi
karron:~/D.mri/D.LIN_POINTERS_TEST_1.90.09.26/0101:61movie *.sgi
crash !
Now if it set the COMPRESS_8_BITS environ flag, everything is cool, but
I have to throw away lots of info. I would rather set the BPP to 1 and make
smaller files if that is what I wanted to do.
I can make my own tools, but I would rather be able to build on sgi
tools for this type of applications.
Cheers!
Dan.
| karron@nyu.edu (e-mail alias ) Dan Karron, Research Associate |
| Phone: 212 263 5210 Fax: 212 263 7190 New York University Medical Center |
| 560 First Avenue Digital Pager <1> (212) 397 9330 |
| New York, New York 10016 <2> 10896 <3> <your-number-here> |drb@eecg.toronto.edu (David R. Blythe) (03/30/91)
In article <9103290405.AA06047@karron.med.nyu.edu> karron@cmcl2.nyu.edu writes: > >I am using ipaste format to store medical images, and I am getting >core dumps when I use pixels with a color map index > 255. In medical pix >processing, the images are 12 bits, and I have to rescale (histogram equ and >divide) them to get them to fit in your image format. > >Now what is the meaning of the arguments to iopen, and why are short pixels >with 16 bits of storage bombing out with more than 8 bits of value ? > >I am guessing now, but the BPP(value) is Bytes Per Pixel ? > I frequently use images with 12 bit pixels which are displayed using the colour lookup table (aka cmode()). This is what I pass to iopen() and I also call setcolormap() afterwards to indicate it is a `SCREEN' image image = iopen(argv[2],"w",RLE(2),2,xsize,ysize,1); isetcolormap(image,CM_SCREEN); I have seen other code with zsize set to 0, so I doubt it matters. Most of the imgtools work with SCREEN images (i.e. assemble,izoom,iflip,... but may not set the output type to SCREEN properly (which you can fix in the source code or use the command 'iset SCREEN file'). Some of the commands, however, do not work with all SCREEN files e.g., hist ... david blythe ontario centre for large scale computation drb@clsc.utoronto.ca
Dan Karron@UCBVAX.BERKELEY.EDU (04/01/91)
Thanks for your response. I have been using my hacks for months and months, but
it was only recently that I thought I might check with you or the net for
what is the ``right way'' to do this.
Since the sgi machines (for the moment) have 8 bit dac's, any reference to
more than 1 bytes per pixel must be a color index reference. If sgi is planning
to use more than 8 bits gray scale, great ! I will keep that in mind in my
software. My correspondence with Forest Baskett indicate that that will not
happen in the near term, but X does use more than 8 bit pixels although it
compresses the range on the fly.
My problem is that for simple 2d image manipulation I rely on, or build on
your code. I keep pixels in ipaste format so that I, and the sales demo programs
will run with native data . Now I read ipaste files and need the entire 12 bit
depth for 3d reconstruction and window the 8 bits resolution into the
12 bit depth.
I got a note from davie blythe about this, and this is what I will do, and
if this is what you reccommend, fine.
-------------------------------------------------------------------------------
I frequently use images with 12 bit pixels which are displayed using the colour
lookup table (aka cmode()). This is what I pass to iopen() and I also call
setcolormap() afterwards to indicate it is a `SCREEN' image
image = iopen(argv[2],"w",RLE(2),2,xsize,ysize,1);
isetcolormap(image,CM_SCREEN);
I have seen other code with zsize set to 0, so I doubt it matters. Most of the
imgtools work with SCREEN images (i.e. assemble,izoom,iflip,... but may not
set the output type to SCREEN properly (which you can fix in the source code
or use the command 'iset SCREEN file'). Some of the commands, however, do not
work with all SCREEN files e.g., hist ...
david blythe
ontario centre for large scale computation
drb@clsc.utoronto.ca
Cheers!
dan.
| karron@nyu.edu (e-mail alias ) Dan Karron, Research Associate |
| Phone: 212 263 5210 Fax: 212 263 7190 New York University Medical Center |
| 560 First Avenue Digital Pager <1> (212) 397 9330 |
| New York, New York 10016 <2> 10896 <3> <your-number-here> |