Using a re-exported seams png (even without modifying it) gives me broken results. Should I use a specific png filter/compression and/or color space ? On Tuesday, January 4th, 2022 at 10:32 AM, Tobias <[email protected]> wrote:
> 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 >>>>>>>>>>> width12324int >>>>>>>>>>> height5502int >>>>>>>>>>> pitch12328int >>>>>>>>>>> m128_pitch3082int >>>>>>>>>>> bytes271413248unsigned __int64 >>>>>>>>>>> +data0x0000025ed3e23080 {0.00000000}float * >>>>>>>>>>> x75967int >>>>>>>>>>> y0int >>>>>>>>>>> x_shifttruebool >>>>>>>>>>> y_shiftfalsebool >>>>>>>>>>> upper_x_shiftfalsebool >>>>>>>>>>> upper_m128_pitch0int >>>>>>>>>>> -bands{ size=3 }std::vector<int,std::allocator<int>> >>>>>>>>>>> [capacity]3__int64 >>>>>>>>>>> +[allocator]allocatorstd::_Compressed_pair<std::allocator<int>,std::_Vector_val<std::_Simple_types<int>>,1> >>>>>>>>>>> [0]0int >>>>>>>>>>> [1]2748int >>>>>>>>>>> [2]5502int >>>>>>>>>>> +[Raw View]{_Mypair=allocator }std::vector<int,std::allocator<int>> >>>>>>>>>>> >>>>>>>>>>> -out_level{width=88291 height=61567 pitch=88296 ...}Pyramid::Level >>>>>>>>>>> width88291int >>>>>>>>>>> height61567int >>>>>>>>>>> pitch88296int >>>>>>>>>>> m128_pitch22074int >>>>>>>>>>> bytes4564963328unsigned __int64 >>>>>>>>>>> +data0x0000026099c20000 {0.00000000}float * >>>>>>>>>>> x0int >>>>>>>>>>> y0int >>>>>>>>>>> x_shiftfalsebool >>>>>>>>>>> y_shiftfalsebool >>>>>>>>>>> upper_x_shiftfalsebool >>>>>>>>>>> upper_m128_pitch0int >>>>>>>>>>> -bands{ size=3 }std::vector<int,std::allocator<int>> >>>>>>>>>>> [capacity]3__int64 >>>>>>>>>>> +[allocator]allocatorstd::_Compressed_pair<std::allocator<int>,std::_Vector_val<std::_Simple_types<int>>,1> >>>>>>>>>>> [0]0int >>>>>>>>>>> [1]30780int >>>>>>>>>>> [2]61567int >>>>>>>>>>> +[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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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. -- 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 visit https://groups.google.com/d/msgid/hugin-ptx/gvtbHcUJao2szfaucWiLwVltaSxh6FMhEbYftU_Br8GxSpQTak0lpXzy0MxaxSKlEJDdr83hnyGDnJd8r1qwH0dqsWuv5oAcqkjyQro6-bw%3D%40protonmail.com.
