On Mon, 14 Jan 2008 00:14:00 -0800, tkiehl
<tk****@discussions.microsoft.comwrote:
In my current (working) version of the app, I'm using straight GDI and a
third party library to initally read in the file, then I move/scale it
over
dibsections and all is good.
I'd like to use the gdi+ and get rid of the 3rd party library.
But the 3rd party library is providing functionality that .NET doesn't
offer.
Problem is, I can't get at the bits because (it appears to be as you say)
the gdi+ bitmap has already "done something to them".
I didn't say the bitmap has already "done something to them". I said that
..NET is creating a full-color bitmap even though the file is monochrome.
If I could get to the
bits, I'd be a happy camper, but I think I need to first get the handle
to
the GDI bitmap with the GDI+ call Bitmap.GetHBITMAP which fails on the
big
files (I could be wrong here).
I think you are wrong. The monochrome bits are likely never in the
bitmap. .NET is likely reading the data straight from the file and
converting it immediately before putting it into the bitmap.
You will need to "get to the bits" by reading the file yourself. This
would essentially involve rewriting the functionality of your 3rd party
library. The TIFF file format is not complicated, and this would not be
difficult to do, but you might want to consider just using the 3rd party
library via p/invoke to deliver a monochrome HBITMAP that you can use to
initialize a .NET Bitmap instance.
You'll still have the dependency on the 3rd party library, but it will be
less effort than reading the file yourself.
This assumes that .NET will just wrap the HBITMAP rather than doing
something to convert it. I suspect that's the case, but if not then
you'll have to copy it into a Bitmap instance you've explicitly created to
be monochrome, again using p/invoke (get the DC from your new Bitmap and
use unmanaged GDI to draw the HBITMAP into the new Bitmap using the DC).
After all is said and done, you may find yourself wishing that you'd just
taken the time to learn the TIFF file format and import the bits directly
that way. :)
I have a sample that uses the GDI+ Image, but each time it wants to draw
onto the graphics, it takes way too long since it appears to have to
decode
+all+ the bits each time it draws. With my straight GDI version, once the
file is loaded and handed off to my dibsections it is fast with BitBlt
and
StretchBlt.
I doubt that the time is being spent "decoding" anything. By my
calculations, a 24bpp image the size you're talking about is roughly
600MB. It's likely that the time is simply all of that data being moved
back and forth to and from the swap file as it's needed. My guess is that
if you look at the disk activity while you're waiting for the bitmap to
draw, you'll notice significant activity.
Pete
