larserio@IFI.UIO.NO (LarsErikOsterud) (05/25/91)
Does anyone have an EASY TO UNDERSTAND description of the .IMG Gem bitmap file format. I have written some scanner software but today I use the DEGAS format (640 x 400) and that is to small so I need to convert the program to use IMG files instead (and then I need the IMG format :-) Lars-Erik / ABK-BBS +47 2132659 / ____ ______ ________________________ Osterud / larserio@ifi.uio.no / /___ / The norwegian ST __________/ ______________________/ ____/ / Klubben, user association
blackbox@pfunk.hanse.de (Michael Kistenmacher) (05/28/91)
In <CMM.0.90.2.675111152.larserio@kvart.ifi.uio.no>, LarsErikOsterud writes: >Does anyone have an EASY TO UNDERSTAND description of the .IMG Gem bitmap >file format. I have written some scanner software but today I use the DEGAS Isn't the description of the IMG-format implementef in the monthly posted picture-format list ? Just a moment, i take a look..... --------------cut---------------- <GEM Bit Image> *.IMG 1 word version number of image file [1] 1 word length of header in words [usually 8] 1 word number of color planes [1 for monochrome] 1 word pattern length in bytes [1-8, usually 2 for screen images] 1 word pixel width in microns (1/1000 mm, 25400 microns per inch) 1 word pixel height in microns 1 word line width in pixels 1 word number of lines ------- ? words header length defined in 2nd word of header ? bytes data NOTES: If the image is a color image (planes > 1), the planes are stored separately starting with plane 0. There is, however, no standard way of storing the color palette. Some programs may save the palette in separate files, some may extend the header. For this reason, you should never assume the header is 8 words long, always get the header length from the 2nd word of the header. Also, the line width in the 7th word is the number of pixels in a line. Since the data is encoded in byte-wide packets, the actual unpacked line width is always a multiple of 8, and may be 1-7 pixels longer than the length specified in the header. For each byte x in the data section, x = 0 Pattern/scanline run. Read the next byte, n (unsigned). If n > 0 then: Read a number of bytes equal to the "pattern length" word in the header. Repeat this pattern n times. If n = 0 then: Scanline run. Data for the next scanline is to be used multiple times. Read the following record: 1 byte flag byte [$FF] 1 byte number of times to use next scanline data The data for the next scanline follows, compressed normally. x = 80 (hex) Uncompressed bit string. The next byte determines the number of bytes to use literally. The literal data bytes follow. otherwise Solid run. The value of x determines what to draw. The high bit specifies whether the pixels are set or cleared. A 1 indicates a byte-run using $FF, a 0 indicates a byte-run using $00. The low 7 bits, taken as an unsigned quantity, specify the length of the run in bytes. -------------end--------------- -- ------------------------------------------------------------------------------ | listen to the coolest ! | Michael Kistenmacher / blackbox | | Music from the Galaxy ! | 2000 Hamburg 61 / Schippelsweg 64 | | !!! P-Funk !!! | West Germany / ++ 49 40 552 37 66 | ------------------------------------------------------------------------------
jimomura@lsuc.on.ca (Jim Omura) (05/29/91)
In article <A0b64gka@pfunk.hanse.de> blackbox@pfunk.hanse.de writes: >In <CMM.0.90.2.675111152.larserio@kvart.ifi.uio.no>, LarsErikOsterud writes: >>Does anyone have an EASY TO UNDERSTAND description of the .IMG Gem bitmap >>file format. I have written some scanner software but today I use the DEGAS > >Isn't the description of the IMG-format implementef in the monthly posted >picture-format list ? Just a moment, i take a look..... > >--------------cut---------------- > ><GEM Bit Image> *.IMG > >1 word version number of image file [1] >1 word length of header in words [usually 8] >1 word number of color planes [1 for monochrome] >1 word pattern length in bytes [1-8, usually 2 for screen images] I've been meaning to ask this for a while now, and this seems like a good time. What is this "pattern length" all about? It can't be the length of the data bytes. That would be 32000 rather than 2. >1 word pixel width in microns (1/1000 mm, 25400 microns per inch) >1 word pixel height in microns Does most software actually take this into account for anything or can you leaave the pixel dimension 0? >1 word line width in pixels >1 word number of lines >------- >? words header length defined in 2nd word of header > >? bytes data > >NOTES: If the image is a color image (planes > 1), the planes are stored >separately starting with plane 0. There is, however, no standard way of >storing the color palette. Some programs may save the palette in separate >files, some may extend the header. For this reason, you should never >assume the header is 8 words long, always get the header length from the >2nd word of the header. Also, the line width in the 7th word is the number This is one of the reasons I'm making IFF/ILBM my main "supported file type". No matter how you feel about the Amiga/Atari/Mac wars, the IMG "standard" just isn't sufficiently defined and has not real underlying rational. I don't know if I would embrace the whole of the IFF standard -- it's really just a mish-mash. But the ILBM part is rational and practical. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura
stephen@oahu.cs.ucla.edu (Steve Whitney) (05/30/91)
In article <1991May29.014046.24302@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: >In article <A0b64gka@pfunk.hanse.de> blackbox@pfunk.hanse.de writes: >>In <CMM.0.90.2.675111152.larserio@kvart.ifi.uio.no>, LarsErikOsterud writes: ... >>1 word pixel width in microns (1/1000 mm, 25400 microns per inch) >>1 word pixel height in microns > > Does most software actually take this into account for anything >or can you leaave the pixel dimension 0? I've talked to several other Atari developers who _do_ use this information. Applications that print image files especially need to know the pixel size. --Steve >-- >Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 >lsuc!jimomura >Byte Information eXchange: jimomura -- Steve Whitney - UCLA CS Grad Student (())_-_(()) Soon to be working at Silicon Graphics | (* *) | Internet: stephen@cs.ucla.edu UCLA Bruin--> { \_@_/ } GEnie: S.WHITNEY `-----'
blackbox@pfunk.hanse.de (Michael Kistenmacher) (05/31/91)
In <1991May29.014046.24302@lsuc.on.ca>, Jim Omura writes: >In article <A0b64gka@pfunk.hanse.de> blackbox@pfunk.hanse.de writes: >>1 word pattern length in bytes [1-8, usually 2 for screen images] > > I've been meaning to ask this for a while now, and this seems >like a good time. What is this "pattern length" all about? >It can't be the length of the data bytes. That would be 32000 rather >than 2. "pattern length" means the fill-pattern. As it looks, you can define your own fill patterns and save them with your IMG-file. As you may know, standard fill patterns are 16 pixel wide, so it's the 2 for two bytes. > >>1 word pixel width in microns (1/1000 mm, 25400 microns per inch) >>1 word pixel height in microns > > Does most software actually take this into account for anything >or can you leaave the pixel dimension 0? When you are using your ATARI for publishing, you will need this information for restoring the original size of your IMG. In CALAMUS (SL Version is on the run since this week) you have a function for restoring this, but it will only work, if you have inserted the correct data. Please do so. Bye....Mike -- ------------------------------------------------------------------------------ | listen to the coolest ! | Michael Kistenmacher / blackbox | | Music from the Galaxy ! | 2000 Hamburg 61 / Schippelsweg 64 | | !!! P-Funk !!! | West Germany / ++ 49 40 552 37 66 | ------------------------------------------------------------------------------
fh@well.sf.ca.us (Fabian Hahn) (06/02/91)
jimomura@lsuc.on.ca (Jim Omura) writes: >>1 word pixel width in microns (1/1000 mm, 25400 microns per inch) >>1 word pixel height in microns > Does most software actually take this into account for anything >or can you leaave the pixel dimension 0? No, do not do this. All programs that import .IMG images should at least use these values to calculate the aspect ratio of the picture. Our product, Wordflair II uses them if they seem reasonable to display images correctly when the preserve aspect-ratio option is selected. If you do not have any information about the original pixel size put in something like 72dpi x 72dpi. > No matter how you feel about the Amiga/Atari/Mac wars, >the IMG "standard" just isn't sufficiently defined and has not real >underlying rational. You are probably right, but .IMG is the only format currently supported by the GEM functions in the ATARI. So it will be around for quite some time more. We should try to get all programs that support .IMG's to use them cosistent, this would take care of at least some the problems that we are having with .IMG's. Fabian Hahn Goldleaf Publishing, Inc.