Setting the ColorDepth EncoderParameter to GDI+ Image::Save() ???
in [MFC]
|
From: Peter Olcott on 4 Mar 2010 01:43 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:plguo596uphuucafdndh7b0qvd0on0cmc2(a)4ax.com... > 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. CImage makes encoding and decoding PNG, BMP, TIFF, and GIF trivial. I am currently using a 256 * 256 matrix (indexed on red and green) of std::map as my lookup table. The C++ user group said that a binary search of std::vector is faster than an lookup in std::map, so I will probably be benchmarking this too. I don't think that a faster way can be derived for an ColorTable Index lookup without using the full 256 ^ 3 * 4 (64MB) of memory. > > 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
|
Pages: 1 2 3 Prev: automation Excel running macro in XLA Next: MFC apps and multi video adapters |