problem in GUI

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
shahzad

problem in GUI

Post by shahzad »

i'm using svga mode 0x103.after displaying one bmp i reset the pallete to
display 2nd bmp.But resetting the pallete for 2nd bmp changes the colors of first bmp.
Please tell me how to display two pictures so that colors of first are not affected
when i display 2nd picture.
Brian_Provinciano

Re:problem in GUI

Post by Brian_Provinciano »

You can only have one palette on the screen at once. It's global for all pixels. If you want to display more than 256 colours at once, you must use an RGB video mode and scrap the palette code.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:problem in GUI

Post by Pype.Clicker »

in the old ages, ppl have found several "solutions" to this problems, either having a window manager that changes the palette when you switch between windows that have strong requirements (better have aspirine by your side), or look for the 'closest substitute' in a system palette.

I think Win3.11 was a mix of both, keeping a few 2^(3*k) colours "system" that would cover the whole 'rgb' space uniformly, and the rest of the colours being allocated dynamically to programs that request it.
Curufir

Re:problem in GUI

Post by Curufir »

Hmm, well I can think of a nice simple way if you don't mind the colours being slightly wrong.

Let's say the original image palette is in 8-bit RGB form.

The trick you have to pull off is just to translate 24-bit RGB down into 8-bit indexed palette without losing much colour information.

First convert to HSV instead of RGB (A quick google should give you the algorithm).

This gives us 3 numbers.

Hue (0->360)
Saturation (0->1)
Value (0->1)

Now we're going to use these values to create our 8-bit index number.

[first 4-bits are the Hue content]
Instead of a range of hue we're going to allow only 16 discrete hues to exist. So divide hue by 22.5 and round to the nearest integer (Do not just cut off the remainder). This is a circle so 16 = 0. This leaves you with a 4-bit value representing hue.

[next 2-bits are the Saturation]
Same as hue, we're not going to allow a range, we're going to allow 4 discrete saturation levels (0, 0.4, 0.8, 1.0). Convert the colour's saturation in the same way as before. This isn't linear simply because people, IMHO, don't tend to use many pastel colours for computer graphics.

[next 2-bits are the Value]
Do exactly the same as you did for the saturation. The reason for not using a linear range here is that below 0.4 things start and get quite dark which is again something not common in computer graphics.

This leaves you with the complete 8-bit palette index value.

[pre]
(0 ... 3) (4 ... 5) (6 ... 7)
H S V
[/pre]

Now all that remains is to make sure your OS sets up the 256 colour palette to represent those indices. My advice would be to write out the 256 possible numbers, calculate HSV for them, then use something like GIMP to figure out the RGB values for the palette (Or grab an HSV->RGB algorithm and do it yourself).

The beauty of this is that it's a simple matter to use any RGB depth you like throughout your whole OS. So long as you keep that depth constant all the translation is left as video mode specific. This means that when you finally get your OS running at a decent colour depth all you have to do is change the video driver to have everything work with more colours.

That solves your windows problem. The colours won't be perfect, but they'll be a decent approximation to the original 24-bit RGB values. Enough so that they will at least be coherent with the original image's scheme.
Curufir

Re:problem in GUI

Post by Curufir »

Hmm, been thinking a little more and there's a minor problem.

When H = 0 any value of S and V gives black
When S = 0 any value of H gives the same colour

So you end up actually choosing from a palette of something like 193 unique colours. I can live with that, if you can't then you'd have to alter the scheme to compensate.
mystran

Re:problem in GUI

Post by mystran »

Pype.Clicker wrote: in the old ages, ppl have found several "solutions" to this problems, either having a window manager that changes the palette when you switch between windows that have strong requirements (better have aspirine by your side), or look for the 'closest substitute' in a system palette.
Other more creative solutions have been used in many oldschool demos, including switching fast between two images with different coloring, and using more than one real pixel for each virtual pixel.
I'm not sure if switching palette in the middle of the physical drawing so as to have different palette for different parts of the screen (requires damn good timing) was ever done on PC.

Not that these tricks are realistic for a GUI. They make the image quality much worse and eat CPU...
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:problem in GUI

Post by Pype.Clicker »

mystran wrote: Other more creative solutions have been used in many oldschool demos,(...), and using more than one real pixel for each virtual pixel.
true ... i forgot this.
By allocating 64 colors for a red raster, 64 for blue and 64 for green, and using

Code: Select all

     RG/B\RG/B\
     .B/RG\B/RG\ ...
you can simulate a NxN 2^18 color display with 2Nx2Nx256 colors

However, in a GUI, you're likely to prefer pixel precision to colour count ...
shahzad

Re:problem in GUI

Post by shahzad »

another way that i found to overcome this problem is to
scan the least used colors in the picture.In the picture
that i displayed first has 30 colors that were never used
and quite a few were used just once.So i can replace those colors with colors of 2nd picture.
Curufir

Re:problem in GUI

Post by Curufir »

shahzad wrote: So i can replace those colors with colors of 2nd picture.
This is just putting off the inevitable. What happens when there are 3 windows, or 10? You'll rapidly run out of palette space and you're back to the initial problem.

I still say the way to do it is to just accept imprecision in the colours and come up with a decent conversion algorithm. Heck, it's being viewed on a computer monitor anyhow so you're already fighting against the user's monitor settings, background light, visual acuity etc. Worrying about colour precision is a waste of time for a GUI IMHO, the user will complain far more if the windows move slowly than if they aren't spot on colour-wise.
shahzad

Re:problem in GUI

Post by shahzad »

Curufir u r right in pointing out that replacement of least
used colors is not a good solution.I've to come up with some better solution like the one mentioned by u .
I'm thinking on your suggestion and on some other ways.
darklife

Re:problem in GUI

Post by darklife »

I suggest using dithering since it can be done fast and looks okay on a high res display. You could try to use colors that fall in the range of the original color and if there is no colors that are anything close then just use dithering on that specific area. This way you get the best of both worlds on low color displays.
You could let the user decide how much they will allow it to fall out of that "range".
If you need to paint a pixel with RGB 100,100,23 but the closes color you have on the palette is 100,95,25 then if it falls in a 10% range before dithering, you just use that color. If it falls outside of the range then change other colors around the pixel to be placed with near values but to offset the color so it becomes "dithered" to the image (without bothering the other pixels too much).
Post Reply