Native support for jpeg files in Windows
in [Win32 API]
|
Prev: Using CFSTR_FILEDESCRIPTOR/CFSTR_FILECONTENTS shell format
Next: How to bring an Application to front
From: Lucian Wischik on 23 Nov 2006 14:42 Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote: >Since I am really interested in obtaining bits not HBITMAP, any method >that requires using a DC is not perfect. In my code I put the bitmap >into DC and call GetDIBits. The problem will be if the DC is 16 or 8 >bits. This will hit the quality. I quess using CreateDIBSection and >BitBlting trough display's compatible DC as you do it will have the same >result. I don't think it will. If you create a 24bpp DIBSection then it'll be 24bpp regardless of the current display mode. To obtain the raw bits, use either the *ppvBits that was given back to you by CreateDIBSection, or use DIBSECTION dibs; GetObject(hbm,&dibs,sizeof(dibs)); dibs.whatever.ppvBits. -- Lucian
From: Grzegorz Wróbel on 23 Nov 2006 15:15 Lucian Wischik wrote: > Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote: >> Since I am really interested in obtaining bits not HBITMAP, any method >> that requires using a DC is not perfect. In my code I put the bitmap >> into DC and call GetDIBits. The problem will be if the DC is 16 or 8 >> bits. This will hit the quality. I quess using CreateDIBSection and >> BitBlting trough display's compatible DC as you do it will have the same >> result. > > I don't think it will. If you create a 24bpp DIBSection then it'll be > 24bpp regardless of the current display mode. To obtain the raw bits, > use either the *ppvBits that was given back to you by > CreateDIBSection, When you blitblt from one hbitmap to another then during this operation colordepth will be reduced to current DC's. Sure I'll get bits in 24bpp data format, but if the DC was 8bit it won't be there more than 256 unique colors there. > or use DIBSECTION dibs; > GetObject(hbm,&dibs,sizeof(dibs)); dibs.whatever.ppvBits. I tried this and suprisingly it was 8bits in 8bpp mode, even though HDC was never used explicitly since I copied hbitmap from IPicture using CopyImage(). -- Grzegorz Wr�bel http://www.4neurons.com/ 677265676F727940346E6575726F6E732E636F6D
From: Grzegorz Wróbel on 23 Nov 2006 15:54 Grzegorz Wr�bel wrote: > news(a)rtrussell.co.uk wrote: >> OleLoadPicturePath(wpath,NULL,NULL,NULL,IID_IPicture,(LPVOID*)&ipic); > .... > path or I forgot to get adress of &ipicture). I try to compile version > with OleLoadPicturePath as well, should a bit shorter. It works now - 6 lines of code now instead of 19 and 3 variables less :) -- Grzegorz Wr�bel http://www.4neurons.com/ 677265676F727940346E6575726F6E732E636F6D
From: news@rtrussell.co.uk on 23 Nov 2006 16:47 Grzegorz Wróbel wrote: > When you blitblt from one hbitmap to another then during this operation > colordepth will be reduced to current DC's. Sure I'll get bits in 24bpp > data format, but if the DC was 8bit it won't be there more than 256 > unique colors there. Indeed: it's a shortcoming of Windows that I've never been able to overcome. As you say, even if there is no explicit reference to any DC the current display settings limit the color depth you end up with. It's completely insane, and if anybody knows a way to overcome it (short of bypassing the API completely) I would be very interested. It's hard to understand the processes going on 'under the hood' that lead to this behavior. Fortunately it's less of a problem than it once was because display color depths of fewer than 24 bits are becoming increasingly rare. Richard. http://www.rtrussell.co.uk/ To reply by email change 'news' to my forename.
From: Grzegorz Wróbel on 24 Nov 2006 06:46
news(a)rtrussell.co.uk wrote: > Grzegorz Wr�bel wrote: >> When you blitblt from one hbitmap to another then during this operation >> colordepth will be reduced to current DC's. Sure I'll get bits in 24bpp >> data format, but if the DC was 8bit it won't be there more than 256 >> unique colors there. > > Indeed: it's a shortcoming of Windows that I've never been able to > overcome. As you say, even if there is no explicit reference to any DC > the current display settings limit the color depth you end up with. > It's completely insane, and if anybody knows a way to overcome it > (short of bypassing the API completely) I would be very interested. > It's hard to understand the processes going on 'under the hood' that > lead to this behavior. I think it's not possible if you're using GDI object. I was thinking once about creating 32bit memory DC and perform operatons in memory using these DC, but a) it's not easy to create such DC without having an actual device that supports it b) since some functions use current display's colordepth implicitly this probably wouldn't work anyway. > > Fortunately it's less of a problem than it once was because display > color depths of fewer than 24 bits are becoming increasingly rare. Indeed, and the 8bit mode is officially not supported anymore (though one can still change to this mode using ChangeDisplaySettings() API). -- Grzegorz Wr�bel http://www.4neurons.com/ 677265676F727940346E6575726F6E732E636F6D |