Problem with large tiff files

[=?Utf-8?B?dGtpZWhs?=]

I have large 1bpp tiff scans of arch. drawings that are typically 12032x16890
pixels (filesize is about a 1 meg +/-)

While I can readily view smaller (dimension) files, when I try to do
anything after loading

I've looked at most of the samples on the web in using GDI+... they all fall
over dead with these large files.

Any help is appreciated.

[Peter Duniho]

On Sun, 13 Jan 2008 21:35:00 -0800, tkiehl
<tk****@discuss ions.microsoft. comwrote:

I have large 1bpp tiff scans of arch. drawings that are typically
12032x16890
pixels (filesize is about a 1 meg +/-)

While I can readily view smaller (dimension) files, when I try to do
anything after loading

Did you mean to complete that thought?

I've looked at most of the samples on the web in using GDI+... they all
fall
over dead with these large files.

It sounds as though even though the files are monochrome, when .NET tries
to load them it's trying to make a full-color image. And of course
12Kx17K at 24bpp is pretty huge. I'm not aware of any way to control the
internal format of an Image instance initialized from a file. You may
have to handle the loading yourself, by creating an appropriate 1 bpp
monochrome Bitmap instance, using LockBits to get the buffer, and read the
file data in explicitly, copying to the image's buffer.

Pete

[=?Utf-8?B?dGtpZWhs?=]

Pete,

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.

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". 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.GetHBITM AP which fails on the big
files (I could be wrong here).

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.

TK

"Peter Duniho" wrote:

On Sun, 13 Jan 2008 21:35:00 -0800, tkiehl
<tk****@discuss ions.microsoft. comwrote:

I have large 1bpp tiff scans of arch. drawings that are typically
12032x16890
pixels (filesize is about a 1 meg +/-)

While I can readily view smaller (dimension) files, when I try to do
anything after loading

Did you mean to complete that thought?

I've looked at most of the samples on the web in using GDI+... they all
fall
over dead with these large files.

It sounds as though even though the files are monochrome, when .NET tries
to load them it's trying to make a full-color image. And of course
12Kx17K at 24bpp is pretty huge. I'm not aware of any way to control the
internal format of an Image instance initialized from a file. You may
have to handle the loading yourself, by creating an appropriate 1 bpp
monochrome Bitmap instance, using LockBits to get the buffer, and read the
file data in explicitly, copying to the image's buffer.

Pete

[Peter Duniho]

On Mon, 14 Jan 2008 00:14:00 -0800, tkiehl
<tk****@discuss ions.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.GetHBITM AP 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