As I understand it, and I may not have this exactly right, an OS will manage memory up to the amount of physical memory. Cpfind was using 2Gb but this would have been swapped in and out of disk by the OS. Some versions of Enblend have their own caching.
Certainly, there is a harder limit defined by the size of the paging file. On Linux systems this might 1.5x - 2x the physical RAM. On my Windows computer, with 24Gb physical RAM, it's only currently 9Gb. I think it expands if required, but I did a quick test and I could not allocate 32Gb, despite having plenty of disk space. So I think each process is limited to 24Gb, which may be partially on disk so that other processes can continue to run. That way, every process can have its own 24Gb, but no more. By bypassing that and generating memory mapped files (when allocating RAM files), Multiblend will be able to use as much "RAM" as there is disk space. On Friday, 12 February 2021 at 07:48:04 UTC GnomeNomad wrote: > Hmm, I remember ages ago producing a 768MB panorama. Not a gigapixel > size image, of course. But I did it from the command line on a 32-bit > processor with 2GB RAM, starting with using cpfind on full-size 6mpx > images. Just running cpfind on a single image used 2GB RAM. > > That just puts things in perspective. It took that little old laptop > about 8 hours to stitch the final panorama. That was using enblend back > then, of course. So apparently Linux was transparently managing memory > behind the scene. > > I understand Photoshop does its own memory management, but it dates back > to the days when it ran under OSes that had no real memory management. > > So why does an app like multiblend need to do its own memory management? > > On 2/11/21 9:21 AM, Monkey wrote: > > Output images that are bigger than RAM will be supported (on x64, at > > least; making the same available on x86 would be a /lot /more work). > > Input images that are bigger than RAM are not currently supported, but > > I'll see about adding that (if anyone's going to try blending gigapixel > > images together). It's done with plain memory mapped files rather than > > tiles. > > On Thursday, 11 February 2021 at 18:39:34 UTC gunter.ko...@gmail.com > wrote: > > > > gimp-like memory management that allows to handle target images that > > are bigger than the RAM. don't know if it is already implemented. > > > > The gimp splits big images into tiles that small enough so a few of > > them fit into the RAM and then tries to work on these tiles one at a > > time. > > > > On 11.02.21 18:33, Monkey wrote: > >> It's been several years but I'm working on a new version of > >> Multiblend that's a bit faster, produces much nicer results, and > >> will blend much bigger mosaics. > >> > >> Does anyone have any feature requests for a blender that I could > >> consider incorporating? > >> > >> Along the same lines, does anyone use Enblend's colour space > >> features? Do they produce notably more "correct" results, or just > >> different ones? I've added an approximately linear RGB mode to > >> Multiblend, but it doesn't seem to produce great results so I'll > >> only be leaving it there as a curiosity. > > > -- > David W. Jones > gnome...@gmail.com > wandering the landscape of god > http://dancingtreefrog.com > My password is the last 8 digits of π. > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/b152fafb-bf6f-4c1a-aa96-86c72e17bf90n%40googlegroups.com.
