Re: Very Large Bitmaps
From: Bob Powell [MVP] (bob_at__spamkiller_bobpowell.net)
Date: 02/11/05
- Next message: Steve McLellan: "Re: Very Large Bitmaps"
- Previous message: Steve McLellan: "Re: Very Large Bitmaps"
- In reply to: Steve McLellan: "Re: Very Large Bitmaps"
- Next in thread: Steve McLellan: "Re: Very Large Bitmaps"
- Reply: Steve McLellan: "Re: Very Large Bitmaps"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 11 Feb 2005 14:52:16 +0100
I know that it's a considerable undertaking. I used to design high-end print
systems that worked with CMYK and different RGB / HSB colour spaces so I'm
leery about starting such a huge job. There's a definite need for it. I
don't think the Avalon stuff will be any better at handling huge images and
as Ahmed said, theres more and more applications that need this sort of
thing.
-- 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. "Steve McLellan" <sjm AT fixerlabs DOT com> wrote in message news:eAb81NDEFHA.3976@tk2msftngp13.phx.gbl... > And there was I, just about to ask if there were any such schemes in the > pipeline :-) > > I don't know if you've already considered it, but anything aimed at > serious image manipulation needs to be able to cope with different colour > spaces and 16-bit images etc without the horrible ambiguity and missing > implementations that the current GDI+ stuff has. We've been forced into > making the decision between dropping GDI+ or cutting down on product > features because some of the limitations. > > Just my 2! > > Steve > > "Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message > news:OfO87rCEFHA.2288@TK2MSFTNGP14.phx.gbl... >> This is such a hot issue that I have been thinking about it a lot >> recently. The GDI+ encoder/decoder systems are dedicated to working with >> whole images and are no use at-all for dealing with partial ones. What's >> needed is some custom code that will read these huge images in and create >> sets of tiles that subdivide the image so that portions of it are held in >> memory at any one time. >> >> There are no easy answers and it's just a case of getting on and writing >> the code to do it. Perhaps when I'm less busy it'll be a good thing to do >> for XRay tools. >> >> -- >> 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. >> >> >> >> >> >> "Ahmed Qurashi" <ahmedqurashi@gmail.com> wrote in message >> news:utb1PN%23DFHA.2572@tk2msftngp13.phx.gbl... >>> War and Peace only feels 24ft thick while one is waiting for Napoleon to >>> get >>> around to invading Moscow... >>> >>> Current texture limits for the latest gfx hardware are around 4096 x >>> 4096, >>> but by next generation (or next-next) that should get up to 16384 x >>> 16384. >>> In 64 bit architectures, 16GB RAM machines (with 16 TB of virtual >>> memory) >>> are already available so it seems ultra large images will soon be common >>> in >>> the gaming world as well as with satellite imagery, high res photo, etc. >>> >>> My question is what is the best algorithm, using managed code, to >>> subdivide >>> a very large (too large to read directly) bitmap into 1, 4, 16, 64 ... >>> tileable subimages? >>> >>> ok, >>> aq >>> >>> >>> "Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message >>> news:elS0BR9DFHA.2540@TK2MSFTNGP09.phx.gbl... >>>> The limits are being pushed on the hardware of your machine. >>>> >>>> A bitmap is loaded and expanded to an uncompressed raster so 18000 * >>>> 13000 >>> * >>>> 4 = 892 megabytes. In certain cases the machine might need twice this >>>> to >>>> work with an image. >>>> >>>> More memory will help, a bigger swop file might help, a dedicated >>> hard-disk >>>> that holds nothing but the swop file might help. Whatever happens it >>>> won't >>>> be acceptably fast for another decade. Mores law will eventually help >>>> you. >>>> >>>> The reason it's slow is because of the amount of data the machine needs >>>> to >>>> shift. People don't realize how much a few hundred megabytes is. >>>> >>>> A page of type in a programmers reference book is about 88 characters >>>> by >>> 36 >>>> lines per page. this is 3168 characters per page so 6336 per double >>>> side. >>>> This would make a book 147727 pages thick if you have 892 megabytes in >>>> it. >>>> Thats a book OVER TWENTY FOUR FEET thick if you cram the pages with >>>> characters and don't use any illustrations. >>>> >>>> You thought War and Peace was heavy going? Spare a thought for the poor >>>> computer that has to deal with huge images :-) >>>> >>>> -- >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> <emars@forwild.umass.edu> wrote in message >>>> news:1108067035.113555.36060@z14g2000cwz.googlegroups.com... >>>> > Greetings, >>>> > I am working with large bitmaps of 13,000x18,000 pixels and need to >>>> > do >>>> > some cropping at minimum. The code I use is fine for smaller bitmaps >>>> > but does not work for the large size bitmap, and gives an invalid >>>> > parameter error on the creation of the new Bitmap(**). The code >>>> > works >>>> > fine for smaller bitmaps up to 8,000x10,000 so I was unsure if I have >>>> > reached a limit of some sort? >>>> > >>>> > Thanks! >>>> > >>>> > Error Message: >>>> > "An unhandled exception of type 'System.ArgumentException' occurred >>>> > in >>>> > system.drawing.dll >>>> > >>>> > Additional information: Invalid parameter used." >>>> > >>>> > >>>> > //number of slices to crop the bitmap >>>> > numSplit = 2; >>>> > >>>> > for (int i = 0; i < numSplit; i++) >>>> > { >>>> > >>>> > >>>> > splitHeight = height/numSplit; >>>> > >>>> > **Bitmap half = new Bitmap(width, splitHeight); >>>> > >>>> > >>>> > //Create graphics drawing surface to redisplay the half img >>>> > Graphics h = Graphics.FromImage(half); >>>> > >>>> > //rectangle of location and size to copy >>>> > Rectangle m = new Rectangle(0, 0, width, height/numSplit); >>>> > >>>> > //create a graphic 'g' from the bounds of the rectangle 'r' of the >>>> > bitmap image 'img' >>>> > h.DrawImage(img,m,0,(0+(splitHeight*i)), width, >>>> > splitHeight,GraphicsUnit.Pixel); >>>> > >>>> > //name each half SPLIT plus 1 or 0 >>>> > string splitfile = "c:\\temp\\split"+i; >>>> > half.Save(splitfile+".jpg", System.Drawing.Imaging.ImageFormat.Jpeg); >>>> > h.Dispose(); >>>> > half.Dispose(); >>>> > >>>> > I am willing to accept that this size bitmap is too much to ask my >>>> > system (P4 1GB) but would prefer to hear it from somebody else :) >>>> > >>>> >>>> >>> >>> >> >> > >
- Next message: Steve McLellan: "Re: Very Large Bitmaps"
- Previous message: Steve McLellan: "Re: Very Large Bitmaps"
- In reply to: Steve McLellan: "Re: Very Large Bitmaps"
- Next in thread: Steve McLellan: "Re: Very Large Bitmaps"
- Reply: Steve McLellan: "Re: Very Large Bitmaps"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|