I think the biggest I've made was 1.2GB as a TIFF. I have 64GB RAM and
64GB swap. The max memory use it hit during blending was 32GB, so it
never touched swap.
I'll have to see if I can produce bigger ones now since I've moved from
a 6mpix camera to a 20mpix one.
On 2/12/21 5:56 AM, Luís Henrique Camargo Quiroz wrote:
I have made some panoramas with circa 2.7 GB in a tif
equirectangular file. However I had to grew my linux swap partition
more than one time until I managed to finish those panoramas, and my
swap has 72 GB currently (and only 16 GB physical memory).
regards,
Luís Henrique
Em sex., 12 de fev. de 2021 às 10:01, Monkey escreveu:
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
[email protected] 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
[email protected]
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/5cf61215-2505-fb26-8e0c-fe7c82d16501%40gmail.com.
