Very fine, it works now. Thank you for fixing.
For this panorama Multiblend took about 40 minutes. The final tiff file has 
about 14 GBytes. Windows could not open it (probably too large), but with 
GIMP I could view it.

Monkey schrieb am Sonntag, 4. Juli 2021 um 12:13:05 UTC+2:

> The most probable culprit is line 167 in pyramid.h which should be changed 
> to:
>
>     dst_p += *(size_t)*(sy - (level ? 1 : 0)) * pitch;
>
> Line 169 should also be changed to:
>
>     p_pt += *(size_t)*m128_pitch * sy;
>
> although it is probably not the cause of the problem in this case.
> On Sunday, 4 July 2021 at 05:48:50 UTC+1 Florian Königstein wrote:
>
>>
>> With the Debugger I see that it now crashed in the function   template 
>> <typename F> void Pyramid::OutPlanar8 _OP_  in the line
>>           _mm_storeu_si128(dst_pp_m++, pixels);
>> dst_pp_m points to an unreadable position. However *dst_p is readable 
>> (above dst_pp_m = (__m128i*)dst_p; was executed).
>>
>> Monkey schrieb am Samstag, 3. Juli 2021 um 21:51:58 UTC+2:
>>
>>> Actually never mind, that probably isn't it... I'll keep looking.
>>>
>>> On Saturday, 3 July 2021 at 20:46:48 UTC+1 Monkey wrote:
>>>
>>>> Line 683 of image.cpp - please replace
>>>>
>>>>     size_t channel_bytes = (width * height) << (bpp >> 4);
>>>>
>>>> with
>>>>
>>>>     size_t channel_bytes = ((size_t)width * height) << (bpp >> 4);
>>>>
>>>> I would test this myself but my one attempt caused my computer to 
>>>> freeze and need a hard reset, which I hate doing!
>>>> On Saturday, 3 July 2021 at 20:06:38 UTC+1 Florian Königstein wrote:
>>>>
>>>>> I changed it and ran it in a Release build because running the Debug 
>>>>> version takes much more time. The release version stopped with the 
>>>>> following console output:
>>>>> Warning: test1191347.tif is fully obscured by other images
>>>>> Warning: test1191349.tif is fully obscured by other images
>>>>> Warning: test1191350.tif is fully obscured by other images
>>>>> Shrinking masks...
>>>>> Blending...
>>>>>
>>>>> So, no meesage "writing .. output file". And test119.tif (the output 
>>>>> file) contains 0 bytes. Probably the Debugger would raise an error at the 
>>>>> same line. At night I will run the new version with the debugger.
>>>>> Monkey schrieb am Samstag, 3. Juli 2021 um 20:16:46 UTC+2:
>>>>>
>>>>>> Ah, how foolish of me, I think I failed to account for the required 
>>>>>> number of bytes overflowing a 32-bit value.
>>>>>>
>>>>>> Does it work if you change line 31 of pyramid.cpp from
>>>>>>
>>>>>>         size_t bytes = pitch * ((height + y_shift + 3) & ~3) * 
>>>>>> sizeof(float);
>>>>>>
>>>>>> to
>>>>>>
>>>>>>         size_t bytes = (size_t)pitch * ((height + y_shift + 3) & ~3) 
>>>>>> * sizeof(float);
>>>>>>
>>>>>> ?
>>>>>> On Saturday, 3 July 2021 at 15:26:41 UTC+1 Florian Königstein wrote:
>>>>>>
>>>>>>> I tested it so that more memory than I have RAM is used.
>>>>>>> But Multiblend crashed when stitching 1351 photos to an output size 
>>>>>>> of 88291 x 61567 Pixels.
>>>>>>>
>>>>>>> I started it again with the Visual Studio 2019 Debugger.
>>>>>>>
>>>>>>> The input options were Multiblend --argfile=test.txt with test.txt 
>>>>>>> containing
>>>>>>> --bigtiff
>>>>>>> --all-threads
>>>>>>> -f88291x61567+18125+0
>>>>>>> --compression=LZW
>>>>>>> -o
>>>>>>> test119.tif
>>>>>>> test1190000.tif
>>>>>>> test1190001.tif
>>>>>>> test1190002.tif
>>>>>>> ...
>>>>>>> test1191350.tif
>>>>>>>
>>>>>>>
>>>>>>> The console output was
>>>>>>> ignoring Enblend option -f
>>>>>>>
>>>>>>> Multiblend v2.0.0 (c) 2021 David Horman        
>>>>>>> http://horman.net/multiblend/
>>>>>>>
>>>>>>> ----------------------------------------------------------------------------
>>>>>>> Processing test1190000.tif...
>>>>>>> Processing test1190001.tif...
>>>>>>> Processing test1190002.tif...
>>>>>>> ...
>>>>>>> Processing test1191350.tif...
>>>>>>>
>>>>>>> 88291 x 61567, 11 levels, 8 bpp
>>>>>>>
>>>>>>> Seaming...
>>>>>>> Warning: test1190001.tif is fully obscured by other images
>>>>>>> Warning: test1190002.tif is fully obscured by other images
>>>>>>>    .... some other images obscured ....
>>>>>>> Warning: test1191350.tif is fully obscured by other images
>>>>>>> Shrinking masks...
>>>>>>> Blending...
>>>>>>>
>>>>>>>
>>>>>>> The crash was in the function CompositeLine() in the following line:
>>>>>>>        if (i == 0) memset(&output_p[x], 0, mask_count << 2);
>>>>>>> The pointer output_p is 0x0000026321b85980, "Unable to read memory". 
>>>>>>> mask_count is 88291.
>>>>>>>
>>>>>>> In the calling function main() and the lambda function the variables 
>>>>>>> were:
>>>>>>>    i = 0
>>>>>>>    l = 0
>>>>>>> - in_level {width=12324 height=5502 pitch=12328 ...} Pyramid::Level
>>>>>>> width 12324 int
>>>>>>> height 5502 int
>>>>>>> pitch 12328 int
>>>>>>> m128_pitch 3082 int
>>>>>>> bytes 271413248 unsigned __int64
>>>>>>> + data 0x0000025ed3e23080 {0.00000000} float *
>>>>>>> x 75967 int
>>>>>>> y 0 int
>>>>>>> x_shift true bool
>>>>>>> y_shift false bool
>>>>>>> upper_x_shift false bool
>>>>>>> upper_m128_pitch 0 int
>>>>>>> - bands { size=3 } std::vector<int,std::allocator<int>>
>>>>>>> [capacity] 3 __int64
>>>>>>> + [allocator] allocator 
>>>>>>> std::_Compressed_pair<std::allocator<int>,std::_Vector_val<std::_Simple_types<int>>,1>
>>>>>>> [0] 0 int
>>>>>>> [1] 2748 int
>>>>>>> [2] 5502 int
>>>>>>> + [Raw View] {_Mypair=allocator } 
>>>>>>> std::vector<int,std::allocator<int>>
>>>>>>>
>>>>>>>
>>>>>>> - out_level {width=88291 height=61567 pitch=88296 ...} 
>>>>>>> Pyramid::Level
>>>>>>> width 88291 int
>>>>>>> height 61567 int
>>>>>>> pitch 88296 int
>>>>>>> m128_pitch 22074 int
>>>>>>> bytes 4564963328 unsigned __int64
>>>>>>> + data 0x0000026099c20000 {0.00000000} float *
>>>>>>> x 0 int
>>>>>>> y 0 int
>>>>>>> x_shift false bool
>>>>>>> y_shift false bool
>>>>>>> upper_x_shift false bool
>>>>>>> upper_m128_pitch 0 int
>>>>>>> - bands { size=3 } std::vector<int,std::allocator<int>>
>>>>>>> [capacity] 3 __int64
>>>>>>> + [allocator] allocator 
>>>>>>> std::_Compressed_pair<std::allocator<int>,std::_Vector_val<std::_Simple_types<int>>,1>
>>>>>>> [0] 0 int
>>>>>>> [1] 30780 int
>>>>>>> [2] 61567 int
>>>>>>> + [Raw View] {_Mypair=allocator } 
>>>>>>> std::vector<int,std::allocator<int>>
>>>>>>>
>>>>>>> x_offset = 75967
>>>>>>> y_offset = 0
>>>>>>> sy = 30780
>>>>>>> ey = 61567
>>>>>>> y = 30780
>>>>>>> The input files have a total size of 90 GBytes, but if nothing 
>>>>>>> helps, I could upload them somewhere.
>>>>>>>
>>>>>>> On Thursday I stitched the same project, but it was scaled with nona 
>>>>>>> so that the output became 36534 x 25476 Pixels. Multiblend used only 
>>>>>>> the 
>>>>>>> RAM (about 24 GBytes). It ran without problems.
>>>>>>>
>>>>>>> Maybe you can provocate this error when simulating less RAM e.g. 
>>>>>>> with a virtual machine and using less images.
>>>>>>> Monkey schrieb am Donnerstag, 1. Juli 2021 um 20:57:38 UTC+2:
>>>>>>>
>>>>>>>> Don't forget that the 64-bit version of Multiblend will use disk 
>>>>>>>> space (system temp or specified directory) if there isn't enough RAM.
>>>>>>>>
>>>>>>>> On Thursday, 1 July 2021 at 16:17:11 UTC+1 Florian Königstein wrote:
>>>>>>>>
>>>>>>>>> For me it does not work if I use  multiblend.exe @test.txt  
>>>>>>>>> instead of  multiblend.exe --argfile=test.txt on Windows.
>>>>>>>>> AFAIK on Linux you can do this with some other syntax (I'm not so 
>>>>>>>>> familiar with Linux). But building something like an --argfile option 
>>>>>>>>> into 
>>>>>>>>> Multiblend has the other advantage that is works OS independent.
>>>>>>>>>
>>>>>>>>> I have stitched nearly 1 GPixels with Multiblend in about 6 
>>>>>>>>> minutes. It's super fast. Thanks @ Monkey !
>>>>>>>>> The maximum memory usage was about 24 GBytes. My photos would 
>>>>>>>>> allow to stitch it to about 10 GPixels, but due to my RAM (64 GBytes) 
>>>>>>>>> I 
>>>>>>>>> will probably only be able to stitch about 2 - 2.5 GPixels.
>>>>>>>>>
>>>>>>>>> Monkey schrieb am Donnerstag, 1. Juli 2021 um 12:04:02 UTC+2:
>>>>>>>>>
>>>>>>>>>> Thanks Florian, that's a great suggestion and I'll incorporate 
>>>>>>>>>> into the source distribution at some point. Out of interest, how 
>>>>>>>>>> long did 
>>>>>>>>>> the blend take? Was the final pixel count?
>>>>>>>>>>
>>>>>>>>>> On Thursday, 1 July 2021 at 10:16:06 UTC+1 [email protected] 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> AFAIK if you pass the parameter @filename to a program on ms 
>>>>>>>>>>> windows the contents of the file "filename" is used as command-line 
>>>>>>>>>>> parameters. Thw last time I tried if the parameters are read from a 
>>>>>>>>>>> file 
>>>>>>>>>>> the maximum length was higher than the 256 bytes the limit was at 
>>>>>>>>>>> back then.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 1. Juli 2021 07:04:12 MESZ schrieb "Florian Königstein" <
>>>>>>>>>>> [email protected]>:
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to stitch a panorama with 1350 images with multiblend. 
>>>>>>>>>>>> It didn't work in Windows because the command line where all the 
>>>>>>>>>>>> image 
>>>>>>>>>>>> filenames are listed was longer than 32768 characters. At least in 
>>>>>>>>>>>> Windows 
>>>>>>>>>>>> the limit is 32768 (or maybe one less).
>>>>>>>>>>>>
>>>>>>>>>>>> I suggest adding the possibility to read the command line 
>>>>>>>>>>>> arguments from a file.
>>>>>>>>>>>> I changed multiblend.cpp so that you can add a command line 
>>>>>>>>>>>> option  --argfile filename  or  --argfile=filename . After this no 
>>>>>>>>>>>> further 
>>>>>>>>>>>> arguments may follow in the command line, but each line in the 
>>>>>>>>>>>> file 
>>>>>>>>>>>> "filename" counts as another argument, e.g. call
>>>>>>>>>>>> multiblend.exe" --argfile=test.txt
>>>>>>>>>>>> with test.txt containing e.g.
>>>>>>>>>>>> --compression=LZW
>>>>>>>>>>>> -o
>>>>>>>>>>>> test110.tif
>>>>>>>>>>>> --
>>>>>>>>>>>> test1100000.tif
>>>>>>>>>>>> test1100001.tif
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>> In the attachment I have the modified version of multiblend.cpp.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe Hugin and HuginExecutor could be changed so that the 
>>>>>>>>>>>> arguments are written in a file if they are many.
>>>>>>>>>>>>
>>>>>>>>>>>> Florian
>>>>>>>>>>>>
>>>>>>>>>>>> [email protected] schrieb am Sonntag, 13. Juni 2021 um 
>>>>>>>>>>>> 11:55:00 UTC+2:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> as there is actual coding of new software going on, maybe one 
>>>>>>>>>>>>> can iron out a deficiency in the Hugin lens model. At least lay 
>>>>>>>>>>>>> the 
>>>>>>>>>>>>> groundwork for it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Brown-Conrady model parameters are sound, but the 
>>>>>>>>>>>>> intersection with the abc-Hugin parameter set contains only one 
>>>>>>>>>>>>> (1) 
>>>>>>>>>>>>> non-trivial distortion parameter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I suggest to add further Brown-Conrady parameters to the 
>>>>>>>>>>>>> software code you are currently writing. Now.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>
>>>>>>>>>>>>> Klaus
>>>>>>>>>>>>> On 11.06.21 18:20, Florian Königstein wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Monkey, I much appreciate your software.
>>>>>>>>>>>>> I like it because I like big panoramas ... and the speedup is 
>>>>>>>>>>>>> welcome.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For big panoramas there's another issue: Geometrical 
>>>>>>>>>>>>> optimization is slow.
>>>>>>>>>>>>> I developed a fork for the libpano library that I called 
>>>>>>>>>>>>> fastPTOptimizer.
>>>>>>>>>>>>> For large panoramas the speedup factor for optimization can be 
>>>>>>>>>>>>> 100 or more.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I integrated both your multiblend and my fastPTOptimizer into 
>>>>>>>>>>>>> a "development version" of Hugin.
>>>>>>>>>>>>> Multiblend is now the default enblend-like program (in the GUI 
>>>>>>>>>>>>> is still written "enblend"
>>>>>>>>>>>>> but you can see that multiblend is used by choosing 
>>>>>>>>>>>>> Preferences / Programs).
>>>>>>>>>>>>> Only the CMakeLists.txt files are not updated so that 
>>>>>>>>>>>>> Multiblend is automatically integrated
>>>>>>>>>>>>> because I'm not yet so familiar with creating files for CMake.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My version of Hugin is here:
>>>>>>>>>>>>> https://sourceforge.net/projects/huginplusplus/files/
>>>>>>>>>>>>> development/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Monkey schrieb am Samstag, 10. April 2021 um 22:00:35 UTC+2:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Has anyone out there tried either the x64 or x86 versions of 
>>>>>>>>>>>>>> Multiblend 2.0 on Windows XP or Windows Vista? Someone's 
>>>>>>>>>>>>>> reporting vcredist 
>>>>>>>>>>>>>> problems and I'm not sure if it's because I built using the 
>>>>>>>>>>>>>> latest platform 
>>>>>>>>>>>>>> toolset.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sunday, 4 April 2021 at 17:11:16 UTC+1 [email protected] 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll give it a shot. last time I used it it for a aerial 360 
>>>>>>>>>>>>>>> it removed cars and other ground objects.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Friday, March 5, 2021 at 3:57:30 PM UTC-8 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 Multiblend 2.0, faster, better, more... blendy. I'm 
>>>>>>>>>>>>>>>> calling it a Release Candidate because there's only so much 
>>>>>>>>>>>>>>>> testing I can 
>>>>>>>>>>>>>>>> stand to do, and I've hit a dead-end with features, so I 
>>>>>>>>>>>>>>>> thought I'd put it 
>>>>>>>>>>>>>>>> out there for people to try. I expect some bugs to be found 
>>>>>>>>>>>>>>>> pretty quickly, 
>>>>>>>>>>>>>>>> which I'll hopefully fix pretty quickly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's released under GPLv3.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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/2699006b-895d-42f4-bd19-6ed0d3f3863bn%40googlegroups.com
>>>>>>>>>>>>>  
>>>>>>>>>>>>> <https://groups.google.com/d/msgid/hugin-ptx/2699006b-895d-42f4-bd19-6ed0d3f3863bn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>> .
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- 
>>>>>>>>>>> Sent from my Android device with K-9 Mail. Please excuse my 
>>>>>>>>>>> brevity.
>>>>>>>>>>>
>>>>>>>>>>

-- 
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/524300ad-fe7b-4480-891d-542fe8fe42f8n%40googlegroups.com.

Reply via email to