PanoTools:
Re: Re: Not PTGui - Question on Fspviewer Maximum File Size
Fulvio Senore 2005-Sep-18 12:30:13
stevenkan ha scritto:
>--- In #removed#, Fulvio Senore <#removed#> wrote:
>
>
>>your file will use more than 1.2
>>GB of ram just to store it. You will need such a block of free memory
>>
>>
>to
>
>
>>open the file, plus some more for other tasks.
>>
>>FSPViewer should not have memory limitations by itself: it will try
>>
>>
>to
>
>
>>allocate the needed memory from Windows and it will report an error
>>
>>
>if
>
>
>>Windows will not be able to allocate it. I am not an expert but you
>>might have more memory in your computer but, if it is fragmented,
>>Windows might not be able to find a single block of contiguous memory
>>large enough.
>>
>>
>
>I have had some experience managing a sw project that uses huge amounts
>of memory. In most versions of Windows a userland application can only
>see a 31-bit address space, or 2 GB. The uppermost address bit is
>reserved by Windows.*
>
>Furthermore, due to the way our app and several DLLs got loaded, we
>were _never_ able to malloc() more than about 1.23 GB, even if we
>thought we should have had a larger contiguous block available.
>
>At that point we stopped worrying about it and implemented a paging
>routine, since we were moving onto 4 GB and 6 GB datasets, which were
>going to be a problem in any case.
>
>So I suspect that you will want to implement some sort of paging
>routine sooner rather than later.
>
>* Server versions of Windows allegedly make more RAM available to apps,
>but I suspect that's mostly a moot point for most/all of your targeted
>users. Ditto for 64-bit Windows, at least for several more years.
>
>
>
Thank you for your information, they are very valuable. I don't know if
it is worth implementing a paging routine for the viewer, because having
to read the image from disk in real time would make panning very jerky
and unresponsive. When looking at large images at normal fields of view
the viewer would need to load an enormous amount of data in order to
compute a view.
Maybe a better solution would be using a multiresolution file format:
keep a smaller image in ram for panning at wide fov, and load high
resolution data on the fly when needed. I will have to think about it.
Fulvio Senore
------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/.Cr1lB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/PanoTools/
<*> To unsubscribe from this group, send an email to:
#removed#
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/