problem in GUI
problem in GUI
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.
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.
Re:problem in GUI
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.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:problem in GUI
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.
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.
Re:problem in GUI
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.
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.
Re:problem in GUI
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.
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.
Re:problem in GUI
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.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.
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...
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:problem in GUI
true ... i forgot this.mystran wrote: Other more creative solutions have been used in many oldschool demos,(...), and using more than one real pixel for each virtual pixel.
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\ ...
However, in a GUI, you're likely to prefer pixel precision to colour count ...
Re:problem in GUI
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.
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.
Re:problem in GUI
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.shahzad wrote: So i can replace those colors with colors of 2nd picture.
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.
Re:problem in GUI
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.
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.
Re:problem in GUI
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).
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).