Change pixel color without redrawing?

[Sheepdog]

Suppose I do something along these lines...

b) Create an array, MyColors, with 10 elements, each holding a TColor number

c) Set up a bitmap

... and then do...

d)
for c1:=0 to 10 do begin
Image1.Picture.Bitmap.canvas.pixels[random(10),random(10)] := MyColors[random(9)];
end;

===
That (or something like it!) would put 11 "dots", of varying colors (selected from those specified in my array MyColors) on the bitmap. That's not the question, so, please, let's not get into whether it is "random" or RND, etc....

THE QUESTION IS....

(I did this, long ago, on an Archimedes!... can Lazarus do it? Even if it means locking this program into the Wicked World Of Windows?)

Let's say that one of the colors in MyColors was a pure green. And that some of the dots drawn at random were drawn in green.

Is there a way to "tweak" the underlying screen drivers so that those pixels previously drawn in green now appear in, say, red?

I do not want to scan the whole bitmap and re-draw any green pixels.

If it is a case of going to "fight" with low levels of the OS, then I understand that this isn't the right forum... but if anyone can at least give me a Google starting point for what Windows would need, it would be much appreciated.

Better yet, if there is a Lazarus OS independent answer!

(If it is a case of using....

http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls

... then that's okay... the functionality would be worth it.)

[circular]

What you are talking about is a system palette. This is not possible with the usual graph modes that have 16 million colors.

It is possible to emulate it however with a 256 color bitmap with a palette and to change just one element of the palette. I am not sure this would be OS independent though. But you can try making a TLazIntfImage for example or TRawImage.

Otherwise you could do it yourself, by having an array for the palette and by storing the image as a packed array of byte. Then when drawing, generate the actual content by going through the bytes by doing something like:

Code: [Select]

var
  p: PDWord;
  MyPalette: array of DWord;
  source: PByte;

...

for n := NbPixels-1 downto 0 do
begin
  p^ := MyPalette[source^];
  inc(p);
  inc(source);
end;And then drawing the bitmap. You need to have direct access to pixels for it to be efficient or to use a function that draws directly the RGB image.

[Sheepdog]

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.)

[circular]

Maybe it will be easier with BGRABitmap. Here is an example:
http://wiki.lazarus.freepascal.org/BGRABitmap_tutorial_4

So here instead of setting red, green, etc. individually, you can have an array of TBGRAPixel, and copy the value with the chosen index.

I don't see any way you could change the colors without redrawing them, at least at a high level of programming and without OS specific stuff.

[engkin]

This is driver/hardware related. You can see similar functions when changing your monitor's Gamma/Brightness/Contrast in:
Display Properties - Settings - Advanced - if supported by your driver.

You *might* have similar control under DirectX/OpenGL.

[Never]

is this what are you looking for?
[ http://wiki.freepascal.org/Fast_direct_pixel_access ]

[Syndrome]

Your problem is that you do not want to

scan the whole bitmap and re-draw any green pixels.

modern OS does not use color table
there is no way to show changed pixel without redrawing
i guess your Archimed just uses 8 bit color mode which is not supported by current hardware

[taazz]

Your problem is that you do not want to

scan the whole bitmap and re-draw any green pixels.

modern OS does not use color table
there is no way to show changed pixel without redrawing
i guess your Archimed just used 8 bit color mode which is not supported by current hardware

yes it does it is called a palette and can be assigned to any device/bitmap you want (in windows at least), but that does not change the fact that redrawing is required every time you change the palette.

[Syndrome]

that does not change the fact that redrawing is required every time you change the palette

i am sure that redrawing isnt needed if the video card works in 8 bit mode.
windows emulates the palette. Native support is completely different thing

[taazz]

that does not change the fact that redrawing is required every time you change the palette

i am sure that redrawing isnt needed if the video card works in 8 bit mode.
windows emulates the palette. Native support is completely different thing

Actually I think that windows emulates only if the system is set to 24/32 bit and your application requests a palleted device if the system is set to 8bit/256 colors then it is native but then again a redraw is also required and has nothing to do with the native/emulated part of the system.