🚀 go-pugleaf

I want to read a rectangular file of float values (i.e. gridded data)
and plot a colour image of it in Windows.  I'm trying to sort out
all of the bitmap and dib functions and it's confusing.  This appears
to be different than recent discussion of bitmaps because:
  - these data values have real dimensions (metres) - they are
    not just pixels in a picture
  - the file is proprietary float values - not BMP, PIC, EPS etc
  - nobody has talked about dithered colours and their use for
    displaying bitmaps on 16-colour systems

I never bothered to tackle this problem under DOS because I
could only get 16 colours on a VGA in 640X480 mode.  Now that
I have Windows, I would like to take advantage of the device
independence of the drivers & the availability of dithered colours.
Most of the following questions relate to using a 16-colour VGA
system as the base system and having Windows provide dithered
colours...

Here are the issues:
  1. I want to distribute the data set as float values, not as saved
     bitmaps (independent or dependent) or other 'picture' formats.
     So converting the file to a BMP first is not an option here.
     I just want to read the 'float' file and display it.  The files
     can be any size (100 X 100 or perhaps 1000 X 1000, i.e. 4 Mb!)

  2. Each data value represents a cell size of a specific value,
     i.e. 250m X 250m.  I need to display all or a portion of
     the file on the screen at a specific scale (to match the
     other GIS data).  There are 2 cases, depending on scale:
        - the data cell is represented by several device pixels
          (i.e. 10 X 10 pixels)
        - the data cell is represented by less than 1 pixel
          (i.e. at a particular scale, each device pixel
          may represent the average of several data values)
        These requirements immediately bring to mind the idea of
        using StretchBlt for zooming and panning on the picture.
        In the first case, I could use Rectangle(), albeit slow,
        but not in the second case.

  3. To test, I wrote a simple program to subdivide the window
     into 256 X 256 rectangles and then I drew each one using
     Rectangle() with a different colour.  I did get my dithered 
     colours and it looked quite good, but it took slightly less 
     than forever. I expect that 1000 X 1000 will take forever.  
     The result is exactly what I want:
        - logical co-ordinates
        - dithered colours
        - simple to program
     except for speed.  Obviously I can do some decimation of the
     data myself, but I would like Windows to take care of it for
     me and I want to use logical co-ordinates, not device co-ordinates.

Questions:
1.  As I read in the file to display it, I can use various algorithms 
    to convert the float values to:
        - palette index values (i.e. 0-255)
        - actual RGB colours (i.e. doing my own lookup instead
          of using palettes)
    Is there any reason to do it one way or another?

2.  Will I still be able to get dithered colours (i.e. more
    than 16) when dealing with:
                - bitmaps
                - DIBs
                - palettes

3.  Here's my first idea:
        - create an N X M memory compatible bitmap to match the file
        - for each value, use SetPixel() to set the RGB colour
        - when ready to display, just BitBlt it to the screen
          and hopefully the individual pixels would 'expand' to
          rectangles of dithered colours
        
        Apparently this won't work because Windows knows the HDC
        is for a 16-colour VGA, so SetPixel() will just give the
        closest 1 of 16 colours.  This appears to eliminate the use 
        of bitmaps entirely and also StretchBlt.

        So, how do I get dithered colours (for 16-colour VGA)
        *and* also use StretchBlt and the other *blt* functions?

4. The docs (Petzold,SDK) say that DIBS are more complex to work 
   with and are really only useful for creating files to be used
   on other systems.  For just internal use etc, they say stick
   with simple bitmaps.  This sounds like good advice, but will
   that limit me later when I want to print the picture?  In
   other words, are DIBs also mandatory for proper printing?

Any ideas?
-- 
John A. Grant						jagrant@emr1.emr.ca
Airborne Geophysics
Geological Survey of Canada, Ottawa