Setting the ColorDepth EncoderParameter to GDI+ Image::Save() ???
in [MFC]
|
From: Peter Olcott on 2 Mar 2010 12:12 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message news:AMWdnZ1zNYHmphDWnZ2dnUVZ_vKdnZ2d(a)giganews.com... > > "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in > message news:ii9qo55tp4n081ap7f2mlo32c87isfks2i(a)4ax.com... >> Did you look at Image::GetEncoderParameterList? And >> things it refers to? >> >> You've got to overcome this trauma of seeing things in >> one language and blanking out with >> respect to other languages. The WinMain/OnInitInstance >> is another example. This is >> day-one MFC instruction. >> >> If you see a managed-code interface, there's a good >> chance there is a non-managed >> interface somewhere that does the same thing, so you look >> for similar names. You'll >> usually find something similarly-named in unmanaged code, >> since GDI+ is unmanaged code. >> For example, just look at the GDI+ documentation (note: >> it has its own problems of being >> poor, but it does appear to be reasonably complete). >> Sometimes the unmanaged interfaces >> are a bit clunky, and the managed code interfaces are >> pretty cosmetic wrappers, but all >> the functionality is there. > > Between the terabytes cost and the learning curve cost it > would be probably hundreds fold cheaper for MSDN to simply > publish a concrete example of every little thing > (elemental library operation) in every language. Starting > with a working example takes a few minutes, having to > transform examples in the wrong language by trial and > error takes at least many hours and sometimes several > days, Even when this is completed, one is unsure if the > solution is really correct, and not just something that > happens to work some of the time. > > One of the examples that I found concluded that the > transformation from 24-bit to 8-bit bitmaps is not > supported, and instead transformed the 24-bit bitmap to a > GIF, and then the GIF to a bitmap. This became the > recommended best solution, simply because the > documentation is so bad. Whoops. It looks like the ColorDepth parameter is only supported on the TIFF image type, thus converting to GIF or TIFF and another conversion to BMP or PNG is the only way to convert from 24-bit BMP or PNG to 8-bit BMP or PNG. When looking back at the GetDIBits() function it seems that this conversion might unnecessarily lose colors. If the original 24-bit BMP or PNG only has 256 unique colors, you may not get these same colors back when converting a 24-bit image to an 8-bit image. Windows likes to reserve some of these colors for itself. Is there a way to force a set of 256 unique colors in a 24-bit bitmap to be converted to these same colors in an 8-bit indexed bitmap? > >> >> I typed "GetEncoder" into the MSDN, found a bunch of >> methods, rejected the ones that were >> managed code, ran across Image::GetEncoderParameterList, >> synced-to-contents, and saw a >> couple interesting things. This is a pretty elementary >> search technique. >> joe >> >> On Mon, 1 Mar 2010 22:36:15 -0600, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>news:h8SdnVSVmNPvDxHWnZ2dnUVZ_qadnZ2d(a)giganews.com... >>>> >>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>> news:u6-dnbTpP9sE6RHWnZ2dnUVZ_vadnZ2d(a)giganews.com... >>>>> Setting the ColorDepth EncoderParameter to GDI+ >>>>> Image::Save() >>>>> >>>>> Status Save( >>>>> const WCHAR *filename, const CLSID *clsidEncoder, >>>>> const EncoderParameters *encoderParams >>>>> ); >>>>> >>>>> The only examples that I could find were incorrect >>>>> examples asking for correction and receiving none. >>>>> >>>> >>>> It looks like this is it: >>>> >>>> http://msdn.microsoft.com/en-us/library/system.drawing.imaging.encoder.colordepth.aspx >>>> >>> >>>No this is managed C++, so it is the wrong answer. >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > >
From: Joseph M. Newcomer on 3 Mar 2010 09:57 Since you know the 256 colors, why is it you cannot create your own 8-bit color map and do the conversion yourself? THen you can pass the 8-bit bitmap to whatever output routine you want. joe On Tue, 2 Mar 2010 11:12:57 -0600, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >news:AMWdnZ1zNYHmphDWnZ2dnUVZ_vKdnZ2d(a)giganews.com... >> >> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >> message news:ii9qo55tp4n081ap7f2mlo32c87isfks2i(a)4ax.com... >>> Did you look at Image::GetEncoderParameterList? And >>> things it refers to? >>> >>> You've got to overcome this trauma of seeing things in >>> one language and blanking out with >>> respect to other languages. The WinMain/OnInitInstance >>> is another example. This is >>> day-one MFC instruction. >>> >>> If you see a managed-code interface, there's a good >>> chance there is a non-managed >>> interface somewhere that does the same thing, so you look >>> for similar names. You'll >>> usually find something similarly-named in unmanaged code, >>> since GDI+ is unmanaged code. >>> For example, just look at the GDI+ documentation (note: >>> it has its own problems of being >>> poor, but it does appear to be reasonably complete). >>> Sometimes the unmanaged interfaces >>> are a bit clunky, and the managed code interfaces are >>> pretty cosmetic wrappers, but all >>> the functionality is there. >> >> Between the terabytes cost and the learning curve cost it >> would be probably hundreds fold cheaper for MSDN to simply >> publish a concrete example of every little thing >> (elemental library operation) in every language. Starting >> with a working example takes a few minutes, having to >> transform examples in the wrong language by trial and >> error takes at least many hours and sometimes several >> days, Even when this is completed, one is unsure if the >> solution is really correct, and not just something that >> happens to work some of the time. >> >> One of the examples that I found concluded that the >> transformation from 24-bit to 8-bit bitmaps is not >> supported, and instead transformed the 24-bit bitmap to a >> GIF, and then the GIF to a bitmap. This became the >> recommended best solution, simply because the >> documentation is so bad. > >Whoops. It looks like the ColorDepth parameter is only >supported on the TIFF image type, thus converting to GIF or >TIFF and another conversion to BMP or PNG is the only way to >convert from 24-bit BMP or PNG to 8-bit BMP or PNG. > >When looking back at the GetDIBits() function it seems that >this conversion might unnecessarily lose colors. If the >original 24-bit BMP or PNG only has 256 unique colors, you >may not get these same colors back when converting a 24-bit >image to an 8-bit image. Windows likes to reserve some of >these colors for itself. > >Is there a way to force a set of 256 unique colors in a >24-bit bitmap to be converted to these same colors in an >8-bit indexed bitmap? > >> >>> >>> I typed "GetEncoder" into the MSDN, found a bunch of >>> methods, rejected the ones that were >>> managed code, ran across Image::GetEncoderParameterList, >>> synced-to-contents, and saw a >>> couple interesting things. This is a pretty elementary >>> search technique. >>> joe >>> >>> On Mon, 1 Mar 2010 22:36:15 -0600, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >>>> >>>>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>>news:h8SdnVSVmNPvDxHWnZ2dnUVZ_qadnZ2d(a)giganews.com... >>>>> >>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>>> news:u6-dnbTpP9sE6RHWnZ2dnUVZ_vadnZ2d(a)giganews.com... >>>>>> Setting the ColorDepth EncoderParameter to GDI+ >>>>>> Image::Save() >>>>>> >>>>>> Status Save( >>>>>> const WCHAR *filename, const CLSID *clsidEncoder, >>>>>> const EncoderParameters *encoderParams >>>>>> ); >>>>>> >>>>>> The only examples that I could find were incorrect >>>>>> examples asking for correction and receiving none. >>>>>> >>>>> >>>>> It looks like this is it: >>>>> >>>>> http://msdn.microsoft.com/en-us/library/system.drawing.imaging.encoder.colordepth.aspx >>>>> >>>> >>>>No this is managed C++, so it is the wrong answer. >>>> >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm >> >> > 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:46 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:b0uso51ajcnc3f0fi5lfk8upmfc7a6nph7(a)4ax.com... > Since you know the 256 colors, why is it you cannot create > your own 8-bit color map and do > the conversion yourself? THen you can pass the 8-bit > bitmap to whatever output routine > you want. > joe (1) I don't know the tedious syntax for this. (2) Why do I have to force windows to NOT screw up the colors? > > On Tue, 2 Mar 2010 11:12:57 -0600, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>news:AMWdnZ1zNYHmphDWnZ2dnUVZ_vKdnZ2d(a)giganews.com... >>> >>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>> message >>> news:ii9qo55tp4n081ap7f2mlo32c87isfks2i(a)4ax.com... >>>> Did you look at Image::GetEncoderParameterList? And >>>> things it refers to? >>>> >>>> You've got to overcome this trauma of seeing things in >>>> one language and blanking out with >>>> respect to other languages. The WinMain/OnInitInstance >>>> is another example. This is >>>> day-one MFC instruction. >>>> >>>> If you see a managed-code interface, there's a good >>>> chance there is a non-managed >>>> interface somewhere that does the same thing, so you >>>> look >>>> for similar names. You'll >>>> usually find something similarly-named in unmanaged >>>> code, >>>> since GDI+ is unmanaged code. >>>> For example, just look at the GDI+ documentation (note: >>>> it has its own problems of being >>>> poor, but it does appear to be reasonably complete). >>>> Sometimes the unmanaged interfaces >>>> are a bit clunky, and the managed code interfaces are >>>> pretty cosmetic wrappers, but all >>>> the functionality is there. >>> >>> Between the terabytes cost and the learning curve cost >>> it >>> would be probably hundreds fold cheaper for MSDN to >>> simply >>> publish a concrete example of every little thing >>> (elemental library operation) in every language. >>> Starting >>> with a working example takes a few minutes, having to >>> transform examples in the wrong language by trial and >>> error takes at least many hours and sometimes several >>> days, Even when this is completed, one is unsure if the >>> solution is really correct, and not just something that >>> happens to work some of the time. >>> >>> One of the examples that I found concluded that the >>> transformation from 24-bit to 8-bit bitmaps is not >>> supported, and instead transformed the 24-bit bitmap to >>> a >>> GIF, and then the GIF to a bitmap. This became the >>> recommended best solution, simply because the >>> documentation is so bad. >> >>Whoops. It looks like the ColorDepth parameter is only >>supported on the TIFF image type, thus converting to GIF >>or >>TIFF and another conversion to BMP or PNG is the only way >>to >>convert from 24-bit BMP or PNG to 8-bit BMP or PNG. >> >>When looking back at the GetDIBits() function it seems >>that >>this conversion might unnecessarily lose colors. If the >>original 24-bit BMP or PNG only has 256 unique colors, you >>may not get these same colors back when converting a >>24-bit >>image to an 8-bit image. Windows likes to reserve some of >>these colors for itself. >> >>Is there a way to force a set of 256 unique colors in a >>24-bit bitmap to be converted to these same colors in an >>8-bit indexed bitmap? >> >>> >>>> >>>> I typed "GetEncoder" into the MSDN, found a bunch of >>>> methods, rejected the ones that were >>>> managed code, ran across >>>> Image::GetEncoderParameterList, >>>> synced-to-contents, and saw a >>>> couple interesting things. This is a pretty elementary >>>> search technique. >>>> joe >>>> >>>> On Mon, 1 Mar 2010 22:36:15 -0600, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>> >>>>>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>>>news:h8SdnVSVmNPvDxHWnZ2dnUVZ_qadnZ2d(a)giganews.com... >>>>>> >>>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in >>>>>> message >>>>>> news:u6-dnbTpP9sE6RHWnZ2dnUVZ_vadnZ2d(a)giganews.com... >>>>>>> Setting the ColorDepth EncoderParameter to GDI+ >>>>>>> Image::Save() >>>>>>> >>>>>>> Status Save( >>>>>>> const WCHAR *filename, const CLSID *clsidEncoder, >>>>>>> const EncoderParameters *encoderParams >>>>>>> ); >>>>>>> >>>>>>> The only examples that I could find were incorrect >>>>>>> examples asking for correction and receiving none. >>>>>>> >>>>>> >>>>>> It looks like this is it: >>>>>> >>>>>> http://msdn.microsoft.com/en-us/library/system.drawing.imaging.encoder.colordepth.aspx >>>>>> >>>>> >>>>>No this is managed C++, so it is the wrong answer. >>>>> >>>> Joseph M. Newcomer [MVP] >>>> email: newcomer(a)flounder.com >>>> Web: http://www.flounder.com >>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>> >>> >> > 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:56 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:b0uso51ajcnc3f0fi5lfk8upmfc7a6nph7(a)4ax.com... > Since you know the 256 colors, why is it you cannot create > your own 8-bit color map and do > the conversion yourself? THen you can pass the 8-bit > bitmap to whatever output routine > you want. > joe If I have a 24-bit HBITMAP, and I also have a std::vector<UINT> ColorIndex that contains the 256 colors in the order that I want (I want to reserve the Zero index for the background color) what is the syntax for creating an 8-bit HBITMAP, that uses my color table? (1) Somehow load whatever MS structure must hold the color index table. (2) Somehow create an HBITMAP with this loaded structure. (3) Somehow copy the 24-bit HBITMAP to the 8-bit HBITMAP. > > On Tue, 2 Mar 2010 11:12:57 -0600, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>news:AMWdnZ1zNYHmphDWnZ2dnUVZ_vKdnZ2d(a)giganews.com... >>> >>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>> message >>> news:ii9qo55tp4n081ap7f2mlo32c87isfks2i(a)4ax.com... >>>> Did you look at Image::GetEncoderParameterList? And >>>> things it refers to? >>>> >>>> You've got to overcome this trauma of seeing things in >>>> one language and blanking out with >>>> respect to other languages. The WinMain/OnInitInstance >>>> is another example. This is >>>> day-one MFC instruction. >>>> >>>> If you see a managed-code interface, there's a good >>>> chance there is a non-managed >>>> interface somewhere that does the same thing, so you >>>> look >>>> for similar names. You'll >>>> usually find something similarly-named in unmanaged >>>> code, >>>> since GDI+ is unmanaged code. >>>> For example, just look at the GDI+ documentation (note: >>>> it has its own problems of being >>>> poor, but it does appear to be reasonably complete). >>>> Sometimes the unmanaged interfaces >>>> are a bit clunky, and the managed code interfaces are >>>> pretty cosmetic wrappers, but all >>>> the functionality is there. >>> >>> Between the terabytes cost and the learning curve cost >>> it >>> would be probably hundreds fold cheaper for MSDN to >>> simply >>> publish a concrete example of every little thing >>> (elemental library operation) in every language. >>> Starting >>> with a working example takes a few minutes, having to >>> transform examples in the wrong language by trial and >>> error takes at least many hours and sometimes several >>> days, Even when this is completed, one is unsure if the >>> solution is really correct, and not just something that >>> happens to work some of the time. >>> >>> One of the examples that I found concluded that the >>> transformation from 24-bit to 8-bit bitmaps is not >>> supported, and instead transformed the 24-bit bitmap to >>> a >>> GIF, and then the GIF to a bitmap. This became the >>> recommended best solution, simply because the >>> documentation is so bad. >> >>Whoops. It looks like the ColorDepth parameter is only >>supported on the TIFF image type, thus converting to GIF >>or >>TIFF and another conversion to BMP or PNG is the only way >>to >>convert from 24-bit BMP or PNG to 8-bit BMP or PNG. >> >>When looking back at the GetDIBits() function it seems >>that >>this conversion might unnecessarily lose colors. If the >>original 24-bit BMP or PNG only has 256 unique colors, you >>may not get these same colors back when converting a >>24-bit >>image to an 8-bit image. Windows likes to reserve some of >>these colors for itself. >> >>Is there a way to force a set of 256 unique colors in a >>24-bit bitmap to be converted to these same colors in an >>8-bit indexed bitmap? >> >>> >>>> >>>> I typed "GetEncoder" into the MSDN, found a bunch of >>>> methods, rejected the ones that were >>>> managed code, ran across >>>> Image::GetEncoderParameterList, >>>> synced-to-contents, and saw a >>>> couple interesting things. This is a pretty elementary >>>> search technique. >>>> joe >>>> >>>> On Mon, 1 Mar 2010 22:36:15 -0600, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>> >>>>>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>>>news:h8SdnVSVmNPvDxHWnZ2dnUVZ_qadnZ2d(a)giganews.com... >>>>>> >>>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in >>>>>> message >>>>>> news:u6-dnbTpP9sE6RHWnZ2dnUVZ_vadnZ2d(a)giganews.com... >>>>>>> Setting the ColorDepth EncoderParameter to GDI+ >>>>>>> Image::Save() >>>>>>> >>>>>>> Status Save( >>>>>>> const WCHAR *filename, const CLSID *clsidEncoder, >>>>>>> const EncoderParameters *encoderParams >>>>>>> ); >>>>>>> >>>>>>> The only examples that I could find were incorrect >>>>>>> examples asking for correction and receiving none. >>>>>>> >>>>>> >>>>>> It looks like this is it: >>>>>> >>>>>> http://msdn.microsoft.com/en-us/library/system.drawing.imaging.encoder.colordepth.aspx >>>>>> >>>>> >>>>>No this is managed C++, so it is the wrong answer. >>>>> >>>> Joseph M. Newcomer [MVP] >>>> email: newcomer(a)flounder.com >>>> Web: http://www.flounder.com >>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>> >>> >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 4 Mar 2010 00:25 See below... On Wed, 3 Mar 2010 09:56:43 -0600, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:b0uso51ajcnc3f0fi5lfk8upmfc7a6nph7(a)4ax.com... >> Since you know the 256 colors, why is it you cannot create >> your own 8-bit color map and do >> the conversion yourself? THen you can pass the 8-bit >> bitmap to whatever output routine >> you want. >> joe > >If I have a 24-bit HBITMAP, and I also have a >std::vector<UINT> ColorIndex that contains the 256 colors in >the order that I want (I want to reserve the Zero index for >the background color) what is the syntax for creating an >8-bit HBITMAP, that uses my color table? > >(1) Somehow load whatever MS structure must hold the color >index table. **** Look at BITMAPINFOHEADER, BITMAPINFO **** >(2) Somehow create an HBITMAP with this loaded structure. **** Yes. In this case, you would typically use CreateDIBSection to create a bitmap of your desired color depth. **** >(3) Somehow copy the 24-bit HBITMAP to the 8-bit HBITMAP. **** Essentially, yes. Since you know the index of the color, you could simply do a direct lookup in the table and find the index. A bit of cleverness of encoding, such as using std::map and a cache of the most-recently-used 5 colors (or some other number) would probably give you substantial performance improvement. But it really is that simple. Then you write out the BITMAPINFOHEADER (which includes the color table) and the bits and you've got it. Of course, if you want to do PNG conversion, you could either use a PNG library or write the PNG code yourself. Depends on whether or not the PNG encoding buys you much. I did a lot of bitmap work in the mid-90s and even under WIn16 it wasn't all that hard. You just have to carefully read the docs. If your code involves a lot of runs, you could use RLE encoding, which has a pretty straightforward algorithm, but all my RLE code is in Win16, and somewhere I can't find. And no, I don't know why it changes the colors; it seems to be a serious error if it does so. joe **** > >> >> On Tue, 2 Mar 2010 11:12:57 -0600, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>news:AMWdnZ1zNYHmphDWnZ2dnUVZ_vKdnZ2d(a)giganews.com... >>>> >>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>> message >>>> news:ii9qo55tp4n081ap7f2mlo32c87isfks2i(a)4ax.com... >>>>> Did you look at Image::GetEncoderParameterList? And >>>>> things it refers to? >>>>> >>>>> You've got to overcome this trauma of seeing things in >>>>> one language and blanking out with >>>>> respect to other languages. The WinMain/OnInitInstance >>>>> is another example. This is >>>>> day-one MFC instruction. >>>>> >>>>> If you see a managed-code interface, there's a good >>>>> chance there is a non-managed >>>>> interface somewhere that does the same thing, so you >>>>> look >>>>> for similar names. You'll >>>>> usually find something similarly-named in unmanaged >>>>> code, >>>>> since GDI+ is unmanaged code. >>>>> For example, just look at the GDI+ documentation (note: >>>>> it has its own problems of being >>>>> poor, but it does appear to be reasonably complete). >>>>> Sometimes the unmanaged interfaces >>>>> are a bit clunky, and the managed code interfaces are >>>>> pretty cosmetic wrappers, but all >>>>> the functionality is there. >>>> >>>> Between the terabytes cost and the learning curve cost >>>> it >>>> would be probably hundreds fold cheaper for MSDN to >>>> simply >>>> publish a concrete example of every little thing >>>> (elemental library operation) in every language. >>>> Starting >>>> with a working example takes a few minutes, having to >>>> transform examples in the wrong language by trial and >>>> error takes at least many hours and sometimes several >>>> days, Even when this is completed, one is unsure if the >>>> solution is really correct, and not just something that >>>> happens to work some of the time. >>>> >>>> One of the examples that I found concluded that the >>>> transformation from 24-bit to 8-bit bitmaps is not >>>> supported, and instead transformed the 24-bit bitmap to >>>> a >>>> GIF, and then the GIF to a bitmap. This became the >>>> recommended best solution, simply because the >>>> documentation is so bad. >>> >>>Whoops. It looks like the ColorDepth parameter is only >>>supported on the TIFF image type, thus converting to GIF >>>or >>>TIFF and another conversion to BMP or PNG is the only way >>>to >>>convert from 24-bit BMP or PNG to 8-bit BMP or PNG. >>> >>>When looking back at the GetDIBits() function it seems >>>that >>>this conversion might unnecessarily lose colors. If the >>>original 24-bit BMP or PNG only has 256 unique colors, you >>>may not get these same colors back when converting a >>>24-bit >>>image to an 8-bit image. Windows likes to reserve some of >>>these colors for itself. >>> >>>Is there a way to force a set of 256 unique colors in a >>>24-bit bitmap to be converted to these same colors in an >>>8-bit indexed bitmap? >>> >>>> >>>>> >>>>> I typed "GetEncoder" into the MSDN, found a bunch of >>>>> methods, rejected the ones that were >>>>> managed code, ran across >>>>> Image::GetEncoderParameterList, >>>>> synced-to-contents, and saw a >>>>> couple interesting things. This is a pretty elementary >>>>> search technique. >>>>> joe >>>>> >>>>> On Mon, 1 Mar 2010 22:36:15 -0600, "Peter Olcott" >>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>> >>>>>> >>>>>>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>>>>news:h8SdnVSVmNPvDxHWnZ2dnUVZ_qadnZ2d(a)giganews.com... >>>>>>> >>>>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in >>>>>>> message >>>>>>> news:u6-dnbTpP9sE6RHWnZ2dnUVZ_vadnZ2d(a)giganews.com... >>>>>>>> Setting the ColorDepth EncoderParameter to GDI+ >>>>>>>> Image::Save() >>>>>>>> >>>>>>>> Status Save( >>>>>>>> const WCHAR *filename, const CLSID *clsidEncoder, >>>>>>>> const EncoderParameters *encoderParams >>>>>>>> ); >>>>>>>> >>>>>>>> The only examples that I could find were incorrect >>>>>>>> examples asking for correction and receiving none. >>>>>>>> >>>>>>> >>>>>>> It looks like this is it: >>>>>>> >>>>>>> http://msdn.microsoft.com/en-us/library/system.drawing.imaging.encoder.colordepth.aspx >>>>>>> >>>>>> >>>>>>No this is managed C++, so it is the wrong answer. >>>>>> >>>>> Joseph M. Newcomer [MVP] >>>>> email: newcomer(a)flounder.com >>>>> Web: http://www.flounder.com >>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>> >>>> >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: automation Excel running macro in XLA Next: MFC apps and multi video adapters |