lsmichae@immd4.informatik.uni-erlangen.de (Lars Michael) (03/01/91)
Hi netlanders, there was some confusion about the format of a SPECTRUM 512 picture. I've done some work and here are my results: The description of the file format of *.SPU and *.SPC in the ST picture formats document made by David Baggett is correct. I have some correction for the area of validity of the colors. In a SPECTRUM 512 picture each scan line has three color palettes, that will make 48 colors. In the following I will number these three palettes from 0 to 2 (first palette 0), e.g. color 45 will appear in palette 2. All three palettes build the one *virtual* palette. All scan lines are independent from each other. The ST has one hardware palette of 16 colors. Let me call this the *real* palette. Get the index <cnr> of a color of the virtual palette, the valid area will apear in the following table (left and right border are inclusive). left border right border Palette 0 0<cnr<=15: cnr odd 0 10*cnr-6 cnr even 0 10*cnr-1 Palette 1 16<=cnr<=31: cnr odd 10*(cnr-16)-5 10*cnr-6 cnr even 10*(cnr-16) 10*cnr-1 Palette 2 32<=cnr<=47: cnr odd 10*(cnr-16)-6 319 cnr even 10*(cnr-16) 319 Color 0 in palette 0 has no valid area and is the border color. SPECTRUM 512 sets the colors with number 0, 15, 16, 31, 32 and 47 to black [$000]. With the above table its not difficult to create a corresponding table where you can get thy real palette from a x-value of a pixel. Lars +-----------------------------------+----------------------------------+ | Lars Michael | | | | | | lsmichae@faui43.uni-erlangen.de | | | | "Down with ATARI, | +-----------------------------------+ / | \ Long live the ST !" | | "May the Schwartz be with you!" | / | \ | +-----------------------------------+----------------------------------+
lsmichae@immd4.informatik.uni-erlangen.de (Lars Michael) (03/01/91)
Hi netlanders, I have made some small conversion routines to a new intermediate picture format called RGB and a routine from RGB to uncompressed SPECTRUM 512 format. The results a very nice !!! The RGB format goes like this: <RGB intermediate format> *.RGB (only low resolution) 1 word resolution flag (ignored) 16 word color palette (ignored) 16000 words red values of the picture (screen format) The color index of the point gives the R-value 1 word resolution flag (ignored) 16 word color palette (ignored) 16000 words green values of the picture (screen format) The color index of the point gives the G-value 1 word resolution flag (ignored) 16 word color palette (ignored) 16000 words blue values of the picture (screen format) The color index of the point gives the B-value ------------ 96102 bytes You may have noticed that each of the R-, G- and the B-planes looks like a DEGAS *.PI1. That's right and you may set the palette to increasing gray values to have a look at the R-plane. Caveats: The color palette is *always* ignored. To get the color value from a pixel get the color indices of the correlated pixels in the R-, G- and B-plane and build directly the RGB-value 0xrgb (no indirection to the color palettes)! I hope there's a discussion about this "new" picture format. My conversion routines are TMPTORGB, (DBW-render temp file to RGB intermediate file) PI1TORGB, (three DEGAS files to one RGB intermediate file) IFFTORGB, (AMIGA IFF file to RGB intermediate file) RGBTOSPU. (RGB intermediate file to SPECTRUM uncompressed) Some notes: - PI1TORGB is used to concatenate digitized R-, G- and B-planes (each plane stored as DEGAS picture). - IFFTORGB uses the CAMG chunk and recognizes HAM and INTERLACE. - RGBTOSPU runs up to 10 minutes, depending on the file. It calculates a color histogram and looks for the best fit of the maximum color in the scan line. If the virtual palette is full all left pixels are set each to the color index of the nearest color in the *real* palette. Some future projects are: GIFTORGB, (GIF file to RGB intermediate file) SPUTOSPC, (compress SPECTRUM file) SPCTOSPU. (uncompress SPECTRUM file) If there's some interest in these routines I'll post them to comp.sources.atari.st and comp.binaries.atari.st. Lars P.S.: Someone out there who has a gif decoder? I have knowledge of the LZW-compression used in gif files, but would prefer to get sources for this to save sleep, tea and sweat ... +-----------------------------------+----------------------------------+ | Lars Michael | | | | | | lsmichae@faui43.uni-erlangen.de | | | | "Down with ATARI, | +-----------------------------------+ / | \ Long live the ST !" | | "May the Schwartz be with you!" | / | \ | +-----------------------------------+----------------------------------+