Bitmap Size
-
a 32768x32768 32-bpp image requires 4GB of memory.
image processing toolkits | batch image processing | blogging
Yes, but 32768x1 1bpp is only 4Kb and that isn't supported either. I guess this means no abuse of bitmaps as a replacement for bit arrays right? Really, I could see where this would be a major issue if someone needed a fairly long and narrow bitmap, like a graph with history. The limit is less than 30 screen widths at my resolution (on a laptop.) So a long scrollable bitmap is just plain out for something like this. I don't see what MS big problem is. It would take them like 2 minutes to convert their decade old 16 bit size bytes to the 64 bit numbers of the new millennium. I very much doubt that ANYONE would hit the limits then.
-
Yes, but 32768x1 1bpp is only 4Kb and that isn't supported either. I guess this means no abuse of bitmaps as a replacement for bit arrays right? Really, I could see where this would be a major issue if someone needed a fairly long and narrow bitmap, like a graph with history. The limit is less than 30 screen widths at my resolution (on a laptop.) So a long scrollable bitmap is just plain out for something like this. I don't see what MS big problem is. It would take them like 2 minutes to convert their decade old 16 bit size bytes to the 64 bit numbers of the new millennium. I very much doubt that ANYONE would hit the limits then.
John Crenshaw wrote:
Yes, but 32768x1 1bpp is only 4Kb and that isn't supported either.
so, chop your image into multiple 32767x1 slices. that's still a ton of image data per bitmap.
John Crenshaw wrote:
I don't see what MS big problem is.
true. me either. but i don't work at MS and don't have access to the GDI source. there's probably a thousand 3rd party video and printer drivers out there based around that limit, too.
image processing toolkits | batch image processing | blogging
-
Yes, but 32768x1 1bpp is only 4Kb and that isn't supported either. I guess this means no abuse of bitmaps as a replacement for bit arrays right? Really, I could see where this would be a major issue if someone needed a fairly long and narrow bitmap, like a graph with history. The limit is less than 30 screen widths at my resolution (on a laptop.) So a long scrollable bitmap is just plain out for something like this. I don't see what MS big problem is. It would take them like 2 minutes to convert their decade old 16 bit size bytes to the 64 bit numbers of the new millennium. I very much doubt that ANYONE would hit the limits then.
You were right until here:
John Crenshaw wrote:
It would take them like 2 minutes to convert their decade old 16 bit size bytes to the 64 bit numbers of the new millennium.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
The images are actually gray scaled 8 bit. It is seismic data acquired by ships. The files are massive. One file is one line. A line may take up to 14 hours to run with a trace (each trace is a vertical line of pixels) of data coming in up to three or four times a second (depends on how "deep" the geologist wants to look). Most are either once or twice a second (so if firing once a second about 9 hours per bitmap) with 5000-15000 samples (depends on sampling frequency) per trace. Each sample is a pixel. The geologist would like zoom capability. I am working with already written specialty code. So thus finding the bitmap limit. Jim "You don't like it here, why don't take a job wrapping tomatoes" Rohan
I would save those large data files to a tiff file and subdivise the data in tiles in the tiff file. That could help your imaging software, you can then load only visible tiles, instead of the whole file
Maximilien Lincourt Your Head A Splode - Strong Bad
-
There is a size limit on bitmaps in VS2005 of 32767 (signed 2^16) pixels height and width, that is hard coded by Microsoft. I could find no documentation indicating it existed. Microsoft did admit it was there. Microsoft's response to queries about changing the limit to a default and allowing the user to set a higher limit or hard coding a higher limit... What are you smoking need a bitmap that size and unless more complaints come in we are going to nothing. Jim "You don't like it here, why don't take a job wrapping tomatoes" Rohan
I think the problem is the bitmaps are intended to be viewed and at that resolution they would be so horribly inefficient for that purpose that there is no point to extend this limit.
John
-
There is a size limit on bitmaps in VS2005 of 32767 (signed 2^16) pixels height and width, that is hard coded by Microsoft. I could find no documentation indicating it existed. Microsoft did admit it was there. Microsoft's response to queries about changing the limit to a default and allowing the user to set a higher limit or hard coding a higher limit... What are you smoking need a bitmap that size and unless more complaints come in we are going to nothing. Jim "You don't like it here, why don't take a job wrapping tomatoes" Rohan
You should also check the option to change the file format, for instance jpg. Another way could be that you divide the picture into subpictures to proceed. With so great pictures (>1 GB) you have performance problems on PCs, you should think about 64-bit Vista :cool:, because it can handle bigger files. Very interesting task. :rolleyes:
Greetings from Germany
-
You should also check the option to change the file format, for instance jpg. Another way could be that you divide the picture into subpictures to proceed. With so great pictures (>1 GB) you have performance problems on PCs, you should think about 64-bit Vista :cool:, because it can handle bigger files. Very interesting task. :rolleyes:
Greetings from Germany
It doesn't matter if it's a jpeg, it's of no value until it's turned into a bitmap, in memory.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
It doesn't matter if it's a jpeg, it's of no value until it's turned into a bitmap, in memory.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
I had recently a project with some background graphic elements. I am using jpegs because the need less space and it works fine. I think he has problems to handle big pictures...
Greetings from Germany
Sure, but in memory, they take up as much room as Bitmaps, because they have to BE Bitmaps in order to be drawn.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Sure, but in memory, they take up as much room as Bitmaps, because they have to BE Bitmaps in order to be drawn.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
because they have to BE Bitmaps in order to be drawn.
Not if you use directdraw but I guess you would want to uncompress the whole image for drawing in that case as well.
John
-
Sure, but in memory, they take up as much room as Bitmaps, because they have to BE Bitmaps in order to be drawn.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
There is a size limit on bitmaps in VS2005 of 32767 (signed 2^16) pixels height and width, that is hard coded by Microsoft. I could find no documentation indicating it existed. Microsoft did admit it was there. Microsoft's response to queries about changing the limit to a default and allowing the user to set a higher limit or hard coding a higher limit... What are you smoking need a bitmap that size and unless more complaints come in we are going to nothing. Jim "You don't like it here, why don't take a job wrapping tomatoes" Rohan
The files are generally in the 155 meg range, but can be from 125-260 meg. The pixel range is typically 5000-7000 by 15000-20000. It is an ocean seismic return, so each line of vertical pixels (a trace) is one sound shot and each pixel on that line is a return. The number of returns depends on the sampling frequency and the frequency of the sound (how far below ground a good return can come from) and the number of traces on how long the ship ran on one line and how often a shot was made. The want/need to zoom is asked for. If you double 20000 the bit map size is exceeded. At the moment the drawing is done on a pictureBox, which turns out not to be so bad as changing the bitmap is VERY bad. At the moment it is looking like the geologists will not be able zoom past 32000, as that is a simple fix. Time/money thing. Jim "You don't like it here, why don't take a job wrapping tomatoes" Rohan
-
Really??? Isnt that a task which will do the Graphic card with its driver, and only process the need (partial) area? :confused:
Greetings from Germany
If you're just using forms, to draw your image you'll need code like this: Bitmap bm = Bitmap.FromFile("myfile.jpg"); At this point the image has been loaded and takes as much room in memory as if it was a bmp.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
You were right until here:
John Crenshaw wrote:
It would take them like 2 minutes to convert their decade old 16 bit size bytes to the 64 bit numbers of the new millennium.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistPerhaps, but following the standard that they usually do for reverse compatibility, it would probably be very easy. Duplicate the structure and related code, convert the shorts that they are using to 64bit integers everywhere (trivial, how often do you REALLY use a short?) Put an Ex on the end of all the APIs so they don't break anything. Of course recompiling might be interesting. And any MS employee will loyally exclaim, "Oh the cost...and the testing...and the time...and the cost...and the cost...and heaven forbid we might break something..." Ignore the fact that they have money to blow on pattenting boxes of unpatentable garbage. Forget the fact that everything is late anyway. NM the fact that when testers report a bug, it gets the same treatment this one got. Don't bother with the statistics. Vista breaks 8% of XP software products AT IT'S BEST (figures from Microsoft.) What do they care about cost, time, testing, and breaking things? They only care when it's a good excuse to not listen to testers, or leave something broken. Like this. Sorry, I'm in a bad mood tonight.:mad: 3rd party might be an issue, I never thought of that, good point.
-
Perhaps, but following the standard that they usually do for reverse compatibility, it would probably be very easy. Duplicate the structure and related code, convert the shorts that they are using to 64bit integers everywhere (trivial, how often do you REALLY use a short?) Put an Ex on the end of all the APIs so they don't break anything. Of course recompiling might be interesting. And any MS employee will loyally exclaim, "Oh the cost...and the testing...and the time...and the cost...and the cost...and heaven forbid we might break something..." Ignore the fact that they have money to blow on pattenting boxes of unpatentable garbage. Forget the fact that everything is late anyway. NM the fact that when testers report a bug, it gets the same treatment this one got. Don't bother with the statistics. Vista breaks 8% of XP software products AT IT'S BEST (figures from Microsoft.) What do they care about cost, time, testing, and breaking things? They only care when it's a good excuse to not listen to testers, or leave something broken. Like this. Sorry, I'm in a bad mood tonight.:mad: 3rd party might be an issue, I never thought of that, good point.
John Crenshaw wrote:
Perhaps, but following the standard that they usually do for reverse compatibility, it would probably be very easy. Duplicate the structure and related code, convert the shorts that they are using to 64bit integers everywhere (trivial, how often do you REALLY use a short?) Put an Ex on the end of all the APIs so they don't break anything.
Heh. What you're describing is a new format, complete with new APIs to support them, all to support the relatively small population of developers who 1) need large bitmaps and 2) would prefer to use Microsoft's bitmap APIs rather than write their own. There's no hope of backwards compatibility, a very slim chance that most popular bitmap programs will be re-written to use a MS-specific large bitmap format anytime soon, and just about 0 chance that the average user will be understanding when their Win2k/XP machine crashes while trying to open .BMP files sent to them by their Vista using friends... I disagree with a lot of what MS is up to, but even i can't see how they could justify such a lost cause. ;)
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
If you're just using forms, to draw your image you'll need code like this: Bitmap bm = Bitmap.FromFile("myfile.jpg"); At this point the image has been loaded and takes as much room in memory as if it was a bmp.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
The files are generally in the 155 meg range, but can be from 125-260 meg. The pixel range is typically 5000-7000 by 15000-20000. It is an ocean seismic return, so each line of vertical pixels (a trace) is one sound shot and each pixel on that line is a return. The number of returns depends on the sampling frequency and the frequency of the sound (how far below ground a good return can come from) and the number of traces on how long the ship ran on one line and how often a shot was made. The want/need to zoom is asked for. If you double 20000 the bit map size is exceeded. At the moment the drawing is done on a pictureBox, which turns out not to be so bad as changing the bitmap is VERY bad. At the moment it is looking like the geologists will not be able zoom past 32000, as that is a simple fix. Time/money thing. Jim "You don't like it here, why don't take a job wrapping tomatoes" Rohan
It would help if you separated the Model/View in your head. The data is a 2 dimensional array of depth information. The view is the screen sized zoom the user is looking at. What you want is a bitmap extract function that can run at multiple zoom levels. There is a transition in the extraction algorithm at 1 to 1. It switches from multiple pixels per point to multiple points per pixel. You can probably insist on powers of 2 zoom levels. The big advantage of this is you only extract the bitmap you are actually going to display. My suggestion is that you use a semi-proprietary file form for the data, XML if file space is not an issue, something binary and compressed if it is. The format should allow at least one thumbnail to be attached. You can argue about what to attach, but an overall zoom to a small view (say 200x600) would probably me most useful for selecting files from a list. The file loader will create the needed array in memory (model), not an actual bitmap (view). Combining the model/view is a standard design error that routinely causes massive long term problem as you restrict the available metadata to what the view format will support.