3982 is NOT the maximum number, just the largest number we have tested. The steady memory usage indicates the maximum number is much, much higher than 3982.
One thing to note..... There is a bug in Microsoft's XP x32 operating system affecting very large file creation. Our conversations with Microsoft have lead to the conclusion the bug was introduced between XP SP1 and XP SP2. The bug keeps the operating system from supporting very large files. The maximum file size you can create depends on your system configuration. The largest we have heard of is 70GB. Most systems cannot exceed 35GB.
We have tried rolling back the XP operating systems back to SP1, or back to the original Windows XP, but that has not been successful. Once Windows XP SP2 is loaded, something is not being unloaded. This is a puzzle for both ERDAS and Microsoft.
What is the solution for large file creation in ERDAS IMAGINE 9.3.x? Use Windows XP x64 or Windows Vista. ERDAS will expand operating system support for ERDAS IMAGINE 2010, the versions to be announced later.
** A post-post clarification, if I may. I received a few emails concerning the XP x32 file size limit. This limit is not related to any specific file format. Rather, it is limited to the operating system not allowing the creation of a single large file of any type. Again, there are some variations, but if you need large files of any type you must move from Windows XP x32. For all its bad press, Vista x32 does not have this problem.
5 comments:
I guess this is a good place to comment. It is nice to create a large file like this. However what happens when a small or large part of the file gets corrupt, for instance in file transfer from disk to disk or disk to ftp etc? My question is in general for any Raster format (TIF, MrSID, JPG, ECW etc..) I guess you can only answer the MrSID side of these questions:
1. What is done for checking a large file for errors?
2. With small errors, an the file still be operated without ANY form of crash of applications viewing it?
3. With large errors, can the file be operated withouth ANY form of crash of applications viewing it?
4. Is it possible in some way to fix a damaged file using some sort of linear interpolation or other algorithm to the damaged area?
Keep up the good work with this blog!
I asked for some help on this from an engineer stong in software architecture. Here are his thoughts:
---
Some good questions and the answers are not easy. It very much depends upon the file format and the nature of problem. In this discussion it sounds like he is talking about some type of file corruption which may be due to either erroneous software operation or failing hardware. In either case it is not just the data (i.e. the pixels) that may be bad, it is also the file infrastructure that tells where data is. So very broadly you could classify the corruption into one of two categories:
1) Data Corruption
2) Format Corruption
If the Data is corrupted, the first problem is to detect that. How do you know if some of the pixels are wrong, since in most images any of the possible pixel values are valid? You could perhaps but a checksum (as he mentions) on the data. However, to then detect that there is an error requires that one recomputed the checksum on the whole of the image. Of course one could compute checksums at the block level, this would make it easier and quicker to compute and check. This however, requires that the format have a place for such a checksum.
For format corruption, you have an even more difficult problem in some ways. This is very format specific and this type of logic would have to built in at the raster format DLL level of every format. The developer would have to determines means of detecting corrupt file infrastructure and dealing with it.
It would seem that this type of corruption detection and prevention is best left up to the operating system layer.
But he is correct, that as we commit more and more of our imagery to a single file we have to have means of protecting it.
---
So, he and I will debate this issue some more and maybe, just maybe if I ever get the go ahead for .img x64, we will include these ideas.
There are other operating systems that are robust with large file support that you can customize to work well with your software. Why stick with a black box that you can't fix as your base work environment?
I assume you are not only referring to Microsoft Windows XP x32 but to Microsoft Windows operating system in general, is that correct? The best technology does not always when the market-share war, without proper marketing and sales efforts, great technology will never be perceived as beneficial.
ERDAS responds to customer demands, because 96% of ERDAS customer and new-market demand for ERDAS products to run on Microsoft operating systems, we focus on Microsoft operating systems.
My vote is for Windows 7-64 bit. While I did not have many issues with Vista-64, 7-64 loads faster and has some nice new features. All the geospatial apps we use, including IMAGINE 2010, work without a hitch on 7-64.
Post a Comment