Forcing an optimized pallette when converting a 24-bit bitmap to 8-bit using GDI+
in [MFC]
|
From: Peter Olcott on 2 Mar 2010 16:42 I want to save 24-bit BMP images as 8-bit PNG files, where the number of unique colors <= 256. I don't want windows to automatically screw up the colors and use its own selections. I want to keep the original unique 256 colors, exactly as they are in the original. How do I force windows to not screw up the colors? Why isn't NOT screwing up the colors the default?
From: David Ching on 2 Mar 2010 21:37 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message news:Z9-dndJfg-fVGxDWnZ2dnUVZ_hOdnZ2d(a)giganews.com... > I want to save 24-bit BMP images as 8-bit PNG files, where the number of > unique colors <= 256. I don't want windows to automatically screw up the > colors and use its own selections. I want to keep the original unique 256 > colors, exactly as they are in the original. > > How do I force windows to not screw up the colors? Why isn't NOT screwing > up the colors the default? How is it "screwing up"? What code are you using to save the png's? -- David
From: Peter Olcott on 2 Mar 2010 21:45 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:ukIKupnuKHA.5812(a)TK2MSFTNGP02.phx.gbl... > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message > news:Z9-dndJfg-fVGxDWnZ2dnUVZ_hOdnZ2d(a)giganews.com... >> I want to save 24-bit BMP images as 8-bit PNG files, >> where the number of unique colors <= 256. I don't want >> windows to automatically screw up the colors and use its >> own selections. I want to keep the original unique 256 >> colors, exactly as they are in the original. >> >> How do I force windows to not screw up the colors? Why >> isn't NOT screwing up the colors the default? > > How is it "screwing up"? What code are you using to save > the png's? > > -- David I created a BMP file that has exactly 256 unique colors, I created a GIF file from this file using an optimized palette from an image editor. Both files were tested to have identical pixels. I got GDI+ to do the same thing, and both files did not have identical pixels. I researched this and found that others have had this same problem.
From: Joseph M. Newcomer on 3 Mar 2010 09:51 Note the following: "Pixels" as stored in the file are not pixel *values*. They are pixel *indexes*. So I can store my file with a color map of RGB(255, 0, 0) RGB(0, 255, 0) RGB(0, 0, 255) and my pixels might be 0, 1, 2, 0, 1, 2 But if I store the color map as RGB(0, 0, 255) RGB(255, 0, 0) RGB(0, 255, 0) then my file shows the pixel values as 1, 2, 0, 1, 2, 0 but they are the same image. So you have to say what you mean by "pixels". Are you talking about the rendering or the file contents? File contents do not have to be identical to get identical renderings. Next, you have to deal with color rendering. If the color map is stored in the file, you should *see* the same pixels as you stored. If you don't store the color map, one will be assumed for you. So your question is not clear. You would have to write a little program that extracted the color map and the pixel indices and indicated what was going on. Or look at my Image Comparator program. I know it gives me the color map for GIF files, try it for PNG files and see what it says. If GDI+ is doing something odd to the colors, that is probably a bug. But if you are looking at file bits, you have no idea what the pixels mean without the color map as well. joe On Tue, 2 Mar 2010 20:45:34 -0600, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message >news:ukIKupnuKHA.5812(a)TK2MSFTNGP02.phx.gbl... >> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >> news:Z9-dndJfg-fVGxDWnZ2dnUVZ_hOdnZ2d(a)giganews.com... >>> I want to save 24-bit BMP images as 8-bit PNG files, >>> where the number of unique colors <= 256. I don't want >>> windows to automatically screw up the colors and use its >>> own selections. I want to keep the original unique 256 >>> colors, exactly as they are in the original. >>> >>> How do I force windows to not screw up the colors? Why >>> isn't NOT screwing up the colors the default? >> >> How is it "screwing up"? What code are you using to save >> the png's? >> >> -- David > >I created a BMP file that has exactly 256 unique colors, I >created a GIF file from this file using an optimized palette >from an image editor. Both files were tested to have >identical pixels. I got GDI+ to do the same thing, and both >files did not have identical pixels. I researched this and >found that others have had this same problem. > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 3 Mar 2010 10:45
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:pftso551nm66g4m7pt087q710jgcuu7ter(a)4ax.com... > Note the following: > > "Pixels" as stored in the file are not pixel *values*. > They are pixel *indexes*. So I > can store my file with a color map of > > RGB(255, 0, 0) > RGB(0, 255, 0) > RGB(0, 0, 255) > > and my pixels might be 0, 1, 2, 0, 1, 2 > > But if I store the color map as > > RGB(0, 0, 255) > RGB(255, 0, 0) > RGB(0, 255, 0) > > then my file shows the pixel values as > 1, 2, 0, 1, 2, 0 > but they are the same image. So you have to say what you > mean by "pixels". Are you > talking about the rendering or the file contents? File > contents do not have to be > identical to get identical renderings. > > Next, you have to deal with color rendering. If the color > map is stored in the file, you > should *see* the same pixels as you stored. If you don't > store the color map, one will be > assumed for you. > > So your question is not clear. The original RGB(255, 0, 0) RGB(0, 255, 0) RGB(0, 0, 255) becomes RGB(253, 0, 0) RGB(0, 251, 0) RGB(0, 0, 252) How can I get Windows to quit screwing this up? The problem is that for legacy reasons it wants to make sure that certain colors are available even if they are not needed. It apparently keeps at least 20 colors for itself, thus merging the colors you specify if it needs to make room for its colors. > > You would have to write a little program that extracted > the color map and the pixel > indices and indicated what was going on. Or look at my > Image Comparator program. I know > it gives me the color map for GIF files, try it for PNG > files and see what it says. If > GDI+ is doing something odd to the colors, that is > probably a bug. But if you are looking > at file bits, you have no idea what the pixels mean > without the color map as well. > joe > > On Tue, 2 Mar 2010 20:45:34 -0600, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message >>news:ukIKupnuKHA.5812(a)TK2MSFTNGP02.phx.gbl... >>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>> news:Z9-dndJfg-fVGxDWnZ2dnUVZ_hOdnZ2d(a)giganews.com... >>>> I want to save 24-bit BMP images as 8-bit PNG files, >>>> where the number of unique colors <= 256. I don't want >>>> windows to automatically screw up the colors and use >>>> its >>>> own selections. I want to keep the original unique 256 >>>> colors, exactly as they are in the original. >>>> >>>> How do I force windows to not screw up the colors? Why >>>> isn't NOT screwing up the colors the default? >>> >>> How is it "screwing up"? What code are you using to >>> save >>> the png's? >>> >>> -- David >> >>I created a BMP file that has exactly 256 unique colors, I >>created a GIF file from this file using an optimized >>palette >>from an image editor. Both files were tested to have >>identical pixels. I got GDI+ to do the same thing, and >>both >>files did not have identical pixels. I researched this and >>found that others have had this same problem. >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |