large bitmaps for printing (GDI+)

large bitmaps for printing (GDI+)

Post by c2VtaGVsc » Thu, 13 Jan 2005 00:57:06


I need to draw a bitmap from CAD data and then print it in color (at least 16
bits) at 600DPI to a large page. The resulting bitmap can be as large as
20000 x 20000 pixels. What is the best way to work with these large images?
Is there some way to work with them in a compressed format? If you have an
image in .png format, can you draw to it with standard graphics methods while
the image is still compressed?
 
 
 

large bitmaps for printing (GDI+)

Post by Bob Powell » Thu, 13 Jan 2005 05:28:42

An image of this size is 1.6 gigabytes in size. There is no way to use such
an image in a compressed form. When images are loaded they are expanded to
their full 32 bpp size when they are first used.

You'd need a machine with at least 3 gigs of hard memory on board to even
think about printing this. 5 might be better.

AFAIK there are no numerical limits other than the size of the integer
values for the dimensions of a bitmap. the problems soon arise however when
bitmap size approaches available memory size.

I've never had the luxury of an n gigabyte computer system to test such
things.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.yqcomputer.com/

Answer those GDI+ questions with the GDI+ FAQ
http://www.yqcomputer.com/

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 
 
 

large bitmaps for printing (GDI+)

Post by c2VtaGVsc » Thu, 13 Jan 2005 07:17:05

Thanks for the response--but I have a couple of questions:

I'm not 'loading' an image from disk. I allocate a 16bpp bitmap and then
draw to it. Are you saying that at some point, it is stored at 32bpp
internally?

To generalize my original question a little--How do you print a CAD drawing
to postscript plotters (large page size) at good resolution without using
many gigs of memory?

I'm trying to print a bitmap image because there appears to be problem when
sending metafile data with transparency to postscript printers. I have
shapes drawn with different hatch brushes on different layers. If I use the
standard printing approach (drawing to e.graphics in the printdocument
routine) the transparency doesn't work. Microsoft has documented this issue
and recommends printing as an bitmap image.

So I'm drawing to a bitmap and then using e.graphics.drawimageunscaled in
the printdocument routine to print. As you point out, this uses a lot of
memory as the bitmaps get larger.

Will it help if I draw 1/4th of the image to a quarter size bitmap and then
call e.graphics.drawimageunscaled to draw the image in the upper left corner
and then draw another 1/4th of the image to the bitmap and call
e.graphics.drawimageunscaled to draw the image in the upper right corner,
etc. This way, I'm not allocating as large of a bitmap, but I'm not sure
about how the printing object allocates memory.

I don't have the luxury of a many gigibyte machine either--I just want a
good resolution plot. Any ideas?
 
 
 

large bitmaps for printing (GDI+)

Post by alejandro » Thu, 13 Jan 2005 09:00:04

would write to an EMF image.

<Unless you are drawing bitmaps> The lines and text you draw are stored as
instructions, not as bits in the image. And You can also scale the resulting
file!

best regards,
Alejandro Lapeyre


"semhelp" < XXXX@XXXXX.COM > escribien el mensaje
news: XXXX@XXXXX.COM ... >> Thanks for the response--but I have a couple of questions: >> >> I'm not 'loading' an image from disk. I allocate a 16bpp bitmap and then >> draw to it. Are you saying that at some point, it is stored at 32bpp >> internally? >> >> To generalize my original question a little--How do you print a CAD >> drawing >> to postscript plotters (large page size) at good resolution without using >> many gigs of memory? >> >> I'm trying to print a bitmap image because there appears to be problem >> when >> sending metafile data with transparency to postscript printers. I have >> shapes drawn with different hatch brushes on different layers. If I use >> the >> standard printing approach (drawing to e.graphics in the printdocument >> routine) the transparency doesn't work. Microsoft has documented this >> issue >> and recommends printing as an bitmap image. >> >> So I'm drawing to a bitmap and then using e.graphics.drawimageunscaled in >> the printdocument routine to print. As you point out, this uses a lot of >> memory as the bitmaps get larger. >> >> Will it help if I draw 1/4th of the image to a quarter size bitmap and >> then >> call e.graphics.drawimageunscaled to draw the image in the upper left >> corner >> and then draw another 1/4th of the image to the bitmap and call >> e.graphics.drawimageunscaled to draw the image in the upper right corner, >> etc. This way, I'm not allocating as large of a bitmap, but I'm not sure >> about how the printing object allocates memory. >> >> I don't have the luxury of a many gigibyte machine either--I just want a >> good resolution plot. Any ideas? >> >> >> "Bob Powell [MVP]" wrote: >> >>> An image of this size is 1.6 gigabytes in size. There is no way to use >>> such >>> an image in a compressed form. When images are loaded they are expanded >>> to >>> their full 32 bpp size when they are first used. >>> >>> You'd need a machine with at least 3 gigs of hard memory on board to even >>> think about printing this. 5 might be better. >>> >>> AFAIK there are no numerical limits other than the size of the integer >>> values for the dimensions of a bitmap. the problems soon arise however >>> when >>> bitmap size approaches available memory size. >>> >>> I've never had the luxury of an n gigabyte computer system to test such >>> things. >>> >>> -- >>> Bob Powell [MVP] >>> Visual C#, System.Drawing >>> >>> Find great Windows Forms articles in Windows Forms Tips and Tricks >>> http://www.bobpowell.net/tipstricks.htm >>> >>> Answer those GDI+ questions with the GDI+ FAQ >>> http://www.bobpowell.net/faqmain.htm >>> >>> All new articles provide code in C# and VB.NET. >>> Subscribe to the RSS feeds provided and never miss a new article. >>> >>> >>> >>> >>> >>> "semhelp"<< XXXX@XXXXX.COM >> wrote in message >>> news: XXXX@XXXXX.COM ... >>>>
 
 
 

large bitmaps for printing (GDI+)

Post by Bob Powell » Thu, 13 Jan 2005 16:18:33

one of the 16 bpp image formats work under GDI+. They are essentially
broken and were included in the system in error.

CAD drawings to plotters are usually defined in a vector graphics format
such as HP plotter format. These formats do not require gigabytes of storage
for even the most complex drawings.

If you have the possibility of breaking the drawing up into smaller chunks
then I think this is the only way that you're likely to have much success.


--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.





"semhelp" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

large bitmaps for printing (GDI+)

Post by c2VtaGVsc » Fri, 14 Jan 2005 00:31:09

'm currently using a 16bpp format (the RGB555 format) and it seems to work
OK. When I look at the task manager, my application seems to use a lot less
memory when using the 16bpp format vs. the 32bpp format. Is there something
in particular that doesn't work when using 16bpp?

I have had some problems using the 1,4,8 bpp indexed formats, but I haven't
looked into what is causing the problem.

"Bob Powell [MVP]" wrote: