Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features

[Florian Königstein]

There's a bug both in Hugin++ and in the latest official Hugin release 
(Hugin-2020.0.0):
To reproduce it, start Hugin, and open a PTO file that is large enough so 
that the loading takes some seconds.
Before the loading has finished, press the grayed out button for 
geometrical optimization in the "images" tab TWO times.
After loading has finished, two windows with title "Panorama Tools" will 
appear. In one the text 012345678901234567890123456789... appears
and nothing changes over time.
The other "Panorama Tools" window behaves normally. When finished 
optimization, accept the results.
Then Hugin / Hugin++ will crash.

I didn't have the time to fix the bug. Maybe later.

Florian Königstein schrieb am Donnerstag, 1. Juli 2021 um 21:46:47 UTC+2:

> I have an update for fastPTOptimizer and also for the Windows installer 
> for Hugin++ that also installs the binaries for fastPTOptimizer.
> When there are weights for CPs other than 1, say a weight 'w', it should 
> be exactly as if you had 'w' CPs with weight 1 at the same position. In the 
> old version of fastPTOptimizer the reported error during the optimization 
> wasn't correct. If e.g. all weights are 1000, the reported error should be 
> the same as if all weights were 1 since the error is an average over all 
> CP's errors. In the old version the error was too high if weights > 1 were 
> used. I have corrected it.
>
> bruno...@gmail.com schrieb am Donnerstag, 1. Juli 2021 um 12:14:54 UTC+2:
>
>> Apologies, I was wrong about this. Sourceforge does support the usual 
>> fork/pull-request workflow, with both mercurial and git. 
>>
>> -- 
>> Bruno 
>>
>> On 28 June 2021 20:51:13 BST, Bruno Postle wrote: 
>>
>> >This is an illustration of our creaking infrastructure. Sourceforge 
>> >doesn't support the fork/pull-request/merge workflow that we have 
>> >become used-to with github/bitbucket, so anyone wanting to work 
>> >separately on Hugin needs to create a new repository or create a 
>> >branch in the main repository. Florian, do you need access to work on 
>> >this in a Hugin branch? 
>>
>

-- 
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/6af9b651-69b7-4474-bcb7-cb4c7cca0d2fn%40googlegroups.com.

Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features

[Florian Königstein]

I have an update for fastPTOptimizer and also for the Windows installer for 
Hugin++ that also installs the binaries for fastPTOptimizer.
When there are weights for CPs other than 1, say a weight 'w', it should be 
exactly as if you had 'w' CPs with weight 1 at the same position. In the 
old version of fastPTOptimizer the reported error during the optimization 
wasn't correct. If e.g. all weights are 1000, the reported error should be 
the same as if all weights were 1 since the error is an average over all 
CP's errors. In the old version the error was too high if weights > 1 were 
used. I have corrected it.

bruno...@gmail.com schrieb am Donnerstag, 1. Juli 2021 um 12:14:54 UTC+2:

> Apologies, I was wrong about this. Sourceforge does support the usual 
> fork/pull-request workflow, with both mercurial and git.
>
> -- 
> Bruno
>
> On 28 June 2021 20:51:13 BST, Bruno Postle wrote:
>
> >This is an illustration of our creaking infrastructure. Sourceforge
> >doesn't support the fork/pull-request/merge workflow that we have
> >become used-to with github/bitbucket, so anyone wanting to work
> >separately on Hugin needs to create a new repository or create a
> >branch in the main repository. Florian, do you need access to work on
> >this in a Hugin branch?
>

-- 
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/2ba6afce-aaa2-440f-9c97-fa1b7ef98b35n%40googlegroups.com.

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

[Monkey]

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 gunter.ko...@gmail.com 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" <
>>> niets...@gmail.com>:

 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
 --
 test110.tif
 test111.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

 klaus...@gmail.com 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 lownsl...@gmail.com 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 mosa

[hugin-ptx] Re: is hugin_hdrmerge broken?

[T. Modes]

kfj schrieb am Mittwoch, 30. Juni 2021 um 23:05:13 UTC+2:

> I saw hugin produce such pgm files, and I could never figure out why they 
> would be needed: the exr should have all the nececssary information, 
> because it holds linear RGBA. What's the pgm good for?
>

In Hugins HDR workflow all input images are remapped to the output 
projection. In the same time they are converted into the same linear 
colorspace - it corrects the exposure, vignetting (and also white balance). 
But then the information about under- and over exposed pixels is lost. This 
information is transferred to hugin_hdrmerge with the _gray.pgm files and 
helps to merge the individual images.

-- 
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/ba9e3449-05f9-40cc-8e4b-0d8d018904b1n%40googlegroups.com.

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

[Florian Königstein]

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 gunter.ko...@gmail.com 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" <
>> niets...@gmail.com>:
>>>
>>> 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
>>> --
>>> test110.tif
>>> test111.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
>>>
>>> klaus...@gmail.com 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 lownsl...@gmail.com 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 

Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features

[Bruno Postle]

Apologies, I was wrong about this. Sourceforge does support the usual 
fork/pull-request workflow, with both mercurial and git.

-- 
Bruno

On 28 June 2021 20:51:13 BST, Bruno Postle wrote:

>This is an illustration of our creaking infrastructure. Sourceforge
>doesn't support the fork/pull-request/merge workflow that we have
>become used-to with github/bitbucket, so anyone wanting to work
>separately on Hugin needs to create a new repository or create a
>branch in the main repository. Florian, do you need access to work on
>this in a Hugin branch?

-- 
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/190626BF-0F44-47E3-B232-991E76969BA9%40postle.net.

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

[Monkey]

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 gunter.ko...@gmail.com 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" <
> niets...@gmail.com>:
>>
>> 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
>> --
>> test110.tif
>> test111.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
>>
>> klaus...@gmail.com 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 lownsl...@gmail.com 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 hugin-ptx+...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/hugin-ptx/2699006b-895d-42f4-bd19

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

[Gunter Königsmann]

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" 
:
>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
>--
>test110.tif
>test111.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
>
>klaus...@gmail.com 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 lownsl...@gmail.com 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 hugin-ptx+...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/hugin-ptx/2699006b-895d-42f4-bd19-6ed0d3f3863bn%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 gr