>
> Still, it seems to be quite more memory hungry than the old version.
--
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.
--cache-threshold=1 did not help, but MAP_SHARED | MAP_NORESERVE did.
--
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
You can probably replace any malloc except the one on line 20 of
functions.cpp, but they should all be pretty small anyway. I'm guessing
it's the seam map that's growing too large, but if you set
--cache-threshold=1 that should cache all the images before it gets to the
seam map and might
Question: Any possibility to convert some of the mallocs to MapAlloc? Could
this prevent some OOM cases I encountered when blending very large scans
(1.2g+0.8g 8-bit tiffs)?
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this
Works. No more crash.
--
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
Ugh, that had me stumped for a while. I couldn't work out why it was
telling me it was trying access 0x.
Anyway, the solution is to change lines 316 and 325 of pyramid.cpp to:
pixels = _mm_load*u*_si128(src_pp_m++);
On Saturday, 3 April 2021 at 16:41:48 UTC+1
FWIW, converting the source tiffs to 8bit works. Although with leaks in
ShrinkMasks.
--
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
Don't think this one is a mere OOM problem since it happens even with
--cache-threshold=1G
--
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
Thank you! blending that 1.2gigapix panorama where finally fails at :
13224 x 12248, 10 levels, 16 bpp
Seaming...
Shrinking masks...
Blending...
AddressSanitizer:DEADLYSIGNAL
AddressSanitizer:DEADLYSIGNAL
==17066==ERROR: AddressSanitizer: SEGV on unknown address (pc
0x559fa73dbbee bp
Errata:
Line 96 of threadpool.cpp should read (as above):
for (i = 0; i < *n_threads*; ++i) {
Line 641 of pyramid.cpp should read:
if (x_shift) memmove(*&((float*)line)[1]*, line, (m128_pitch_hi << 4) -
*4*);
(the first bit is just for clarity, the 1, now a 4, at the end was a
Oh, how embarrassing... for a fix to that immediate problem, change line 96
of threadpool.cpp to read:
for (i = 0; i < *n_threads*; ++i) {
-fsantize=address - which I shall try to remember to use in future! - is
still reporting some other problems so I'll fix those before I update the
I do very much appreciate this effort!
Unfortunate the new one fails to stitch a 1.2gigapixel image that the old
one stitched perfectly, so I compiled it with -fsanitize=address and got
very early this one :
==8137==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x611003b0 at pc
Hi David, thank you for your help. I will try another stitch removing the
sky's photos and generating a partial panorma. For the sky, Hugin can't
obvioulsy find any control point. So I have entered some points very
roughly, just to keep the photos of the sky in the right place. Is there
On Fri, 2021-03-05 at 17:33 -0800, Monkey wrote:
> Build "instructions", such as they are - they work for me on WSL Ubuntu, at
> least - are in the build.txt file:
>
> g++ -msse4.1 -pthread -ffast-math -Ofast -o multiblend multiblend.cpp -lm -
> lpng -ltiff -ljpeg
>
I should have looked in
Sorry, I didn't get around to looking into your project too much. Neither
Enblend nor Multiblend can do much about such misalignments, as they come
from Hugin's processing of control points, and you have some problematic
control points in your project. If you open the Control Point table and
Hi Monkey,
I have done some tests with the same 56 photos 360° Panorama I already sent
to you. I have a pto with some masks to avoid bad seams on the buildings.
Stitching this with Multiblend is much much faster but the result is not
better than the enblend one. There are stitching errors in
I uploaded both .exes to VirusTotal. 11/69 reported the x86 version as
suspect, and 1/69 reported the x64 version as suspect.
I think this is just a hazard of the ubiquity of viruses. You can probably
find something that vaguely resembles some virus in any piece of code.
There's nothing
Hi Monkey
I am only writing to report that my BITDEFENDER TOTAL SECURITY:
- reports the site http://horman.net/multiblend/ as dangerous, and
blocks it.
- in the zip with windows binaries, it reports multiblend_x86.exe as a
virus, and deletes it. (not a great problem as I think everyone is
Thanks Harry.
On Saturday, 6 March 2021 at 12:24:17 UTC hvd...@gmail.com wrote:
> And a distributable macos build for multiblend *2.0rc2*:
> https://mega.nz/file/lQtlgKRI#wNYpcmE4-XuZJOsXmxtBkBmB6Ekji-Vp65c38FCaGws
> Unzip to a folder of your liking with paths. It should give:
>
And a distributable macos build for multiblend *2.0rc2*:
https://mega.nz/file/lQtlgKRI#wNYpcmE4-XuZJOsXmxtBkBmB6Ekji-Vp65c38FCaGws
Unzip to a folder of your liking with paths. It should give:
multiblend-dist/
multiblend-dist/Libraries/
multiblend-dist/Libraries/libz.1.2.11.dylib
Fixed and updated, plus a fix to ignore (properly) an Enblend parameter
that was stopping Hugin from successfully calling Multiblend.
http://horman.net/multiblend/
David
On Saturday, 6 March 2021 at 11:22:47 UTC hvd...@gmail.com wrote:
> Builds fine and runs fine (under Hugin) on my Ubuntu
Builds fine and runs fine (under Hugin) on my Ubuntu derived box. GalliumOS
3.1 (Ubuntu 18.04 LTS)
(Linux edgar 4.16.18-galliumos #1 SMP PREEMPT Sun Jun 23 04:14:45 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux)
On MacOS Catalina I had to replace in multiblend.cpp the following:
#include
#include
Build "instructions", such as they are - they work for me on WSL Ubuntu, at
least - are in the build.txt file:
g++ -msse4.1 -pthread -ffast-math -Ofast -o multiblend multiblend.cpp -lm
-lpng -ltiff -ljpeg
On Saturday, 6 March 2021 at 01:10:10 UTC Tduell wrote:
> On Fri, 2021-03-05 at 15:57
On Fri, 2021-03-05 at 15:57 -0800, Monkey wrote:
> (* for a Gigapixel mosaic, anyway; it's complicated, see below)
>
> http://horman.net/multiblend/
>
> It seems Groups won't let me post the quasi-essay I had written, complete with
> images, so the link above will have to suffice.
>
> Here's
*(* for a Gigapixel mosaic, anyway; it's complicated, see below)*
http://horman.net/multiblend/
It seems Groups won't let me post the quasi-essay I had written, complete
with images, so the link above will have to suffice.
Here's Multiblend 2.0, faster, better, more... blendy. I'm calling it
25 matches
Mail list logo
