tonyg@merlin.cvs.rochester.edu (Tony Giaccone) (09/22/89)
Ok Folks, I've posted this question before, and it didn't get an answer
then. Maybe we'll have a little better luck this time. I've written an
application that takes sun raster files, and converts them in to PICT2
files. It's almost perfect. However, I've run into a problem that I don't
know how to solve, and in fact the documentation seems to indicate I
shouldn't be having at all.
When I open the sun raster file, I use the sun color map to create a
ColorTable. From that ColorTable, I create a Pallette with CTab2Palette.
I then display the image in the window, and associate the palette with that
window. This all works fine as the image displays using the colors from the
sun map.
My next step is to create the PICT2 file. I do this in the way suggested by
the technotes, and the PICT File Format Notes. However, the colormap
doesn't seem to get stored in the PICT2 file. When I display it using
Apple's PICTViewer, the colors are subtley wrong. The image is obviously
being displayed in the whatever the current colormap is set to. Not the
colormap that I created for that file.
Now the tech notes even talk about this, and I quote:
"On the other hand, each CopyBits call that is
made stores a complete copy of the color table
into the picture."
So if that's the case why doesn't the copybits install a copy of the
current color table into the PICT2. Or, if it does how come PICTViewer
doesn't use that Color Table when it displays the file? It certainly seems
to use the color tables in other PICT2 files. I don't get it.
Could someone at Apple please enlighten me?
Tony Giaccone
tonyg@cvs.rochester.eduejd@iris.brown.edu (Ed Devinney) (09/22/89)
In article <3084@ur-cc.UUCP> tonyg@merlin.cvs.rochester.edu (Tony Giaccone) writes: > So if that's the case why doesn't the copybits install a copy of the > current color table into the PICT2. Or, if it does how come PICTViewer > doesn't use that Color Table when it displays the file? It certainly seems > to use the color tables in other PICT2 files. I don't get it. If you use something like PictDetective*, you should see that CopyBits() does put a copy of the ColorTable into the PICT. This Table, though, will not assert its colors in the GDevice when you _draw_ the pict. The Table is used only as the source table when CopyBits does its color mapping on pict playback. I would bet that the reason that PICTViewer seems to use the ColorTable for other PICTs is that the colors in them may be closer to the default palette and don't get mapped too badly. What you probably want to do is to write or find a PICT-viewing program that allows import of Palettes as well as PICTs (tho' I don't know of any offhand); when writing your files you could also write a Palette resource, for instance. In sum, the PICT does hold a copy of the ColorTable. The ColorTable will be used by CopyBits() to map your PixMap's colors to those in the GDevice. The ColorTable currently in the GDevice will _not_ be affected by the ColorTable in your PixMap. It is the job of the displaying application to determine the appropriate Palette needed to display the PICT correctly, and to cause its Window to assert that Palette. ed - Former Junior Rocket Scientist for Color @ Cricket Software (RIP) [*PictDetective is a product of Palomar Software] ++++++ ed devinney...IRIS/Brown University, Providence, RI...ejd@iris.brown.edu -- There's a light on the hill, that's far out in the distance, ...it calls out my name, it calls out for a change...(Fishbone) --
isr@rodan.acs.syr.edu ( ISR group account) (09/22/89)
The"Vision Lab" application (i believe a demo version is on Sumex) is very,very,very good at displaying various types of image-contaning files with the correct CLUT values. (PICT,PICTrsrc,GIF,PixelPaint,Paint Thunder"SCAN",GrayMap). it also lets you copy a section of the image to the clipboard. Very useful. I've got ver 1.0d12 Does anyone know of any later ones around? -- Mike Schechter, Institute for Sensory Research, Syracuse Univ. isr@rodan.acs.syr.edu -or- msschech@rodan.syr.edu
lsr@Apple.COM (Larry Rosenstein) (09/23/89)
In article <3084@ur-cc.UUCP> tonyg@merlin.cvs.rochester.edu (Tony Giaccone) writes: > So if that's the case why doesn't the copybits install a copy of the > current color table into the PICT2. Or, if it does how come PICTViewer > doesn't use that Color Table when it displays the file? It certainly seems > to use the color tables in other PICT2 files. I don't get it. If you were to dump the picture, I think you would find that your custom color table was present. A pixmap always has an associated color table. What happens is that the CopyBits from your picture to the screen follows the normal Color QuickDraw rules. That is, Color QuickDraw maps the desired colors to the closest ones that the display can show. Color QuickDraw never modifies the current color table in the process of drawing. If you were using a 24-bit display, then you would get the desired colors, because all colors are achievable. This is a known weakness in the PICT format. What programs needs to do is get the "appropriate" color table for the picture, set up that palette, and then draw the picture. The problem is that there is no standard for getting the "appropriate" color table. Some programs store the CLUT as a separate resource, and read that resource to construct the palette. (You could use the resource type understood by the Palette Manager.) Another approach is to scan through the picture and build up a CLUT based on the colors actually used. For a bitmap image this is OK, since the CLUT is stored in the pixmap. For an arbitrary picture it is not as easy to do. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
pepke@loligo (Eric Pepke) (09/23/89)
I have a program that, among other things, converts Sun 24-bit raster files to 8-bit chunky bitmap PICT files. It works just fine, and when I read the result into PixelPaint it displays perfectly with the correct palette. I think that the problem may be a failing of the PICT viewer rather than your method of creating the file. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.