Hello, what about creating an github <https://github.com/>or gitlab <https://about.gitlab.com/>repository for multiplend? This would make the patch handling easier.
Regards, Tobias Monkey schrieb am Sonntag, 12. Dezember 2021 um 15:57:15 UTC+1: > I finally got around to packaging up the files with the last few bugfixes. > It doesn't include list file processing though, which is still on the to-do > list. > > https://horman.net/multiblend/ > > On Wednesday, 20 October 2021 at 15:51:01 UTC+1 [email protected] wrote: > >> @Florian K¨nigstein, @Monkey, do you plane to release a RC5 with the >> fixes you identified ? (limited number of images because of windows args in >> console, and silent crashes of Multiblend?) >> I almost have the same problems with big panoramas while charging tiff >> files or blending: Multiblend stops with no errors. >> >> I also found that multiblend reads the geotiff tag, but in order to make >> it work, I have to modify the georeference informations with Y=-Y. >> I'm trying to give you the exact lines of code to change. >> >> This tool is a game changer in th image assembly solutions! >> Best regards, >> >> Le dimanche 4 juillet 2021 à 20:36:19 UTC+2, Florian Königstein a écrit : >> >>> 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/32c90320-0823-4fdb-9d8d-47515672784cn%40googlegroups.com.
