Prev: Using CFSTR_FILEDESCRIPTOR/CFSTR_FILECONTENTS shell format
Next: How to bring an Application to front
From: news@rtrussell.co.uk on 22 Nov 2006 17:09
Lucian Wischik wrote:
> DWORD red; ReadFile(hf,buf,size,&red,0);
> GlobalUnlock(hglob);
> hbm = LoadJpeg(hglob);

To read a JPEG from a file you can use OleLoadPicturePath directly,
rather than going to the trouble of using ReadFile and OleLoadPicture
separately. The only complication is that you must supply
OleLoadPicturePath with a pathname that is unambiguously a disk file
rather than a URL (e.g. by including the drive letter).

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.

From: xbunny on 22 Nov 2006 17:41
Grzegorz Wr?bel wrote:
> Does it exist? The documantation on standard GDI library and
> BITMPAPINFOHEADER mentions BI_JPEG and BI_PNG compression types but I
> never saw a working code that would took advantage of that. Seems they
> never finished this.

I have used the BI_JPEG facility a long time ago, its not supported by
the normal GDI screen graphics (or at least it wasnt then) but certain
print drivers support it (I used a tektronics phaser printer with a
postscript print driver). It is very useful rather than having to
decompress a potentially huge image and send it as hundreds of megabytes
of raw rgb to the printer you can send the jpeg data directly (with
StretchDIBits) and the printer will decompress it internally. Theres a
pretty vague example at:
http://msdn2.microsoft.com/en-us/library/ms532320.aspx

So anyways it is finished just it probably doesnt help you in this respect.

Bunny

From: Grzegorz Wróbel on 22 Nov 2006 20:04
xbunny wrote:
> Grzegorz Wr?bel wrote:
>> Does it exist? The documantation on standard GDI library and
>> BITMPAPINFOHEADER mentions BI_JPEG and BI_PNG compression types but I
>> never saw a working code that would took advantage of that. Seems they
>> never finished this.
>
> I have used the BI_JPEG facility a long time ago, its not supported by
> the normal GDI screen graphics (or at least it wasnt then) but certain
> print drivers support it (I used a tektronics phaser printer with a
> postscript print driver). It is very useful rather than having to
> decompress a potentially huge image and send it as hundreds of megabytes
> of raw rgb to the printer you can send the jpeg data directly (with
> StretchDIBits) and the printer will decompress it internally. Theres a
> pretty vague example at:
> http://msdn2.microsoft.com/en-us/library/ms532320.aspx
>
> So anyways it is finished just it probably doesnt help you in this respect.
>

I've seen this example, what hit me there is no way to obtain width and
height of the original image, that's perhaps why it is useful only for
printing.

--
Grzegorz Wr?bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
From: Grzegorz Wróbel on 22 Nov 2006 20:22
news(a)rtrussell.co.uk wrote:
> Lucian Wischik wrote:
>> DWORD red; ReadFile(hf,buf,size,&red,0);
>> GlobalUnlock(hglob);
>> hbm = LoadJpeg(hglob);
>
> To read a JPEG from a file you can use OleLoadPicturePath directly,
> rather than going to the trouble of using ReadFile and OleLoadPicture
> separately. The only complication is that you must supply
> OleLoadPicturePath with a pathname that is unambiguously a disk file
> rather than a URL (e.g. by including the drive letter).
>
> Richard.
> http://www.rtrussell.co.uk/
> To reply by email change 'news' to my forename.
>

Full path is not that trouble, however I can't get OleLoadPicturePath
working. I just successfully compiled first working version using
ReadFile + CreateStreamOnHGlobal + OleLoadPicture that converts jpg to
bmp :).

I think I can get shorter code than Lucian's, including converting to
DIB and saving. ;)

--
Grzegorz Wr?bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
From: Grzegorz Wróbel on 22 Nov 2006 23:40
Lucian Wischik wrote:
....
> // Now we make a copy of it into our own hbm
> DIBSECTION dibs; GetObject(hbm0,sizeof(dibs),&dibs);
> int w=dibs.dsBm.bmWidth, h=dibs.dsBm.bmHeight;
> dibs.dsBmih.biClrUsed=0; dibs.dsBmih.biClrImportant=0; void *bits;
> HDC sdc=GetDC(0);
> HBITMAP
> hbm1=CreateDIBSection(sdc,(BITMAPINFO*)&dibs.dsBmih,DIB_RGB_COLORS,&bits,0,0);
> //
> HDC hdc0=CreateCompatibleDC(sdc), hdc1=CreateCompatibleDC(sdc);
> HGDIOBJ hold0=SelectObject(hdc0,hbm0),
> hold1=SelectObject(hdc1,hbm1);
> BitBlt(hdc1,0,0,w,h,hdc0,0,0,SRCCOPY);

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.

The question is: how to ensure I get 24bpp quality even if current
display mode is 16 or 8 bits?


--
Grzegorz Wr?bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Using CFSTR_FILEDESCRIPTOR/CFSTR_FILECONTENTS shell format
Next: How to bring an Application to front