Thank you Circular... I've spent scores of minutes trying to get my head around TLazIntfImage and TRawImage.. but don't seem to be making much progress towards the functionality I seek.
The more I worked at that, the more I wondered if your answer really dealt with what I wanted to do. (Sorry!)
I think you were showing me a fast way to redraw a bitmap, with sort of a "color substitution" mechanism along the way? By reference to sort of a "look up" table? The "raw" image was held "internally", (the "packed array of byte"?) out of sight, and when the graphic is (re)drawn, to move it "into sight", the process was along the lines of "look at the 'color' for each pixel in the raw image/ display a pixel of a color-deteremined-from-the-lookup-table"? ("Lookup table" being the array MyPalette?)
I don't mean to drone on about the Archimedes... it's just that having done this once, I know that it CAN be done, in some environments.
Anyone reading this, please re-read my original post in a moment.. but here's an attempt to build on that....
I think the Archimedes gave me access to some kind of color lookup table deep within the OS.
When I drew the image, the colors used were specified by what amounted to "names". The programming language, or maybe the OS dealt with on-the-fly mapping of a "named" color to a mix of RGB.
So, for instance, let's say I'd drawn pixel[3,7] in "color24". But WHAT "color24" was at any given time was determined in a table. I could go to the "table of colors" and say what I wanted "color24" to be, and as soon as I changed the value there, the color of pixel[3,7] (and any other pixels drawn (some time ago) in "color24".)
** I didn't have to explicitly redraw the graphic. **
Upon the next screen refresh, the color of those pixels changed, and stayed in the new color unless "color24" was redefined again.
It was a neat and useful fuctionality!
====
Something else that gives me hope....
I believe there are ways to "calibrate" monitors? I believe it is done by the OS, by tweaking what is actually sent to the display when, at a higher level, you think you are asking for RGB in the (for instance) ratio 128:128:64?
Suppose I have two PCs set up side by side, same in every way, except that one uses an old CRT monitor and the other an LCD monitor. And they both drive one printer. And I do high precision graphics work.
If I don't have the two PCs and the printer all "inter-calibrated", I could have "identical" roses, say, on the two screens, but get (slightly) different results out of the printer when I printed from the two computers. I believe "calibration" overcomes this sort of issue?
And if that's right... is there some way to get at the mechanism behind it, and if so does it seem, kind reader, a path to what I want to do?
===
Sorry if I misunderstood first answer. By all means tell me to look at it again, if to change the color of, say, all green pixels to blue *does not entail* re-drawing the image.
(My aversion to re-drawing the image is that there would be many, MANY pixels to re-draw in the application I hope to build.)