Re: [hugin-ptx] Hugin computing power

[Monkey]

"multiblend is exceptionally fast compared to enblend (maybe 10x to 20x 
faster, as I recall)."

It's not a fixed increase. Enblend has O(n^2) runtime (it scales with the 
square of the number of pixels) whereas Multiblend is linear. I don't know 
of anyone who's tried a terapixel blend with both, but Multiblend should be 
on the order of 100,000 times faster :D

"Hugin was used to combine the images of 2 cams in a panorama"

For videos, you might want to consider Avisynth+ instead of Hugin. There 
are plugins for warping and fusing videos (I keep meaning to release an 
update for the latter).
On Thursday 25 January 2024 at 23:43:59 UTC GnomeNomad wrote:

> Thanks. I didn't know you had two cameras. Very cool!
>
> On 1/25/24 08:26, Maarten Verberne wrote:
> > I'm not sure what you are asking.
> > Hugin was used to combine the images of 2 cams in a panorama, used the 
> > template it created for the rest of the images.
> >
> >
> > Op 25-Jan-24 om 5:40 schreef David W. Jones:
> >> That's pretty good. How did you use Hugin in this project?
> >>
> >
>
> -- 
> David W. Jones
> gnome...@gmail.com
> wandering the landscape of god
> http://dancingtreefrog.com
> My password is the last 8 digits of π.
>
>

-- 
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/889c551d-ac21-4306-a792-0daf95169b93n%40googlegroups.com.

[hugin-ptx] Re: Problem with bright splodge in panorama from enblend.

[Monkey]

Have you tried re-ordering the images? Order matters in enblend.

(And of course you could always try Multiblend ;) )

On Thursday, 20 April 2023 at 20:35:23 UTC+1 irthoma...@gmail.com wrote:

>
> Thanks. Raws are here 
> https://drive.google.com/drive/folders/1zzjVOqO3pnwZu92LdJuUvTYoCOggfRk6?usp=sharing
> I am using 10bit rec2020 raws. But I noticed this pano was shot with 
> auto-exposure, and I was using Photometric > High dynamic range, fixed 
> exposure. I wonder if that causes problems?
>
>
>
>
> On Thursday, April 20, 2023 at 4:29:54 PM UTC+1 T. Modes wrote:
>
>> irthoma...@gmail.com schrieb am Donnerstag, 20. April 2023 um 14:27:33 
>> UTC+2:
>>
>> My process is to export raws from Darktable with everything disabled, 
>> but, lens correction.
>>
>> 
>>
>> 5: Photometric: High Dynamic Range, Fixed Exposure.
>>
>>  
>> This will only optimize vignetting correction. In case of images with a 
>> low dynamic range (high key/low key images) this may not result in correct 
>> results and may need manual fine-tune. This blurred spot could be the 
>> result of an improper vignetting correction.
>> But when you already corrected this in the raw converter this step may 
>> not be necessary.
>>
>> > Using built-in, instead of enblend, gets rid of the blotchy brightness. 
>> But, this produces it's own problems with seams and hard edges 
>> The internal blender has also a second blend mode in case there are 
>> remaining seams. This one has to be selected in the blender options.
>>
>>

-- 
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/5c41bb3d-2e6d-44da-b4d4-06f0bd27cf67n%40googlegroups.com.

Re: [hugin-ptx] Stop enblend from removing result

[Monkey]

Enblend's blending is dependent on the order that images are specified on 
the command line. By specifying the images in a different order (maybe in 
reverse, or maybe with the "redundant" image and its neighbour that you 
want it to blend with first) you may get something closer to the result you 
were hoping for. It's difficult to be more specific about what to do 
without knowing how the images overlap though.
On Friday, 25 February 2022 at 18:25:40 UTC Luís Henrique Camargo Quiroz 
wrote:

>
>That would be very useful: not automatically deleting the defective (?) 
> blended result! 
>
>
>
> Em sex., 25 de fev. de 2022 às 12:27, johnfi...@gmail.com <
> johnfi...@gmail.com> escreveu:
>
>> How do I stop enblend from removing the result?
>>
>> The message in the log is:
>>
>> enblend: warning: some images are redundant and will not be blended
>> enblend: note: usually this means that at least one of the images
>> enblend: note: does not belong to the set
>> enblend: encountered degenerate image/mask geometry; too high risk of 
>> defective seam line
>> enblend: info: remove invalid output image "DSC00228 - DSC00264.tif"
>>
>> "redundant" is likely correct.  I expect there are one or two in there 
>> that are each 100% covered by some collection of other images.  I'm pretty 
>> sure there is not any image that "does not belong" in the sense I would 
>> expect that to mean.
>>
>> One of the times this happened, I was able to open and view the result 
>> image before it was deleted and it was what I was aiming for.  Even if it 
>> hadn't been, I'd need it to get some clue what was wrong.  When I viewed 
>> it, I could have saved a copy but didn't realize I needed to.  Most times I 
>> don't get a chance in the moment in which that file exists.
>>
>> -- 
>> 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/ae5717f5-e986-41bc-aaf5-808b52cf684an%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> -- 
> Luis Henrique Camargo Quiroz
> http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
> http://panoramaslh.net/
>

-- 
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/81159c78-2645-435c-94ec-fc3c35f191aen%40googlegroups.com.

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

[Monkey]

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 carr...@gmail.com 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 
>>>>  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 =

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

[Monkey]

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 
>  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
>>>>>> test119.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 test119.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
>>>

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

[Monkey]

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
>>>> test119.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 test119.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 0x026321b85980, "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 0x025ed3e23080 {0.} 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>
>>>> [capacity] 3 __int64
>>>> + [allocator] allocator 
>>>> std::_Compres

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

[Monkey]

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
>>> test119.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 test119.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 0x026321b85980, "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 0x025ed3e23080 {0.} 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>
>>> [capacity] 3 __int64
>>> + [allocator] allocator 
>>> std::_Compressed_pair,std::_Vector_val>,1>
>>> [0] 0 int
>>> [1] 2748 int
>>> [2] 5502 int
>>> + [Raw View] {_Mypair=allocator } std::vector>
>>>
>>>
>>> - 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 0x026099c2 {0.} float *
>>> x 0 int
>>> y 0 int
>>> x_shift false bool
>>> y_sh

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

[Monkey]

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
> test119.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 test119.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 0x026321b85980, "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 0x025ed3e23080 {0.} 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>
> [capacity] 3 __int64
> + [allocator] allocator 
> std::_Compressed_pair,std::_Vector_val>,1>
> [0] 0 int
> [1] 2748 int
> [2] 5502 int
> + [Raw View] {_Mypair=allocator } std::vector>
>
>
> - 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 0x026099c2 {0.} 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>
> [capacity] 3 __int64
> + [allocator] allocator 
> std::_Compressed_pair,std::_Vector_val>,1>
> [0] 0 int
> [1] 30780 int
> [2] 61567 int
> + [Raw View] {_Mypair=allocator } std::vector>
>
> 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 a

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 
>>>

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, 
>>>>>> comp

[hugin-ptx] Re: Is there any way to keep pixels unchangeable with Hugin?

[Monkey]

Is there any way you can convert your false colour images to a linear 
greyscale first?

On Friday, 25 June 2021 at 15:52:48 UTC+1 alvaroh...@gmail.com wrote:

> Hello!
>
> I'm trying to stitch thermal images (codified with Rainbow HC palette for 
> false color) and once I've stitched the images bring back the thermal 
> information of the images. 
>
> [image: thermalToFalseColor.png]
>
> The problem is that once I stitch the images Hugin slightly change the 
> values of some pixels then I can't bring back the thermal information. 
> Anyone knows how to keep the values of the original image pixels 
> unchangeable?
>
> I hope you understand the problem!
> Thanks in advance.
>

-- 
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/14b38a7b-6403-4ea6-89b2-30bd6039451an%40googlegroups.com.

[hugin-ptx] Re: Frustrado com Hugin

[Monkey]

sudo apt install hugin

Parece funcionar bem para mim no Ubuntu.

On Saturday, 12 June 2021 at 20:28:41 UTC+1 jer...@gmail.com wrote:

>
> Instalei o DigiKam para editar fotos que é um dos meus hobbies. Uso o 
> Ubuntu Studio. O programa veio sem o Hugin para criar panorama. Quando 
> baixo o programa vem no formato Tar.bz2 que para min (ou quem como eu não é 
> formado em computação) é impossível instalar. Já visitei vários fórums, vi 
> vídeos no Youtube e sempre dizem para executar um comando ./configure que 
> não aparece na pasta descompactada do Hugin, outros tutoriais dizem para 
> ler o READ-ME, o que fiz várias vezes e não consegui nada. Gosto muito do 
> Linux mas as frustrações constantes estão me afastando da plataforma cada 
> vez mais. Só pra concluir, instalei o programa no Windows e com alguns 
> cliques já estava tudo funcionando. Preferiria que fosse no Linux mas só me 
> frustrei.
>

-- 
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/5fa23479-286a-441c-bafd-0a5a86a5343dn%40googlegroups.com.

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

[Monkey]

Strange. My two deleted messages from 3-4 days ago both appeared in my 
group digest email this morning.

Anyway, he's a different link to the image I was trying to link to:

https://horman.net/warped.jpg

On Sunday, 18 April 2021 at 13:54:18 UTC+1 Monkey wrote:

> > Please don't post large attachments directly to mailing lists, not 
> everyone 
> > wants to receive the attachment. 
> > It's always good etiquette to put your attachment on a cloud service 
> (Dropbox or 
> > similar) where those that want to can retrieve it. 
>
> But not Imgur, I'm guessing? Because I've tried to post a message 
> containing an Imgur link twice now in reply to this thread, and it's been 
> seemingly auto-deleted both times...
>
> On Saturday, 17 April 2021 at 23:51:14 UTC+1 Tduell wrote:
>
>> Hello Meowly, 
>>
>> On Sat, 2021-04-17 at 19:20 +0800, Meowly Bear wrote: 
>> > Hi, 
>> > 
>> > Here is the slightly lower res version of the two pictures, together 
>> with 
>> > the .pti file. I'm trying to match the Capitol Theatre with the old 
>> picture 
>> > angle. Thanks :) 
>> > 
>> > 1 Old150.jpg 
>>
>> Please don't post large attachments directly to mailing lists, not 
>> everyone 
>> wants to receive the attachment. 
>> It's always good etiquette to put your attachment on a cloud service 
>> (Dropbox or 
>> similar) where those that want to can retrieve it. 
>>
>> Cheers, 
>> -- 
>> Terry Duell  
>>
>>

-- 
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/6f785f0b-f5fc-4f85-974c-7ede846c0925n%40googlegroups.com.

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

[Monkey]

My reply seems to have been deleted, not sure how or why... but anyway, 
here's my result of using my video plugin to warp the old image to the new 
one based on the control points in the PTO file:

https://i.imgur.com/Vp0VkqR.jpeg

It's cropped a bit because of the way the process works.
On Saturday, 17 April 2021 at 23:51:14 UTC+1 Tduell wrote:

> Hello Meowly,
>
> On Sat, 2021-04-17 at 19:20 +0800, Meowly Bear wrote:
> > Hi,
> > 
> > Here is the slightly lower res version of the two pictures, together with
> > the .pti file. I'm trying to match the Capitol Theatre with the old 
> picture
> > angle. Thanks :)
> > 
> > 1 Old150.jpg
>
> Please don't post large attachments directly to mailing lists, not everyone
> wants to receive the attachment.
> It's always good etiquette to put your attachment on a cloud service 
> (Dropbox or
> similar) where those that want to can retrieve it.
>
> Cheers, 
> -- 
> Terry Duell 
>
>

-- 
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/6bef4f9a-bccc-4749-8ad2-d246050482b9n%40googlegroups.com.

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

[Monkey]

Using warping:

https://i.imgur.com/8AQjDwf.jpg

On Saturday, 17 April 2021 at 23:51:14 UTC+1 Tduell wrote:

> Hello Meowly,
>
> On Sat, 2021-04-17 at 19:20 +0800, Meowly Bear wrote:
> > Hi,
> > 
> > Here is the slightly lower res version of the two pictures, together with
> > the .pti file. I'm trying to match the Capitol Theatre with the old 
> picture
> > angle. Thanks :)
> > 
> > 1 Old150.jpg
>
> Please don't post large attachments directly to mailing lists, not everyone
> wants to receive the attachment.
> It's always good etiquette to put your attachment on a cloud service 
> (Dropbox or
> similar) where those that want to can retrieve it.
>
> Cheers, 
> -- 
> Terry Duell 
>
>

-- 
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/dd2d5523-598d-47b8-b959-3dd6faa96badn%40googlegroups.com.

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

[Monkey]

> Please don't post large attachments directly to mailing lists, not 
everyone 
> wants to receive the attachment. 
> It's always good etiquette to put your attachment on a cloud service 
(Dropbox or 
> similar) where those that want to can retrieve it. 

But not Imgur, I'm guessing? Because I've tried to post a message 
containing an Imgur link twice now in reply to this thread, and it's been 
seemingly auto-deleted both times...

On Saturday, 17 April 2021 at 23:51:14 UTC+1 Tduell wrote:

> Hello Meowly,
>
> On Sat, 2021-04-17 at 19:20 +0800, Meowly Bear wrote:
> > Hi,
> > 
> > Here is the slightly lower res version of the two pictures, together with
> > the .pti file. I'm trying to match the Capitol Theatre with the old 
> picture
> > angle. Thanks :)
> > 
> > 1 Old150.jpg
>
> Please don't post large attachments directly to mailing lists, not everyone
> wants to receive the attachment.
> It's always good etiquette to put your attachment on a cloud service 
> (Dropbox or
> similar) where those that want to can retrieve it.
>
> Cheers, 
> -- 
> Terry Duell 
>
>

-- 
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/94c02f3f-d2ef-44ac-89e3-e9aa4b8ec049n%40googlegroups.com.

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

[Monkey]

There's quite a large difference in geometry which I think Hugin is going 
to unable to fully correct. Can you upload your .pto file? I have a video 
plugin that should be able to warp one image to the other using the control 
points in the file.

On Friday, 16 April 2021 at 11:32:34 UTC+1 Meowly Bear wrote:

> Hi Bruno,
>
> Thank you for your reply.
>
> Unfortunately, I can't seem to make it work - probably because I'm doing 
> this wrong.
>
> These are the two pictures.
>  1 Old.jpg.zip 
> 
>  2 NewJPG.zip 
> 
>
> 1. I set Hugin INTERFACE to Expert.
> 2. ADD IMAGE: Old picture (this will be the anchor)
> 3. Double click on the filename. That opens up IMAGE VARIABLES. Under 
> POSITIONS, I ensure Yaw, Pitch & Roll = 0. Hit Okay.
> 4. ADD IMAGE: New picture
> 5. Then I hit CONTROL POINTS.
> 6. On the Left Panel is the Old picture. On the Right I select the New 
> Picture.
> 7. I match and ADD as many as 30 points between the left & right pictures.
>
> Then this is where I get lost. Am I supposed to go back to PHOTOS tab, 
> then highlight both the New & Old pics, and hit Optimise Geometric 
> (Positions & View) Calculate?
> Leave Feature Matching Setting: cpfind ?
> And then move to STITCHER tab, PROJECTION (Rectilinear)?
> Remapped Images select all three boxes and then hit STITCH?
>
> When I do that, it tells me it could not output as no images are selected.
>
> What am I doing wrong? Thank you in advance.
>
>
> On Fri, 16 Apr 2021 at 05:12, Bruno Postle  wrote:
>
>> On Thu 15-Apr-2021 at 10:33 -0700, Meowly Bear wrote:
>> >
>> > Just looking for a simple way to do this non-pano work.
>> >
>> > I have 2 pictures of a building taken 20 years apart. The angle of 
>> > the newer second image doesn't exactly match the older image.
>> >
>> > I would like to insert control points in Image 2 to match the 
>> > perspective and camera angles of the older Image 1, and output 
>> > only the corrected newer Image 2.
>>
>> This is only going to give satisfactory results if both photos were 
>> taken at more-or-less the same spot.
>>
>> You will need to use the Panorama Editor, the Preview window doesn't 
>> offer enough options.  Load the 'anchor' photo first and set the 
>> roll, pitch and yaw to zero, create control points, and optimise 
>> 'positions and view'.  The 'anchor' photo should stay in place and 
>> the other photo should move to fit.
>>
>> In the Stitcher tab, set the output projection to rectilinear, but 
>> before stitching select the 'remapped images' option.  The will save 
>> the images you want as TIFF files (usually they are deleted after 
>> blending).
>>
>> My experience to trying this with old photos is that you should 
>> switch it around.  You know the parameters of your new photo, so this 
>> should be your anchor, old photos have unknown lenses and are often 
>> cropped asymmetrically (which Hugin can deal with using the d,e 
>> parameters).
>>
>> -- 
>> Bruno
>>
>> -- 
>> 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/YHisTgbrKAXTKBtJ%40postle.net
>> .
>>
>

-- 
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/65ec62a8-3fec-4dd8-971c-fdd101d666c4n%40googlegroups.com.

Re: [hugin-ptx] enblend error while stiching large image

[Monkey]

That looks almost right, but you should mask out that darkened corner as 
well. And for the other images you just need to make sure you haven't left 
any of those darkened parts in (even if they are small they can 
disproportionately affect the blend).

Given the nature of the images you can be pretty aggressive in masking out, 
at least when using Multiblend - it only needs a tiny overlap to avoid 
leaving a blank area, and will blend images even if they don't overlap.

On Tuesday, 13 April 2021 at 22:59:41 UTC+1 Jared wrote:

> With enblend.  I just re-tested with multiblend and get roughly the same 
> results.  Yes, reasonably sure I masked that out.  Here's an example, just 
> to verify I didn't misunderstand you again:
> https://boxdog.legroom.net/public/ffmap-mask.jpg
>
> I created a mask like that on all 8 source images to mask the square.  Is 
> that what you mean?
>
> On Tuesday, April 13, 2021 at 3:49:15 AM UTC-5 Monkey wrote:
>
>> Was that with Enblend or Multiblend? Have you made sure to mask out the 
>> shadowed/darkened strip at the edge, as well as the actual square?
>>
>> On Tuesday, 13 April 2021 at 05:19:41 UTC+1 Jared wrote:
>>
>>> Ah.  Well that makes much more sense.  Sorry, that's my bad.  So what 
>>> you're seeing is a square that I use to align stuff on my scanner - just 
>>> aligning against any of the edges around the glass results in the sides of 
>>> the image being cropped off.  I didn't think it'd have an effect on the 
>>> blending process, so I had planned to crop it out of the stitched image.
>>>
>>> Here's my latest attempt:
>>> https://boxdog.legroom.net/public/ffmap-example3.jpg
>>>
>>> Sadly, not much of an improvement.  Actually a bit worse, as the middle 
>>> section is darker now as well.  After applying the mask, I generated one 
>>> image with no other changes (not shown - pretty much the same as example2, 
>>> though), and then for this image I clicked Calculate for Optimize, 
>>> Photometric, Low dynamic range, variable white balance.  Is there some 
>>> other option I should try to apply proper blending after that border is 
>>> masked out?
>>>
>>> Again, I appreciate the continued support.
>>>
>>>
>>> On Monday, April 12, 2021 at 7:13:08 PM UTC-5 Monkey wrote:
>>>
>>>> That's not the border I meant. It's the thin gray border with black 
>>>> lines which is at the top and/or left and/or bottom of *all* the 
>>>> images. It might be part of the scanner lid being visible or something you 
>>>> put behind the folded page.
>>>>
>>>> On Monday, 12 April 2021 at 21:34:06 UTC+1 Jared wrote:
>>>>
>>>>> Ha.  So keeping in mind I'm new to hugin and figuring this out as I 
>>>>> go, my first attempt at creating a mask didn't exactly go as planned.  
>>>>> Here's a screenshot of the resulting image:
>>>>> https://boxdog.legroom.net/public/ffmap-example2.jpg
>>>>>
>>>>> Technically I think I did mask that out, but I'm guessing that's not 
>>>>> what you had in mind.  :-)
>>>>>
>>>>> So that's the result of an exclude mask that I added to the two 
>>>>> left-most source images.  Can you provide any more detail on how I 
>>>>> *should* 
>>>>> create that mask?  I tried referencing the mask tutorial (
>>>>> http://hugin.sourceforge.net/tutorials/Blend-masks/en.shtml), but it 
>>>>> seems like that's addressing a fundamentally different issue, so wasn't 
>>>>> sure how to apply that to this image.
>>>>>
>>>>> On Monday, April 12, 2021 at 6:25:13 AM UTC-5 Monkey wrote:
>>>>>
>>>>>> The problem is the grey border with black lines on the top and left 
>>>>>> of the images (and the shadow it casts on the page). Mask those out and 
>>>>>> it 
>>>>>> should then blend as expected.
>>>>>>
>>>>>> On Monday, 12 April 2021 at 03:46:41 UTC+1 Jared wrote:
>>>>>>
>>>>>>> Hello.  Appreciate your continued guidance on this.  I got the 
>>>>>>> canvas size down to a usable state so I can open it in GIMP now.  Still 
>>>>>>> having trouble with the blending, though.  I tried Bruno's white 
>>>>>>> balance 
>>>>>>> suggestion, and then spent a while fiddling with a bu

Re: [hugin-ptx] enblend error while stiching large image

[Monkey]

Was that with Enblend or Multiblend? Have you made sure to mask out the 
shadowed/darkened strip at the edge, as well as the actual square?

On Tuesday, 13 April 2021 at 05:19:41 UTC+1 Jared wrote:

> Ah.  Well that makes much more sense.  Sorry, that's my bad.  So what 
> you're seeing is a square that I use to align stuff on my scanner - just 
> aligning against any of the edges around the glass results in the sides of 
> the image being cropped off.  I didn't think it'd have an effect on the 
> blending process, so I had planned to crop it out of the stitched image.
>
> Here's my latest attempt:
> https://boxdog.legroom.net/public/ffmap-example3.jpg
>
> Sadly, not much of an improvement.  Actually a bit worse, as the middle 
> section is darker now as well.  After applying the mask, I generated one 
> image with no other changes (not shown - pretty much the same as example2, 
> though), and then for this image I clicked Calculate for Optimize, 
> Photometric, Low dynamic range, variable white balance.  Is there some 
> other option I should try to apply proper blending after that border is 
> masked out?
>
> Again, I appreciate the continued support.
>
>
> On Monday, April 12, 2021 at 7:13:08 PM UTC-5 Monkey wrote:
>
>> That's not the border I meant. It's the thin gray border with black lines 
>> which is at the top and/or left and/or bottom of *all* the images. It 
>> might be part of the scanner lid being visible or something you put behind 
>> the folded page.
>>
>> On Monday, 12 April 2021 at 21:34:06 UTC+1 Jared wrote:
>>
>>> Ha.  So keeping in mind I'm new to hugin and figuring this out as I go, 
>>> my first attempt at creating a mask didn't exactly go as planned.  Here's a 
>>> screenshot of the resulting image:
>>> https://boxdog.legroom.net/public/ffmap-example2.jpg
>>>
>>> Technically I think I did mask that out, but I'm guessing that's not 
>>> what you had in mind.  :-)
>>>
>>> So that's the result of an exclude mask that I added to the two 
>>> left-most source images.  Can you provide any more detail on how I *should* 
>>> create that mask?  I tried referencing the mask tutorial (
>>> http://hugin.sourceforge.net/tutorials/Blend-masks/en.shtml), but it 
>>> seems like that's addressing a fundamentally different issue, so wasn't 
>>> sure how to apply that to this image.
>>>
>>> On Monday, April 12, 2021 at 6:25:13 AM UTC-5 Monkey wrote:
>>>
>>>> The problem is the grey border with black lines on the top and left of 
>>>> the images (and the shadow it casts on the page). Mask those out and it 
>>>> should then blend as expected.
>>>>
>>>> On Monday, 12 April 2021 at 03:46:41 UTC+1 Jared wrote:
>>>>
>>>>> Hello.  Appreciate your continued guidance on this.  I got the canvas 
>>>>> size down to a usable state so I can open it in GIMP now.  Still having 
>>>>> trouble with the blending, though.  I tried Bruno's white balance 
>>>>> suggestion, and then spent a while fiddling with a bunch of different 
>>>>> options to see if I could come up with anything, but no luck.  I've 
>>>>> uploaded scaled versions of the remmaped files, plus the full image and 
>>>>> PTO 
>>>>> file for reference, here:
>>>>>
>>>>> https://boxdog.legroom.net/public/transfer/
>>>>>
>>>>> Looking closely at the source images, it looks like there is a little 
>>>>> color difference between the two left-most segments and the rest of the 
>>>>> map 
>>>>> (even though it was all scanned under the same conditions), but nowhere 
>>>>> near what's shown in the final image.  I also noticed that the second 
>>>>> column is oddly darker as well - look at the water below point 2 and to 
>>>>> the 
>>>>> left of point 1 around the bottom center of the map.  All of the water 
>>>>> should be a reasonably uniform blue, except for those 4 stains in the 
>>>>> upper-left.
>>>>>
>>>>> On Wednesday, April 7, 2021 at 5:48:32 AM UTC-5 Monkey wrote:
>>>>>
>>>>>> If the remapped images don't show the difference in colour, but the 
>>>>>> blend still does, could you output a reduced size remapped image set and 
>>>>>> upload it somewhere?
>>>>>>
>>>>>> On Tuesday, 6 April

Re: [hugin-ptx] enblend error while stiching large image

[Monkey]

That's not the border I meant. It's the thin gray border with black lines 
which is at the top and/or left and/or bottom of *all* the images. It might 
be part of the scanner lid being visible or something you put behind the 
folded page.

On Monday, 12 April 2021 at 21:34:06 UTC+1 Jared wrote:

> Ha.  So keeping in mind I'm new to hugin and figuring this out as I go, my 
> first attempt at creating a mask didn't exactly go as planned.  Here's a 
> screenshot of the resulting image:
> https://boxdog.legroom.net/public/ffmap-example2.jpg
>
> Technically I think I did mask that out, but I'm guessing that's not what 
> you had in mind.  :-)
>
> So that's the result of an exclude mask that I added to the two left-most 
> source images.  Can you provide any more detail on how I *should* create 
> that mask?  I tried referencing the mask tutorial (
> http://hugin.sourceforge.net/tutorials/Blend-masks/en.shtml), but it 
> seems like that's addressing a fundamentally different issue, so wasn't 
> sure how to apply that to this image.
>
> On Monday, April 12, 2021 at 6:25:13 AM UTC-5 Monkey wrote:
>
>> The problem is the grey border with black lines on the top and left of 
>> the images (and the shadow it casts on the page). Mask those out and it 
>> should then blend as expected.
>>
>> On Monday, 12 April 2021 at 03:46:41 UTC+1 Jared wrote:
>>
>>> Hello.  Appreciate your continued guidance on this.  I got the canvas 
>>> size down to a usable state so I can open it in GIMP now.  Still having 
>>> trouble with the blending, though.  I tried Bruno's white balance 
>>> suggestion, and then spent a while fiddling with a bunch of different 
>>> options to see if I could come up with anything, but no luck.  I've 
>>> uploaded scaled versions of the remmaped files, plus the full image and PTO 
>>> file for reference, here:
>>>
>>> https://boxdog.legroom.net/public/transfer/
>>>
>>> Looking closely at the source images, it looks like there is a little 
>>> color difference between the two left-most segments and the rest of the map 
>>> (even though it was all scanned under the same conditions), but nowhere 
>>> near what's shown in the final image.  I also noticed that the second 
>>> column is oddly darker as well - look at the water below point 2 and to the 
>>> left of point 1 around the bottom center of the map.  All of the water 
>>> should be a reasonably uniform blue, except for those 4 stains in the 
>>> upper-left.
>>>
>>> On Wednesday, April 7, 2021 at 5:48:32 AM UTC-5 Monkey wrote:
>>>
>>>> If the remapped images don't show the difference in colour, but the 
>>>> blend still does, could you output a reduced size remapped image set and 
>>>> upload it somewhere?
>>>>
>>>> On Tuesday, 6 April 2021 at 22:00:38 UTC+1 bruno...@gmail.com wrote:
>>>>
>>>>> On Tue 06-Apr-2021 at 13:46 -0700, Jared wrote: 
>>>>> > 
>>>>> >I have one additional question, if you don't mind - the stiching came 
>>>>> out 
>>>>> >well, but the blending is off. Here's a much smaller version of the 
>>>>> >stiched image for reference: 
>>>>> >https://boxdog.legroom.net/public/ffmap-example.jpg 
>>>>> > 
>>>>> >Note that the left column is darker than the rest. The source images 
>>>>> >aren't like that - they're uniformly blue. I suspect it's those dark 
>>>>> >splotches, I guess some kind of oil or water stains, that's throwing 
>>>>> off 
>>>>> >the blending. Is there any reasonably straightforward way to tune 
>>>>> that to 
>>>>> >get the original brighter blue across the full image? Both enblend 
>>>>> and 
>>>>> >multiblend produced similar results. 
>>>>>
>>>>> Hugin will try and optimise the brightness and colour of your images 
>>>>> to match if you ask it to, but your PTO project has default values 
>>>>> for photometric parameters. So it looks like your photos are 
>>>>> different somehow. 
>>>>>
>>>>> In the Photos tab, optimise Photometric -> Low dynamic range, 
>>>>> variable white balance. 
>>>>>
>>>>> -- 
>>>>> Bruno 
>>>>>
>>>>

-- 
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/04c75df0-4424-4d85-a17b-94bc96bf4a52n%40googlegroups.com.

Re: [hugin-ptx] enblend error while stiching large image

[Monkey]

The problem is the grey border with black lines on the top and left of the 
images (and the shadow it casts on the page). Mask those out and it should 
then blend as expected.

On Monday, 12 April 2021 at 03:46:41 UTC+1 Jared wrote:

> Hello.  Appreciate your continued guidance on this.  I got the canvas size 
> down to a usable state so I can open it in GIMP now.  Still having trouble 
> with the blending, though.  I tried Bruno's white balance suggestion, and 
> then spent a while fiddling with a bunch of different options to see if I 
> could come up with anything, but no luck.  I've uploaded scaled versions of 
> the remmaped files, plus the full image and PTO file for reference, here:
>
> https://boxdog.legroom.net/public/transfer/
>
> Looking closely at the source images, it looks like there is a little 
> color difference between the two left-most segments and the rest of the map 
> (even though it was all scanned under the same conditions), but nowhere 
> near what's shown in the final image.  I also noticed that the second 
> column is oddly darker as well - look at the water below point 2 and to the 
> left of point 1 around the bottom center of the map.  All of the water 
> should be a reasonably uniform blue, except for those 4 stains in the 
> upper-left.
>
> On Wednesday, April 7, 2021 at 5:48:32 AM UTC-5 Monkey wrote:
>
>> If the remapped images don't show the difference in colour, but the blend 
>> still does, could you output a reduced size remapped image set and upload 
>> it somewhere?
>>
>> On Tuesday, 6 April 2021 at 22:00:38 UTC+1 bruno...@gmail.com wrote:
>>
>>> On Tue 06-Apr-2021 at 13:46 -0700, Jared wrote: 
>>> > 
>>> >I have one additional question, if you don't mind - the stiching came 
>>> out 
>>> >well, but the blending is off. Here's a much smaller version of the 
>>> >stiched image for reference: 
>>> >https://boxdog.legroom.net/public/ffmap-example.jpg 
>>> > 
>>> >Note that the left column is darker than the rest. The source images 
>>> >aren't like that - they're uniformly blue. I suspect it's those dark 
>>> >splotches, I guess some kind of oil or water stains, that's throwing 
>>> off 
>>> >the blending. Is there any reasonably straightforward way to tune that 
>>> to 
>>> >get the original brighter blue across the full image? Both enblend and 
>>> >multiblend produced similar results. 
>>>
>>> Hugin will try and optimise the brightness and colour of your images 
>>> to match if you ask it to, but your PTO project has default values 
>>> for photometric parameters. So it looks like your photos are 
>>> different somehow. 
>>>
>>> In the Photos tab, optimise Photometric -> Low dynamic range, 
>>> variable white balance. 
>>>
>>> -- 
>>> Bruno 
>>>
>>

-- 
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/9179687f-e14f-441a-8b41-e34990bcaa0bn%40googlegroups.com.

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

[Monkey]

https://i.imgur.com/RPTbrDs.png

This image shows a rough analysis of the image set. A red line indicates 
that cpfind was not able to find sensible control points between images. 
The coloured areas show the largest fully connected areas which should 
stitch reasonably well, assuming the remaining control points are actually 
good. As you can see, the sea and the sky are going to be a problem...

On Friday, 9 April 2021 at 15:25:11 UTC+1 Monkey wrote:

> Okay, I haven't got finished PHP scripts yet but (for me, anyway) it's the 
> way to go.
>
> In preparation, can you download the top zip file from here: 
> https://windows.php.net/download#php-8.0
> Extract the contents to C:\php (or any other folder, doesn't have to be on 
> C: and doesn't have to be the same drive as your photos)
> Add C:\php (or your chosen path) to your "Path" Environment variable 
> (Right click My Computer, go to Advanced System Settings, click Environment 
> Variables button. Or search "Environment Variables" in Settings)
> Open a command line prompt and type *php --version* [ENTER] to confirm 
> it's working.
>
> If you haven't got one already, I'd recommend setting up a project folder, 
> with a "Photos" folder in it containing the full set of photos. PHP scripts 
> will go in the project folder.
>

-- 
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/66132717-2f73-4f30-83c6-31d7f2a0c8ddn%40googlegroups.com.

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

[Monkey]

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/c647a12b-63d8-48f8-b409-0bfbe191f6a7n%40googlegroups.com.

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

[Monkey]

Okay, I haven't got finished PHP scripts yet but (for me, anyway) it's the 
way to go.

In preparation, can you download the top zip file from here: 
https://windows.php.net/download#php-8.0
Extract the contents to C:\php (or any other folder, doesn't have to be on 
C: and doesn't have to be the same drive as your photos)
Add C:\php (or your chosen path) to your "Path" Environment variable (Right 
click My Computer, go to Advanced System Settings, click Environment 
Variables button. Or search "Environment Variables" in Settings)
Open a command line prompt and type *php --version* [ENTER] to confirm it's 
working.

If you haven't got one already, I'd recommend setting up a project folder, 
with a "Photos" folder in it containing the full set of photos. PHP scripts 
will go in the project folder.

-- 
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/2d085f2b-0099-4c8b-809f-0178a7b1771fn%40googlegroups.com.

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

[Monkey]

What OS are you using? Are you au fait with using PHP on the command line?

You can definitely cut the overlap back as the images are all well matched 
for exposure and there's no vignetting. Multiblend doesn't actually need 
*any* overlap to blend images, but I'd say 5% minimum to be safe, or 10% to 
be a good balance between blending and number of images needed.
On Wednesday, 7 April 2021 at 14:54:00 UTC+1 ryanf...@gmail.com wrote:

> Here is the whole image set so you can pick and choose (may still be 
> uploading for a while), this is 123 rows x 66 columns ordered left to 
> right, the focus was not perfect in all shots, expecially the trees on the 
> right hand side of the bottom few rows, a lens like this has a depth of 
> feild of about 50m at 1km, 
>
> https://ln.sync.com/dl/4d2d48830/fe4ajnhj-6qy45ytu-catktz9g-w6gusyk8
>
> I'm in the process of modifying the mount to be a little more wind 
> resistant to reduce how much it is able to shift, to hopefully cut back the 
> overlap % a little, and making my canon camera play nice with the focuser 
> on the lens, as this batch was manually focused, 
>
> When that is resolved, I'm likely going to try it again, aswell as noting 
> the exact feild of veiw so I can feed it in to the stitching program
> On Wednesday, 7 April 2021 at 8:45:08 pm UTC+10 Monkey wrote:
>
>> Gigapxtools looks to be an extremely piece of software. As far as I can 
>> see it just splits or tiles images, with no alignment, overlap, or blending.
>>
>> ryanf, could you upload a few of your test images somewhere? Say, a 
>> square of 9, or maybe 25? I'm thinking you might need something more 
>> bespoke to achieve your goal, which I'd be interested in helping with, as 
>> I'd love to be able to confirm that Multiblend can blend a terapixel image 
>> (it should take somewhere on the order of days, and you'll need a few dozen 
>> terabytes of storage). The fact that the images are taken with such a long 
>> - and, one assumes, extremely good - lens, and with a motorised mount, 
>> should make a lot of the usual Hugin workflow redundant and we go straight 
>> to playing directly with images.
>> On Tuesday, 6 April 2021 at 21:51:35 UTC+1 ryanf...@gmail.com wrote:
>>
>>> Monkey, its 0.44x0.67 degree per image, or about 0.3 square degrees. the 
>>> total image is going to be roughly 180x90 or 270x60, though I will have 
>>> some margin on the sides, the goal is to exceed 1 Terapixel 
>>>
>>> GnomeNomad, Thanks I'll check that out, 
>>>
>>> On Wednesday, 7 April 2021 at 3:22:08 am UTC+10 GnomeNomad wrote:
>>>
>>>> Hmmm, maybe something here could handle? 
>>>>
>>>> https://gigapxtools.com/ 
>>>>
>>>> On April 6, 2021 6:24:42 AM HST, Monkey  wrote: 
>>>> > Well that's ambitious! If you know how the images overlap, one could 
>>>> > call 
>>>> > cpfind manually on each valid image pair just to get the control 
>>>> > points for 
>>>> > that pair, then combine all the pairs' control points into one big 
>>>> > project 
>>>> > file. I think actually using the Hugin GUI might be out of the 
>>>> > question - 
>>>> > unless you replace the images themselves with 1x1 pixel dummies, and 
>>>> > even 
>>>> > that might not work - but you might be able to use the command line 
>>>> > tools 
>>>> > by themselves to optimise and remap the images. How long it would 
>>>> take 
>>>> > is 
>>>> > another question entirely... 
>>>> > 
>>>> > So, 100,000 images with a 1900mm lens... is the end result to be 
>>>> > 360x180, 
>>>> > with each image covering a little under a square degree? 
>>>> > On Tuesday, 6 April 2021 at 14:02:39 UTC+1 ryanf...@gmail.com wrote: 
>>>> > 
>>>> > > Would any of you know any good software (free or otherwise), to put 
>>>> > > together my small scale trial pano of 8118 photos, (Full scale is 
>>>> > hoped to 
>>>> > > be 70,000-110,000) shot on a 1900mm lens with a crop factor of 1.62 
>>>> > for 
>>>> > > those interested 
>>>> > > 
>>>> > > Hugin seems to crash on trying to open that many files, and seems 
>>>> to 
>>>> > lack 
>>>> > > an easy way to tell it the positions of each of the photos before 
>>>> > aligning 
>>>> >

Re: [hugin-ptx] enblend error while stiching large image

[Monkey]

If the remapped images don't show the difference in colour, but the blend 
still does, could you output a reduced size remapped image set and upload 
it somewhere?

On Tuesday, 6 April 2021 at 22:00:38 UTC+1 bruno...@gmail.com wrote:

> On Tue 06-Apr-2021 at 13:46 -0700, Jared wrote:
> >
> >I have one additional question, if you don't mind - the stiching came out
> >well, but the blending is off. Here's a much smaller version of the
> >stiched image for reference:
> >https://boxdog.legroom.net/public/ffmap-example.jpg
> >
> >Note that the left column is darker than the rest. The source images
> >aren't like that - they're uniformly blue. I suspect it's those dark
> >splotches, I guess some kind of oil or water stains, that's throwing off
> >the blending. Is there any reasonably straightforward way to tune that to
> >get the original brighter blue across the full image? Both enblend and
> >multiblend produced similar results.
>
> Hugin will try and optimise the brightness and colour of your images 
> to match if you ask it to, but your PTO project has default values 
> for photometric parameters. So it looks like your photos are 
> different somehow.
>
> In the Photos tab, optimise Photometric -> Low dynamic range, 
> variable white balance.
>
> -- 
> Bruno
>

-- 
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/dae1bcd5-384f-41ce-aa37-11550a5a1760n%40googlegroups.com.

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

[Monkey]

Gigapxtools looks to be an extremely piece of software. As far as I can see 
it just splits or tiles images, with no alignment, overlap, or blending.

ryanf, could you upload a few of your test images somewhere? Say, a square 
of 9, or maybe 25? I'm thinking you might need something more bespoke to 
achieve your goal, which I'd be interested in helping with, as I'd love to 
be able to confirm that Multiblend can blend a terapixel image (it should 
take somewhere on the order of days, and you'll need a few dozen terabytes 
of storage). The fact that the images are taken with such a long - and, one 
assumes, extremely good - lens, and with a motorised mount, should make a 
lot of the usual Hugin workflow redundant and we go straight to playing 
directly with images.
On Tuesday, 6 April 2021 at 21:51:35 UTC+1 ryanf...@gmail.com wrote:

> Monkey, its 0.44x0.67 degree per image, or about 0.3 square degrees. the 
> total image is going to be roughly 180x90 or 270x60, though I will have 
> some margin on the sides, the goal is to exceed 1 Terapixel 
>
> GnomeNomad, Thanks I'll check that out, 
>
> On Wednesday, 7 April 2021 at 3:22:08 am UTC+10 GnomeNomad wrote:
>
>> Hmmm, maybe something here could handle?
>>
>> https://gigapxtools.com/
>>
>> On April 6, 2021 6:24:42 AM HST, Monkey  wrote:
>> > Well that's ambitious! If you know how the images overlap, one could
>> > call 
>> > cpfind manually on each valid image pair just to get the control
>> > points for 
>> > that pair, then combine all the pairs' control points into one big
>> > project 
>> > file. I think actually using the Hugin GUI might be out of the
>> > question - 
>> > unless you replace the images themselves with 1x1 pixel dummies, and
>> > even 
>> > that might not work - but you might be able to use the command line
>> > tools 
>> > by themselves to optimise and remap the images. How long it would take
>> > is 
>> > another question entirely...
>> > 
>> > So, 100,000 images with a 1900mm lens... is the end result to be
>> > 360x180, 
>> > with each image covering a little under a square degree?
>> > On Tuesday, 6 April 2021 at 14:02:39 UTC+1 ryanf...@gmail.com wrote:
>> > 
>> > > Would any of you know any good software (free or otherwise), to put 
>> > > together my small scale trial pano of 8118 photos, (Full scale is
>> > hoped to 
>> > > be 70,000-110,000) shot on a 1900mm lens with a crop factor of 1.62
>> > for 
>> > > those interested
>> > >
>> > > Hugin seems to crash on trying to open that many files, and seems to
>> > lack 
>> > > an easy way to tell it the positions of each of the photos before
>> > aligning 
>> > > when a smaller subset is used (was taken on a computerised mount)
>> > >
>> > > Image composition Editor will begrudgingly handle it, but the export
>> > is 
>> > > either limited to less than 65535 in any dimension due to windows
>> > .NET 
>> > > limitations, or the adobe output that after 3 days was 1% done, and
>> > lacked 
>> > > means to fix a few stitching errors, (Have looked into patching the
>> > .NET 
>> > > libraries without much success)
>> > >
>> > > I have 256GB of RAM, and many Terabytes of fast storage, so
>> > computational 
>> > > resources are not an issue, only software that will actually deal
>> > with it, 
>> > > as this was a 1/10th scale test run before I invest the time in the
>> > full 
>> > > scale ones, I'm hoping someone e.g. dealing with night sky mosaics
>> > of sky 
>> > > surveys might have a suggestion, or some means of making hugin work
>> > for it?
>> > >
>>
>>
>>
>> -- 
>> David W. Jones
>> gnome...@gmail.com
>> wandering the landscape of god
>> http://dancingtreefrog.com
>>
>> Sent from my Android device with F/LOSS K-9 Mail.
>>
>

-- 
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/fb7f4aba-1baf-4334-a2fb-a40f289fe2c8n%40googlegroups.com.

[hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

[Monkey]

Well that's ambitious! If you know how the images overlap, one could call 
cpfind manually on each valid image pair just to get the control points for 
that pair, then combine all the pairs' control points into one big project 
file. I think actually using the Hugin GUI might be out of the question - 
unless you replace the images themselves with 1x1 pixel dummies, and even 
that might not work - but you might be able to use the command line tools 
by themselves to optimise and remap the images. How long it would take is 
another question entirely...

So, 100,000 images with a 1900mm lens... is the end result to be 360x180, 
with each image covering a little under a square degree?
On Tuesday, 6 April 2021 at 14:02:39 UTC+1 ryanf...@gmail.com wrote:

> Would any of you know any good software (free or otherwise), to put 
> together my small scale trial pano of 8118 photos, (Full scale is hoped to 
> be 70,000-110,000) shot on a 1900mm lens with a crop factor of 1.62 for 
> those interested
>
> Hugin seems to crash on trying to open that many files, and seems to lack 
> an easy way to tell it the positions of each of the photos before aligning 
> when a smaller subset is used (was taken on a computerised mount)
>
> Image composition Editor will begrudgingly handle it, but the export is 
> either limited to less than 65535 in any dimension due to windows .NET 
> limitations, or the adobe output that after 3 days was 1% done, and lacked 
> means to fix a few stitching errors, (Have looked into patching the .NET 
> libraries without much success)
>
> I have 256GB of RAM, and many Terabytes of fast storage, so computational 
> resources are not an issue, only software that will actually deal with it, 
> as this was a 1/10th scale test run before I invest the time in the full 
> scale ones, I'm hoping someone e.g. dealing with night sky mosaics of sky 
> surveys might have a suggestion, or some means of making hugin work for it?
>

-- 
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/24699ed4-0005-4b68-96c9-68d2224a1432n%40googlegroups.com.

[hugin-ptx] Re: enblend error while stiching large image

[Monkey]

I think Enblend doesn't like some of the pixel values in your images. You 
could try specifying a different blend colorspace 
(--blend-colorspace=IDENTITY might be a good option, but I'm just 
guessing). Or you could try Multiblend , 
which has no such colourspace qualms (though only because it ignores 
colourspaces completely) and is a LOT quicker.
On Tuesday, 6 April 2021 at 07:50:42 UTC+1 Jared wrote:

>
> Hello, all.  New hugin user here.  I'm trying to stich together a scanned 
> poster comprised of 8 different parts using the scanning tutorial here:
> http://hugin.sourceforge.net/tutorials/scans/en.shtml
>
> I *think* I did everything correctly, but when stitching it fails with 
> this error:
>
> Blending images...
> enblend: info: loading next image: ffmap2.tif 1/1
> enblend: info: loading next image: ffmap20001.tif 1/1
> enblend: 
> /tmp/portage/media-gfx/enblend-4.2.0_p20161007-r1/work/enblend-4.2.0_p20161007/src/fixmath.h:487:
>  
> double enblend::PyramidScale PyramidFractionBits>::scale_lightness_for_pyramid(double) const [with int 
> PyramidIntegerBits = 9; int PyramidFractionBits = 7]: Assertion `result >= 
> 0.0' failed.
>
> I tried multiple times but always get the same error.  The images are 
> large, about maybe 300 MB TIFFs (x8) when uncompressed, so I thought maybe 
> I was running out of RAM or disk or something, but I have 32 GB of ram and 
> still had 14.5 GB reported free when running in a 1 second loop the last 
> time it failed.  Disk also looks good.
>
> As mentioned, I'm new to hugin, so I could certainly be doing something 
> wrong myself.  Also may be running into some kind of size limits (though 
> that seems unlikely) or maybe a bug.  Would appreciate if anyone can 
> provide some guidance on how to resolve, or at least further troubleshoot.
>
> Here's the full log:
> https://boxdog.legroom.net/public/ffmap2.log
>
> And the PTO file for reference:
> https://boxdog.legroom.net/public/ffmap2.pto
>
> Thanks!
>
> -- 
> Jared
>

-- 
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/577023ba-40e1-45c4-bf60-96aadbf836f7n%40googlegroups.com.

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

[Monkey]

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 give you enough RAM to finish.

I'll try to implement cacheable, reallocable Flex class data in a future 
version.
On Saturday, 3 April 2021 at 17:14:29 UTC+1 bul...@gmail.com wrote:

> 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 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/377336d4-3e1b-4cda-af6f-6076f5cde8b2n%40googlegroups.com.

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

[Monkey]

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 bul...@gmail.com wrote:

> 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 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/05e17ce1-453d-42a1-92ce-9d5449e25b47n%40googlegroups.com.

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

[Monkey]

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 bug)

Line 424 of functions.cpp should read:

for (i = 0; i < 5; ++i) delete*[]* real_lines[i];

Line 90 of functions.cpp should read:

delete*[]* rows;

This just leaves a bunch of indirect leaks which I should probably clean up 
one day just to be nice about it but don't have any effect on execution.
On Saturday, 3 April 2021 at 13:59:33 UTC+1 Monkey wrote:

> 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 
> source download.
> On Friday, 2 April 2021 at 08:58:12 UTC+1 bul...@gmail.com wrote:
>
>> 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 0x55be84604975 bp 0x7ffd3aef4e90 sp 0x7ffd3aef4e80 
>> READ of size 1 at 0x611003b0 thread T0 
>>  
>> 
>>#0 0x55be84604974 in Threadpool::Wait() 
>> (/usr/src/multiblend2/src/multiblend+0x39974) 
>>#1 0x55be846147ed in Image::Read(void*, bool) 
>> (/usr/src/multiblend2/src/multiblend+0x497ed)
>>
>>
>> Il giorno domenica 7 marzo 2021 alle 14:00:01 UTC+1 Sergio Amateis ha 
>> scritto:
>>
>>> 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 
>>> another way to position them better, perhaps manually without using control 
>>> points?
>>>
>>> Il giorno domenica 7 marzo 2021 alle 00:14:00 UTC+1 Monkey ha scritto:
>>>
>>>> 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 sort by distance (highest first) you'll see a lot of control 
>>>> points in sky (click on each one to see them in the Control Point editor) 
>>>> with very high distances, which you should delete - they are either in 
>>>> blue 
>>>> sky, which can't make a good alignment and will drag the rest of the 
>>>> pictures out of alignment, or they are on clouds which move between shots. 
>>>> After deleting those and re-optimising, you should get a better final 
>>>> result - altough you could use more control points on the building, rather 
>>>> than (for example) on the tree behind it (right corner).
>>>>
>>>> David
>>>>
>>>> On Saturday, 6 March 2021 at 22:50:33 UTC ginos...@gmail.com wrote:
>>>>
>>>>> 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 the same 
>>>>> zones as enblend did, just displaced a little bit. Then I tried to remove 
>>>>> all masks and again stitch with enblend and multiblend. This time 
>>>>> multiblend shows a few more errors than enblend, but again, results are 
>>>>> similar.
>>>>>
>>>>> Aside from speed, should I find other advantages in multiblend? Is 
>>>>> there any parameter I can try, to improve the stiching precision ?
>>>>>
>>>>> Thank you
>>>>> Ginosergio
>>>>>
>>>>>
>>>>

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

[Monkey]

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 
source download.
On Friday, 2 April 2021 at 08:58:12 UTC+1 bul...@gmail.com wrote:

> 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 0x55be84604975 bp 0x7ffd3aef4e90 sp 0x7ffd3aef4e80 
> READ of size 1 at 0x611003b0 thread T0 
>   
>
>#0 0x55be84604974 in Threadpool::Wait() 
> (/usr/src/multiblend2/src/multiblend+0x39974) 
>#1 0x55be846147ed in Image::Read(void*, bool) 
> (/usr/src/multiblend2/src/multiblend+0x497ed)
>
>
> Il giorno domenica 7 marzo 2021 alle 14:00:01 UTC+1 Sergio Amateis ha 
> scritto:
>
>> 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 
>> another way to position them better, perhaps manually without using control 
>> points?
>>
>> Il giorno domenica 7 marzo 2021 alle 00:14:00 UTC+1 Monkey ha scritto:
>>
>>> 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 sort by distance (highest first) you'll see a lot of control 
>>> points in sky (click on each one to see them in the Control Point editor) 
>>> with very high distances, which you should delete - they are either in blue 
>>> sky, which can't make a good alignment and will drag the rest of the 
>>> pictures out of alignment, or they are on clouds which move between shots. 
>>> After deleting those and re-optimising, you should get a better final 
>>> result - altough you could use more control points on the building, rather 
>>> than (for example) on the tree behind it (right corner).
>>>
>>> David
>>>
>>> On Saturday, 6 March 2021 at 22:50:33 UTC ginos...@gmail.com wrote:
>>>
>>>> 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 the same 
>>>> zones as enblend did, just displaced a little bit. Then I tried to remove 
>>>> all masks and again stitch with enblend and multiblend. This time 
>>>> multiblend shows a few more errors than enblend, but again, results are 
>>>> similar.
>>>>
>>>> Aside from speed, should I find other advantages in multiblend? Is 
>>>> there any parameter I can try, to improve the stiching precision ?
>>>>
>>>> Thank you
>>>> Ginosergio
>>>>
>>>>
>>>> Il giorno sabato 6 marzo 2021 alle 17:50:43 UTC+1 Monkey ha scritto:
>>>>
>>>>> 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 particularly clever or unusual in Multiblend's code 
>>>>> - 
>>>>> no self-modifying code and no built-in compiler, one of which I have 
>>>>> previously written and which caused a lot of false positives. It could be 
>>>>> something as simple as its use of threads of memory-mapped files that 
>>>>> raises suspicions.
>>>>>
>>>>> As for the site itself, it might be blocked just because it d

Re: [hugin-ptx] Hugin freezing during blending

[Monkey]

Not that I would expect it to be default - I assume that's going to be 
Verdandi at some point - but what "necessary" features is it missing?

I believe Multiblend was at one point bundled with Hugin as an alternative 
to Enblend for a release or two, not sure why it was dropped.

On Sunday, 21 March 2021 at 09:34:58 UTC T. Modes wrote:

> gunter.ko...@gmail.com schrieb am Samstag, 20. März 2021 um 17:00:32 
> UTC+1:
>
>> Hmmm... One partially related question: Would it make sense to make 
>> multiblend the default for new hugin installs?
>>
>> Multiblend does not support all necessary features needed by Hugin. So it 
> can't currently be the default.
>

-- 
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/551fbedc-e96b-41c1-ab45-8af585d24be6n%40googlegroups.com.

Re: [hugin-ptx] Hugin freezing during blending

[Monkey]

Enblend is very slow. Multiblend is much, *much *quicker:

http://horman.net/multiblend/

You change the Hugin settings under the Programstab (Use alternative 
Enblend program) and point it to multiblend.exe instead.

On Friday, 19 March 2021 at 19:24:00 UTC MikaylaL wrote:

> Hi Bruno,
>
> Thanks so much! 
> Yes, it's the google earth logo. I left it because I figured the photos 
> overlapped enough it wouldn't be a problem. 
> I considered it may have just been taking a long time to process, but I 
> think what would happen is that it would eventually time-out on my computer 
> and end up failing. I will try again! Hopefully I can get it to work.
> Thanks again!
>
> Best,
> Mikayla
>
> On Friday, March 19, 2021 at 2:17:37 PM UTC-5 bruno...@gmail.com wrote:
>
>> Hi Mikayla, I can get it to stitch here, the enblend warning is just 
>> because the output panorama is very small (4096x2048), but this is 
>> ok. It takes a few minutes for enblend to blend everything 
>> together, maybe it was just taking a very long time.
>>
>> The images are all very precisely arranged in the panorama, but the 
>> control points make no sense - are these the correct positions for 
>> the photos? or do they need aligning?
>>
>> The control points are all clustered in a small rectangle at the 
>> bottom left of each image, is there a logo or something in every 
>> picture? If you want to generate control points you will first need 
>> to mask out this area using the Masks tab in the Panorama Editor.
>>
>> -- 
>> Bruno
>>
>> On Fri 19-Mar-2021 at 09:38 -0700, MikaylaL wrote:
>> >Sure!
>> >Thanks for taking a look!
>> >
>> >It occurred to me today that there is the possibility that it's a 
>> hardware
>> >issue, so I will be trying it on a different computer in the next few 
>> days.
>>
>> >On Friday, March 19, 2021 at 8:34:34 AM UTC-5 bruno wrote:
>> >
>> >> Hi Mikayla, this doesn't sound like a familiar problem, so we can't say
>> >> for sure. Please can you post a PTO project file so we can have a look 
>> (no
>> >> need to post the images).
>> >>
>> >> On 18 March 2021 15:35:22 GMT, Mikayla wrote:
>> >> >Hello!
>> >> >I'm very new to Hugin, so I apologize if this is a rudimentary 
>> question.
>> >> I
>> >> >am trying to stitch images taken from Google earth to create an
>> >> >equirectangular panorama shot. When I go to stitch the images, the
>> >> >commands freeze when it gets to:
>> >> >"Blending images...
>> >> >enblend: warning: input images too small for coarse mask
>> >> >enblend: note: switching to fine mask"
>> >> >I don't know what's happening or why It refuses to continue 
>> processing.
>> >> >
>> >> >Any help would be greatly appreciated!
>> >> >Thanks!
>>
>

-- 
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/beb088fc-a774-4dff-bf53-10143b1332bcn%40googlegroups.com.

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

[Monkey]

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 
sort by distance (highest first) you'll see a lot of control points in sky 
(click on each one to see them in the Control Point editor) with very high 
distances, which you should delete - they are either in blue sky, which 
can't make a good alignment and will drag the rest of the pictures out of 
alignment, or they are on clouds which move between shots. After deleting 
those and re-optimising, you should get a better final result - altough you 
could use more control points on the building, rather than (for example) on 
the tree behind it (right corner).

David

On Saturday, 6 March 2021 at 22:50:33 UTC ginos...@gmail.com wrote:

> 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 the same zones 
> as enblend did, just displaced a little bit. Then I tried to remove all 
> masks and again stitch with enblend and multiblend. This time multiblend 
> shows a few more errors than enblend, but again, results are similar.
>
> Aside from speed, should I find other advantages in multiblend? Is there 
> any parameter I can try, to improve the stiching precision ?
>
> Thank you
> Ginosergio
>
>
> Il giorno sabato 6 marzo 2021 alle 17:50:43 UTC+1 Monkey ha scritto:
>
>> 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 particularly clever or unusual in Multiblend's code - 
>> no self-modifying code and no built-in compiler, one of which I have 
>> previously written and which caused a lot of false positives. It could be 
>> something as simple as its use of threads of memory-mapped files that 
>> raises suspicions.
>>
>> As for the site itself, it might be blocked just because it doesn't have 
>> HTTPS (my current host is pretty terrible and their Let's Encrypt option 
>> doesn't work).
>>
>> On Saturday, 6 March 2021 at 15:44:27 UTC ginos...@gmail.com wrote:
>>
>>> 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 now on 
>>> 64bit)
>>> I'm starting to think I'll throw Bitdefender away when my subscription 
>>> expires.
>>>
>>> I will report again after some tests with my big 360 panoramas.
>>>
>>> Cheers
>>> Ginosergio
>>>
>>>
>>>
>>> Il giorno sabato 6 marzo 2021 alle 13:42:13 UTC+1 Monkey ha scritto:
>>>
>>>> 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:
>>>>> multiblend-dist/
>>>>> multiblend-dist/Libraries/
>>>>> multiblend-dist/Libraries/libz.1.2.11.dylib
>>>>> multiblend-dist/Libraries/libpng16.16.dylib
>>>>> multiblend-dist/Libraries/libzstd.1.4.8.dylib
>>>>> multiblend-dist/Libraries/libtiff.5.dylib
>>>>> multiblend-dist/Libraries/liblzma.5.dylib
>>>>> multiblend-dist/Libraries/libjpeg.8.2.2.dylib
>>>>> multiblend-dist/multiblend
>>>>>
>>>>> Removed a few "sloppy" things from the script:  
>>>>> https://mega.nz/file/FR9CxCpB#ucZGem59Z6n8jVP7NriuqKS9YwGvMtIok9DZqX75vro
>>>>>
>>>>> Harry
>>>>>
>>>>> Op za 6 mrt. 2021 om 13:02 schreef Monkey :
>>>>>
>>>>>> Fixed and updated, plus a fix to ignore (properly) an Enblend 
>>>>>

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

[Monkey]

Tried to build on Ubuntu Mate and got this:

/usr/include/Vc/scalar/../common/../sse/intrinsics.h:601:13: error: 
argument to '__builtin_ia32_vec_ext_v4sf' must be a constant integer
_MM_EXTRACT_FLOAT(f, v, i);
^~
/usr/lib/llvm-10/lib/clang/10.0.0/include/smmintrin.h:876:11: note: 
expanded from macro '_MM_EXTRACT_FLOAT'
  { (D) = __builtin_ia32_vec_ext_v4sf((__v4sf)(__m128)(X), (int)(N)); }
  ^
1 error generated.
make: *** [makefile:61: pv_avx.o] Error 1


On Saturday, 6 March 2021 at 19:03:45 UTC Yuv wrote:

> On Wed, 2021-03-03 at 17:54 +0100, 'Kay F. Jahnke' via hugin and other
> free panoramic software wrote:
> > Am 03.03.21 um 13:27 schrieb yuv:
> > 
> > > why not adding to pv the
> > > missing functions from Hugin rather than the other way around?
> > 
> > In a way this is what I've been doing.
>
> From far away, it looks like there are four alternatives:
> (a) do nothing;
> (b) distribute pv along Hugin;
> (c) integrate pv's functionalities into Hugin; or
> (d) integrate Hugin's functionalities into pv.
>
> How far is pv from being a replacement to Hugin, and do you see it
> going there?
>
> Conversely, how different is pv from Hugin and how difficult would be
> that integration work? I suspect that the use of a different GUI
> Toolkit is a major obstacle, but your expertise my intuition wrong?
>
> Which brings us to what I understand is your proposal, to distributed
> pv along Hugin. The cost to Hugin are "only" more build/distribution
> complexity. Or am I missing something? And it does not seem to be
> such a heavy toll, based on Harry's feedback here. Do the benefits to
> Hugin's users justify the extra build/distribution complexity? And are
> there things that can be done to reduce that complexity, e.g. moving pv
> from bitbucket to the same repo as Hugin?
>
> Distributing pv along Hugin would give pv more visibility, and
> photographers would receive an additional, valuable tool in their
> toolbox. But what would it give Hugin other than more
> build/distribution complexity? Note that the question is only meant to
> be thought-provoking and does not represent an opinion. It is only the
> opinion of those who do the heavy lifting that counts; and ultimately,
> like all open source project, the driver is user's need.
>
> Hugin is already a bundle of more or less integrated tools and
> libraries. It is proof that the unix philosophy of one tool for one
> task is not universal. One such limit is a GUI workflow tool like
> Hugin, where the integration of editing / stitiching / blending tools
> has enabled usability that was not available when all of these
> functions were in isolated single-purpose tools.
>
> Does it make sense to distribute Multiblend with Hugin as well, and
> integrate it as a possible worklfow option?
>
>
> > I decided [...] to *not* use a traditional GUI library 
> > like wxWidgets or Qt
>
> Maybe that is the technical obstacle, and need reconsideration? 
> Integration is a two-way street.
>
>
> > Look at my implementation of the B&A algorithm, and compare it
> > to 'traditional' approaches, and judge for yourself:
> > 
> > https://bitbucket.org/kfj/pv/src/master/pv_combine.cc
> > 
> > Compared to traditional code, this is alien technology.
>
> I am sure there are experts in alien technology. I am not one, don't
> ask for my judgment. All I see is a beautiful and useful tool that has
> fulfilled a niche left open by the existing tools. I see the same in
> Multiblend. And I recall how Hugin started as an overall GUI to
> visualize, control, and synchronize different such specialized tools.
>
> The general question becomes: what test need to be met for a tool to:
> (a) be distributed with Hugin (the minimum common denominator)?
> (b) get a tab or other UI element within Hugin as an addition to the
> existing tabs (i.e. pv as the third view mode)?
> (c) replace a tool within Hugin (IIRC some control point finders have
> been deprecated/removed)?
>
> With a clear set of rules for the above, you'd have a target to work
> toward.
>
> I, as an external spectator who no longer has the time to shoot, edit,
> stitch panos, can only cheer from the sidelines the efforts of
> developers and builders sharing their newest development and trying to
> make them work for the rest of us. 
> --
> Yuval Levy, JD, MBA, CFA
> Ontario-licensed lawyer
>
>
>

-- 
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/668f2c79-a410-450c-8e16-342069ad0c8an%40googlegroups.com.

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

[Monkey]

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 particularly clever or unusual in Multiblend's code - no 
self-modifying code and no built-in compiler, one of which I have 
previously written and which caused a lot of false positives. It could be 
something as simple as its use of threads of memory-mapped files that 
raises suspicions.

As for the site itself, it might be blocked just because it doesn't have 
HTTPS (my current host is pretty terrible and their Let's Encrypt option 
doesn't work).

On Saturday, 6 March 2021 at 15:44:27 UTC ginos...@gmail.com wrote:

> 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 now on 
> 64bit)
> I'm starting to think I'll throw Bitdefender away when my subscription 
> expires.
>
> I will report again after some tests with my big 360 panoramas.
>
> Cheers
> Ginosergio
>
>
>
> Il giorno sabato 6 marzo 2021 alle 13:42:13 UTC+1 Monkey ha scritto:
>
>> 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:
>>> multiblend-dist/
>>> multiblend-dist/Libraries/
>>> multiblend-dist/Libraries/libz.1.2.11.dylib
>>> multiblend-dist/Libraries/libpng16.16.dylib
>>> multiblend-dist/Libraries/libzstd.1.4.8.dylib
>>> multiblend-dist/Libraries/libtiff.5.dylib
>>> multiblend-dist/Libraries/liblzma.5.dylib
>>> multiblend-dist/Libraries/libjpeg.8.2.2.dylib
>>> multiblend-dist/multiblend
>>>
>>> Removed a few "sloppy" things from the script:  
>>> https://mega.nz/file/FR9CxCpB#ucZGem59Z6n8jVP7NriuqKS9YwGvMtIok9DZqX75vro
>>>
>>> Harry
>>>
>>> Op za 6 mrt. 2021 om 13:02 schreef Monkey :
>>>
>>>> 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 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 
>>>>>
>>>>> #include "tiffio.h"
>>>>> #include "jpeglib.h"
>>>>>
>>>>> with:
>>>>> #include 
>>>>> #ifdef __APPLE__
>>>>>   #define memalign(a,b) malloc((b))
>>>>> #else
>>>>>   #include 
>>>>> #endif
>>>>>
>>>>> #include "tiffio.h"
>>>>> #include "jpeglib.h"
>>>>>
>>>>> Please correct that before final 2.0 release.
>>>>> With that it builds fine on MacOS and runs fine under Hugin. I now 
>>>>> used Macports instead of homebrew, as I needed macports for pv.
>>>>> See attached your modified build.txt.
>>>>> I also created a distributable version: 
>>>>> https://mega.nz/file/VEkRlKLY#zt2oymaxcqi1gK-XrKzE0fGiPs8W3lYzXL2yuC89DFM
>>>>> Unzip the zip with paths (!) to some location of your liking. It will 
>>>>> create a folder multiblend-dist and inside you will find multiblend and 
>>>>> it's 3rd party necessary libraries.
>>>>> In Hugin preferences under programs select "use other enblend program" 
>>>>> and give the full path to multiblend.
>>>>>
>>>>> Script to create a distributable multiblend (using macports): 
>>>>> https://mega.nz/file/sc8hXIrT#6SYq8Dbei8KZZxoc

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

[Monkey]

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:
> multiblend-dist/
> multiblend-dist/Libraries/
> multiblend-dist/Libraries/libz.1.2.11.dylib
> multiblend-dist/Libraries/libpng16.16.dylib
> multiblend-dist/Libraries/libzstd.1.4.8.dylib
> multiblend-dist/Libraries/libtiff.5.dylib
> multiblend-dist/Libraries/liblzma.5.dylib
> multiblend-dist/Libraries/libjpeg.8.2.2.dylib
> multiblend-dist/multiblend
>
> Removed a few "sloppy" things from the script:  
> https://mega.nz/file/FR9CxCpB#ucZGem59Z6n8jVP7NriuqKS9YwGvMtIok9DZqX75vro
>
> Harry
>
> Op za 6 mrt. 2021 om 13:02 schreef Monkey :
>
>> 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 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 
>>>
>>> #include "tiffio.h"
>>> #include "jpeglib.h"
>>>
>>> with:
>>> #include 
>>> #ifdef __APPLE__
>>>   #define memalign(a,b) malloc((b))
>>> #else
>>>   #include 
>>> #endif
>>>
>>> #include "tiffio.h"
>>> #include "jpeglib.h"
>>>
>>> Please correct that before final 2.0 release.
>>> With that it builds fine on MacOS and runs fine under Hugin. I now used 
>>> Macports instead of homebrew, as I needed macports for pv.
>>> See attached your modified build.txt.
>>> I also created a distributable version: 
>>> https://mega.nz/file/VEkRlKLY#zt2oymaxcqi1gK-XrKzE0fGiPs8W3lYzXL2yuC89DFM
>>> Unzip the zip with paths (!) to some location of your liking. It will 
>>> create a folder multiblend-dist and inside you will find multiblend and 
>>> it's 3rd party necessary libraries.
>>> In Hugin preferences under programs select "use other enblend program" 
>>> and give the full path to multiblend.
>>>
>>> Script to create a distributable multiblend (using macports): 
>>> https://mega.nz/file/sc8hXIrT#6SYq8Dbei8KZZxocDQ9iSidv__qDJjc7RMaNCwTRFIo
>>> Create a "mac-dist" subfolder in your build directory and use the script 
>>> from there. Read the info in the script before use.
>>> Of course this script already expects a compiled multiblend in the build 
>>> folder.
>>>
>>> Hoi,
>>> Harry
>>>
>>>
>>> -- 
>> 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/2ea613a7-9e0f-4605-961a-63cf504d461dn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/hugin-ptx/2ea613a7-9e0f-4605-961a-63cf504d461dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/2e2ddf4f-5351-4ef4-ac8f-a4be17c05ff6n%40googlegroups.com.

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

[Monkey]

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 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 
>
> #include "tiffio.h"
> #include "jpeglib.h"
>
> with:
> #include 
> #ifdef __APPLE__
>   #define memalign(a,b) malloc((b))
> #else
>   #include 
> #endif
>
> #include "tiffio.h"
> #include "jpeglib.h"
>
> Please correct that before final 2.0 release.
> With that it builds fine on MacOS and runs fine under Hugin. I now used 
> Macports instead of homebrew, as I needed macports for pv.
> See attached your modified build.txt.
> I also created a distributable version: 
> https://mega.nz/file/VEkRlKLY#zt2oymaxcqi1gK-XrKzE0fGiPs8W3lYzXL2yuC89DFM
> Unzip the zip with paths (!) to some location of your liking. It will 
> create a folder multiblend-dist and inside you will find multiblend and 
> it's 3rd party necessary libraries.
> In Hugin preferences under programs select "use other enblend program" and 
> give the full path to multiblend.
>
> Script to create a distributable multiblend (using macports): 
> https://mega.nz/file/sc8hXIrT#6SYq8Dbei8KZZxocDQ9iSidv__qDJjc7RMaNCwTRFIo
> Create a "mac-dist" subfolder in your build directory and use the script 
> from there. Read the info in the script before use.
> Of course this script already expects a compiled multiblend in the build 
> folder.
>
> Hoi,
> Harry
>
>
>

-- 
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/2ea613a7-9e0f-4605-961a-63cf504d461dn%40googlegroups.com.

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

[Monkey]

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 -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 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.
> > 
>
> Do you have any build instructions?
> I have had a try at building it on Fedora 33, essentially using the rpm 
> spec
> file I used ages ago for 0.6.2, with attempts to fix as things went wrong, 
> but
> quickly came to a halt with this error, which crops up many times;
>
> /usr/lib/gcc/x86_64-redhat-linux/10/include/pmmintrin.h:56:1: error: 
> inlining
> failed in call to 'always_inline' '_mm_hadd_ps(float __vector(4), float
> __vector(4))': target specific option mismatch
> 56 | _mm_hadd_ps (__m128 __X, __m128 __Y)
> | ^~~
>
> I'm guessing a lot on this as I go.
> The build requirements for 0.6.2 were 'libtiff-devel libjpeg-devel libpng-
> devel', and I've assumed they will still be required. Are there other
> dependencies?
>
> Cheers,
> -- 
> Terry Duell 
>
>

-- 
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/d7c5af78-a7ad-4a38-bc00-d6ff1e065d29n%40googlegroups.com.

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

[Monkey]

 *(* 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/cd7c4beb-c236-4993-921b-75f62a1d788cn%40googlegroups.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

[Monkey]

> and it's use of image pyramids relies on a variant of image pyramids 
based on b-splines. 

> To me, the implementation of the Burt/Adelson Algorithm is a 
major breakthrough. 

Is there a simple way to explain how this/these differ from a standard 
Laplacian pyramid?

On Monday, 1 March 2021 at 07:40:46 UTC kfj wrote:

> Am 28.02.21 um 19:09 schrieb Harry van der Wolf:
>
> > I just build it on a Ubuntu derived 64bit system. It compiles fine.
>
> Great! Thanks for reporting back. Do try it out, and share your 
> experience. To me, the implementation of the Burt/Adelson Algorithm is a 
> major breakthrough.
>
> > Before testing further I did the same on my Debian 10 buster armhf 
> > Raspberry pi 4. Now it ends in error.
> > Don't put too much effort in it. The rpi4 is my server, but I just 
> > wanted to test if it would compile there (and then test it via tightvnc).
>
> pv is currently intel/AMD only, the Raspi uses an ARM processor. I'd 
> like to try a port to ARM eventually, especially to support newer macs, 
> but this will require a bit more fiddling than just supporting yet 
> another intel ISA.
>
> What would be required is quite different compiler flags for the 
> rendering code (so, not -mavx etc) and setting up the dispatcher to send 
> rendering jobs to the code with the right ISA.
>
> This should not be too hard if Vc supports ARM well, and if it doesn't, 
> pv can fall back on code which isn't using Vc. The problem is that I 
> don't have any ARM hardware, so it's hard for me to test. Would you like 
> to cooperate on an ARM port? I could produce code which should run on 
> ARM, but lacking testing hardware I'd probably need several attempts 
> before it comes out right. I'd set up an ARM branch, you can watch it 
> for new commits, try the build and communicate via the issue tracker.
>
> Kay
>
>

-- 
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/40deab61-8517-45f3-b492-175d106ff2d3n%40googlegroups.com.

Re: [hugin-ptx] Feature requests for Multiblend 2.0?

[Monkey]

Anyone on Mac OS who can check if it compiles if I email a link to the 
source?

On Friday, 12 February 2021 at 16:50:06 UTC bugbear...@gmail.com wrote:

> True as far as it goes.
>
> An OS will manage virtual memory, swapping data between RAM and Disc as 
> needed, normally in pages of some fixed size.
>
> However, if the application is "naive", some worst case behaviour can 
> emerge. Imagine an application that routinely access the first byte of a 
> page,
> and then accessed the first byte of every other page before re-accessing 
> the first byte of the first page again.
> The application is not addressing many BYTES, but it will thrash the 
> virtual memory badly. A typical image rotate will have this behaviour on 
> either source of destination.
>
> What you're aiming for is locality of accesses, where multiple accesses 
> all fall within a page. For raster graphics this can be achieved by 
> accessing data in a tiled way, so that adjacent pixels in both X and Y are 
> "near". This can be done WITHOUT a tiled virtual memory system, you just 
> need to access the data in a tiled order.
>
> This can be done by finding the pseudo-tile T a (x,y) coord is in (simple 
> divide X, Y by the the tile size), calculate the tile base address of the 
> tile T (T * tile_bytes) and then work out the offset of the data from the 
> tile base (x and y modulo tile side, then multiply the new Y by tile side).
>
> I has a fancy 2D Object browser on SunOs that was thrashing, and by simply 
> implementing "address_of_object()" as outlined above, the memory behaviour 
> was immaculate.
>
>BugBear
>
>

-- 
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/78e53b5c-9b93-46e8-a098-07c83e610358n%40googlegroups.com.

Re: [hugin-ptx] Feature requests for Multiblend 2.0?

[Monkey]

As I understand it, and I may not have this exactly right, an OS will 
manage memory up to the amount of physical memory. Cpfind was using 2Gb but 
this would have been swapped in and out of disk by the OS. Some versions of 
Enblend have their own caching.

Certainly, there is a harder limit defined by the size of the paging file. 
On Linux systems this might 1.5x - 2x the physical RAM. On my Windows 
computer, with 24Gb physical RAM, it's only currently 9Gb. I think it 
expands if required, but I did a quick test and I could not allocate 32Gb, 
despite having plenty of disk space. So I think each process is limited to 
24Gb, which may be partially on disk so that other processes can continue 
to run. That way, every process can have its own 24Gb, but no more.

By bypassing that and generating memory mapped files (when allocating RAM 
files), Multiblend will be able to use as much "RAM" as there is disk space.
On Friday, 12 February 2021 at 07:48:04 UTC GnomeNomad wrote:

> Hmm, I remember ages ago producing a 768MB panorama. Not a gigapixel 
> size image, of course. But I did it from the command line on a 32-bit 
> processor with 2GB RAM, starting with using cpfind on full-size 6mpx 
> images. Just running cpfind on a single image used 2GB RAM.
>
> That just puts things in perspective. It took that little old laptop 
> about 8 hours to stitch the final panorama. That was using enblend back 
> then, of course. So apparently Linux was transparently managing memory 
> behind the scene.
>
> I understand Photoshop does its own memory management, but it dates back 
> to the days when it ran under OSes that had no real memory management.
>
> So why does an app like multiblend need to do its own memory management?
>
> On 2/11/21 9:21 AM, Monkey wrote:
> > Output images that are bigger than RAM will be supported (on x64, at 
> > least; making the same available on x86 would be a /lot /more work). 
> > Input images that are bigger than RAM are not currently supported, but 
> > I'll see about adding that (if anyone's going to try blending gigapixel 
> > images together). It's done with plain memory mapped files rather than 
> > tiles.
> > On Thursday, 11 February 2021 at 18:39:34 UTC gunter.ko...@gmail.com 
> wrote:
> > 
> > gimp-like memory management that allows to handle target images that
> > are bigger than the RAM. don't know if it is already implemented.
> > 
> > The gimp splits big images into tiles that small enough so a few of
> > them fit into the RAM and then tries to work on these tiles one at a
> > time.
> > 
> > On 11.02.21 18:33, Monkey wrote:
> >> It's been several years but I'm working on a new version of
> >> Multiblend that's a bit faster, produces much nicer results, and
> >> will blend much bigger mosaics.
> >>
> >> Does anyone have any feature requests for a blender that I could
> >> consider incorporating?
> >>
> >> Along the same lines, does anyone use Enblend's colour space
> >> features? Do they produce notably more "correct" results, or just
> >> different ones? I've added an approximately linear RGB mode to
> >> Multiblend, but it doesn't seem to produce great results so I'll
> >> only be leaving it there as a curiosity.
>
>
> -- 
> David W. Jones
> gnome...@gmail.com
> wandering the landscape of god
> http://dancingtreefrog.com
> My password is the last 8 digits of π.
>

-- 
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/b152fafb-bf6f-4c1a-aa96-86c72e17bf90n%40googlegroups.com.

Re: [hugin-ptx] Feature requests for Multiblend 2.0?

[Monkey]

Output images that are bigger than RAM will be supported (on x64, at least; 
making the same available on x86 would be a *lot *more work). Input images 
that are bigger than RAM are not currently supported, but I'll see about 
adding that (if anyone's going to try blending gigapixel images together). 
It's done with plain memory mapped files rather than tiles.
On Thursday, 11 February 2021 at 18:39:34 UTC gunter.ko...@gmail.com wrote:

> gimp-like memory management that allows to handle target images that are 
> bigger than the RAM. don't know if it is already implemented.  
>
> The gimp splits big images into tiles that small enough so a few of them 
> fit into the RAM and then tries to work on these tiles one at a time.  
> On 11.02.21 18:33, Monkey wrote:
>
> It's been several years but I'm working on a new version of Multiblend 
> that's a bit faster, produces much nicer results, and will blend much 
> bigger mosaics.
>
> Does anyone have any feature requests for a blender that I could consider 
> incorporating?
>
> Along the same lines, does anyone use Enblend's colour space features? Do 
> they produce notably more "correct" results, or just different ones? I've 
> added an approximately linear RGB mode to Multiblend, but it doesn't seem 
> to produce great results so I'll only be leaving it there as a curiosity.
>
> -- 
> 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/c0e1493b-014c-43b1-b897-39c1d7ac9d41n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/hugin-ptx/c0e1493b-014c-43b1-b897-39c1d7ac9d41n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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/c5d81922-fa04-4784-8953-3f32cf1b1fdan%40googlegroups.com.

[hugin-ptx] Feature requests for Multiblend 2.0?

[Monkey]

It's been several years but I'm working on a new version of Multiblend 
that's a bit faster, produces much nicer results, and will blend much 
bigger mosaics.

Does anyone have any feature requests for a blender that I could consider 
incorporating?

Along the same lines, does anyone use Enblend's colour space features? Do 
they produce notably more "correct" results, or just different ones? I've 
added an approximately linear RGB mode to Multiblend, but it doesn't seem 
to produce great results so I'll only be leaving it there as a curiosity.

-- 
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/c0e1493b-014c-43b1-b897-39c1d7ac9d41n%40googlegroups.com.

Re: [hugin-ptx] Trying to use Hugin, and...

[Monkey]

Thanks for trying. That is about as good as I would have expected from the 
input images. I had another go myself, starting from scratch and placing 
the images manually before running optimise.

Once I'd run optimise, however, the images weren't displaying properly in 
the preview again. Does anyone know why this happens? Is it an OpenGL 
problem?

Some images turn into jagged strips, some don't appear at all (they do 
appear in the little "sphere" preview to the left).


On Monday, 8 February 2021 at 06:48:03 UTC m.l...@up.ac.za wrote:

> Hallo Monkey,
>
> Sunday, February 7, 2021, 10:18:40 PM, you wrote:
>
> > The project is supposed to be a 360x180, with 7 images taken
> > horizontally, one up, and one down. I haven't bothered trying to
> > connect the sky image, but I've given the others a handful of
> > control points (I'm not bothered about getting a great alignment;
> > just a rough one is fine). Hugin seems to be insisting on putting
>
> I don't have experience in stitching very wide angle images. The few
> that I have tried has not worked at all. This is what I was able to
> produce, but left out the sky and feet image. I also rotated the
> images before stitching. This makes the placement of control points
> and alignments much easier.
>
> The overlap between the images are just not enough to get anything
> better, although some of the others on the group could correct me.
>
> Groetnis
> Marius 
> mailto:marius...@up.ac.za
> BMedSci (Hons) UP, PGCHE (UP) HCM (FPD)
>
> add some chaos to your life and put the world in order
> http://www.chaos.co.za/
>
> Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule 
> onderhewig. Volledige besonderhede is by 
> www.it.up.ac.za/documentation/governance/disclaimer/ 
> beskikbaar.
> -- 
> This message and attachments are subject to a disclaimer.
>
> Please refer to 
> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
> <http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
> full 
> details.
>

-- 
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/70481e69-c098-485d-acff-034dd24ee8b6n%40googlegroups.com.

Re: [hugin-ptx] Does anyone have any image sets, particularly ones that don't blend well, that they could share for testing purposes?

[Monkey]

Hi Laurent,

Those sound ideal, especially if they exhibit change in lighting or 
exposure. Loss of contrast is one of my remaining problems with Multiblend 
so even well-matched images will be useful for that, and if the panos are 
big that will help test caching.

On Tuesday, 26 January 2021 at 04:47:43 UTC Laurent E wrote:

> Hi Monkey,
> I'm finishing a virtual tour that includes 8 street-art flat panoramas. 
> Some are 30 meters wide.
> Is it the kind of pano you're looking for?
>
> On Tuesday, January 26, 2021 at 5:13:22 AM UTC+7 Monkey wrote:
>
>> Perfect, thanks!
>>
>> On Monday, 25 January 2021 at 20:35:45 UTC Donald Johnston wrote:
>>
>>> Hi Monkey … these are links to some file sets I have on Sync.com.  Let 
>>> me know if they are useful.
>>>
>>> https://ln2.sync.com/dl/f27685a80/392a24qm-7uudw2mp-4vzsr5eg-qaj852qx
>>> https://ln2.sync.com/dl/310817b80/vxegvztw-7ixx2fqu-8q5h6kr8-8g7789m8
>>> https://ln2.sync.com/dl/380fc1290/x63ceeax-pnft3mpd-fhub63bd-gcasikxn
>>> https://ln2.sync.com/dl/b7d757380/68iyddwc-puc3yr7d-exqjavjv-mpmg4rnh
>>>
>>> Don Johnston
>>>
>>>
>>> On Jan 25, 2021, at 12:08 PM, Monkey  wrote:
>>>
>>> I'm making a new version of Multiblend but I don't have a lot of 
>>> panoramas/mosaics to test it with. Does anyone have any image sets they 
>>> could share, perhaps via Google Drive, particularly ones which have proven 
>>> problematic to blend together?
>>>
>>> 360s x 180s, gigapixels, planar mosaics and such would also all be good, 
>>> but I'm mainly looking for the kind of "Automatic" mosaics that show wide 
>>> variations in white balance, exposure, and focus, or ones where there is 
>>> minimal overlap between images.
>>>
>>> I just need JPEG sets, plus a PTO file if you happen to have one.
>>>
>>> I won't share results with anyone except the uploader, unless explicitly 
>>> given permission to do so.
>>>
>>> Thanks in advance!
>>>
>>> -- 
>>> 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/28763516-6521-4f7a-890e-5f3392eb846an%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/hugin-ptx/28763516-6521-4f7a-890e-5f3392eb846an%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>>>

-- 
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/42e33478-66ee-40f4-b3fb-8cbaf5133be9n%40googlegroups.com.

Re: [hugin-ptx] Does anyone have any image sets, particularly ones that don't blend well, that they could share for testing purposes?

[Monkey]

Perfect, thanks!

On Monday, 25 January 2021 at 20:35:45 UTC Donald Johnston wrote:

> Hi Monkey … these are links to some file sets I have on Sync.com.  Let me 
> know if they are useful.
>
> https://ln2.sync.com/dl/f27685a80/392a24qm-7uudw2mp-4vzsr5eg-qaj852qx
> https://ln2.sync.com/dl/310817b80/vxegvztw-7ixx2fqu-8q5h6kr8-8g7789m8
> https://ln2.sync.com/dl/380fc1290/x63ceeax-pnft3mpd-fhub63bd-gcasikxn
> https://ln2.sync.com/dl/b7d757380/68iyddwc-puc3yr7d-exqjavjv-mpmg4rnh
>
> Don Johnston
>
>
> On Jan 25, 2021, at 12:08 PM, Monkey  wrote:
>
> I'm making a new version of Multiblend but I don't have a lot of 
> panoramas/mosaics to test it with. Does anyone have any image sets they 
> could share, perhaps via Google Drive, particularly ones which have proven 
> problematic to blend together?
>
> 360s x 180s, gigapixels, planar mosaics and such would also all be good, 
> but I'm mainly looking for the kind of "Automatic" mosaics that show wide 
> variations in white balance, exposure, and focus, or ones where there is 
> minimal overlap between images.
>
> I just need JPEG sets, plus a PTO file if you happen to have one.
>
> I won't share results with anyone except the uploader, unless explicitly 
> given permission to do so.
>
> Thanks in advance!
>
> -- 
> 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/28763516-6521-4f7a-890e-5f3392eb846an%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/hugin-ptx/28763516-6521-4f7a-890e-5f3392eb846an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>

-- 
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/17e85455-62fe-403c-bb8a-4ff7e6f096a1n%40googlegroups.com.

[hugin-ptx] Does anyone have any image sets, particularly ones that don't blend well, that they could share for testing purposes?

[Monkey]

I'm making a new version of Multiblend but I don't have a lot of 
panoramas/mosaics to test it with. Does anyone have any image sets they 
could share, perhaps via Google Drive, particularly ones which have proven 
problematic to blend together?

360s x 180s, gigapixels, planar mosaics and such would also all be good, 
but I'm mainly looking for the kind of "Automatic" mosaics that show wide 
variations in white balance, exposure, and focus, or ones where there is 
minimal overlap between images.

I just need JPEG sets, plus a PTO file if you happen to have one.

I won't share results with anyone except the uploader, unless explicitly 
given permission to do so.

Thanks in advance!

-- 
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/28763516-6521-4f7a-890e-5f3392eb846an%40googlegroups.com.

[hugin-ptx] Re: Any reason to use Enblend over Verdandi?

[Monkey]

Thanks for the info. I wondered if a combination mode could be made, which 
corrects the colours using the Poisson equation (something for me to learn 
about - got any links? Is it a frequency domain thing?), but still uses a 
hard seam to connect the images without trying to blend any features (which 
blend mode appears to do, as I get smears very similar to 
Enblend/Multiblend when I use deliberately misaligned images).

I've been updating Muliblend and while it is faster than both Verdandi and 
Enblend, I haven't yet come up with a reliable way to avoid overblending 
(Enblend uses different numbers of levels for every image, as the overlap 
allows, but as well raising the possibility of inconsistent blending this 
also seems to result in later images being blended more than earlier ones).
On Friday, 22 January 2021 at 15:44:05 UTC T. Modes wrote:

> Hi Monkey,
>
> verdandi has 2 blending modes:
>
> - hard seam: this is the fastest one and relies to 100 % on Hugin 
> photometric optimization. For me this works fine in about 3/4 of the cases. 
> If there are bigger color/exposure differences at the image edges between 
> the images then I use blend seam (or enblend)
> - blend seam: it uses the same seam finder as in the hard seam case. The 
> remaining differences between the images are blended with a Poisson 
> equation solver - something completely different from enblends pyramids 
> approach. This algorithm can also blend away some higher color shifts 
> between images. But it still benefits from Hugin photometric optimization - 
> especially when the photometric optimizer has corrected the vignetting 
> (color and exposure is not so important in this case).
>
> But I got some reports where verdandi blend produced bad results. This 
> happens mostly when using bigger images. This issues are not there when 
> reducing the output size. So it is very difficult to debug in the case. 
> Fixes for this are always welcome ;-)
>
> Because of this issue and for backward compatibility I have hesitated to 
> change the default. But each user can change the default blender in the 
> preferences.
>
> PS: 
> > Hugin may have done in balance the exposure of control points 
>
> The control points are only used for geometric optimization. They have no 
> effect for the photometric optimizer. Here only the current arrangement of 
> the images is used for probing the photometric differences between the 
> 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/107d740f-084f-4a24-ba26-b808c73f48d4n%40googlegroups.com.

Re: [hugin-ptx] Any reason to use Enblend over Verdandi?

[Monkey]

Did you try both seam modes? They do quite different things, and the 
default is not the Enblend-like one.

On Tuesday, 19 January 2021 at 22:00:11 UTC GnomeNomad wrote:

> On January 19, 2021 10:54:28 AM HST, Monkey  wrote:
>>
>> I haven't used Hugin for a while, but I recently started updatng my old 
>> Multiblend project as I had recently rewritten the pyramid processing part 
>> of it for another project.
>>
>> I hadn't used the built-in Hugin blender (Verdandi), so I gave it a try 
>> and was pleasantly surprised with the results. Wtih seam=blend, it does a 
>> great job of matching the exposure of images (even if it does so relative 
>> to the first image in the list, seemingly undoing much of the work Hugin 
>> may have done in balance the exposure of control points), the end result 
>> looks very good, and seems to do just as good a job at optimising seams as 
>> Enblend does.
>>
>> With that in mind, and given that Verdandi must be at least dozens of 
>> times faster then Enblend (and likely gets exponentially faster as mosaic 
>> size increases), what are the reasons, if any, for using Enblend (and still 
>> having it be the default blender in Hugin) over Verdandi?
>>
>>
> Only time I tried Verdandi, it didn't do as nearly a good job as enblend.
>
> -- 
> David W. Jones
> gnome...@gmail.com
> wandering the landscape of god
> http://dancingtreefrog.com
>
> Sent from my Android device with F/LOSS K-9 Mail.
>

-- 
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/629b5243-7d12-4e87-9b6e-8c13b6fcb8b9n%40googlegroups.com.

[hugin-ptx] Any reason to use Enblend over Verdandi?

[Monkey]

I haven't used Hugin for a while, but I recently started updatng my old 
Multiblend project as I had recently rewritten the pyramid processing part 
of it for another project.

I hadn't used the built-in Hugin blender (Verdandi), so I gave it a try and 
was pleasantly surprised with the results. Wtih seam=blend, it does a great 
job of matching the exposure of images (even if it does so relative to the 
first image in the list, seemingly undoing much of the work Hugin may have 
done in balance the exposure of control points), the end result looks very 
good, and seems to do just as good a job at optimising seams as Enblend 
does.

With that in mind, and given that Verdandi must be at least dozens of times 
faster then Enblend (and likely gets exponentially faster as mosaic size 
increases), what are the reasons, if any, for using Enblend (and still 
having it be the default blender in Hugin) over Verdandi?

-- 
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/c50e1d23-f9ed-4187-9e19-c4de650abf7en%40googlegroups.com.

[hugin-ptx] Rounding bug in Nona and/or image reading

[Monkey]

The attached project consists or two images - small, ostensibly 
single-colour JPEGs.

When opened in Photoshop, green.jpg has pixels all of value (0,255,1). 
yellow.jpg has pixels all of value (255,255,0).

After stiching to separate tifs, one tif is over 10x larger than the other. 
On opening in Photoshop this can be seen to be the result of the pixels 
being a mixture of (0,255,1) and (0,255,2), and as such, not being very 
compressible with LZW - unlike the other tif, which is still pure 
(255,255,0).

This suggests a bug in Nona's resampling code which is causing some values 
to round up - either that or a bug (or maybe just a difference from 
Photoshop) in the code that decompresses the JPEG? Maybe the second is more 
likely, because changing Nona's interpolator makes no difference.

Anyway, it's probably more of academic interest really, since such images 
are not common in real usage, but I thought it would be of interest.

David

-- 
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/abf79eb5-6dae-43c3-84b1-0b2472262cfen%40googlegroups.com.
<>

[hugin-ptx] Re: Hole in panorama

[Monkey]

I think it's either a stitching problem or you've inadvertently masked out 
that section of the image. Switch from enlblend to built-in or vice versa, 
or check the Masks tab.

-- 
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/1418bcb9-ce05-43b1-8ee0-12a00a586075%40googlegroups.com.

[hugin-ptx] Re: multiblend error

[Monkey]

This one's not so obvious. Try changing line 531:

int lp;

to

size_t lp;

If that doesn't work, which I suspect it won't, you may just have to add 
printfs to figure out exactly where it's breaking.

On Saturday, 25 January 2020 12:25:30 UTC, Hans Bull wrote:
>
> Your guess was right!! Now it goes further, but exists in collapse(), see 
> below. 
>
>

-- 
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/3756-5453-4379-bf37-df8a4063f1d2%40googlegroups.com.

[hugin-ptx] Re: multiblend error

[Monkey]

The likely suspect is the memset on line 449. 
"(output->pitch*output->h)pitch*output->h)pitch*(size_t)output->h)<
> After multiblend repeatedly aborted while trying to blend a 28611x51445, I 
> recompiled it with -fsanitize=address and got the following. Any ideas 
> where the problem might be?
>
>
> opening images (caching enabled)... 
> processing 10.tif... 
> processing 11.tif... 
> 28611x51445, 8bpp, 13 levels 
> seaming... 
> masks... 
> blending... 
> = 
> ==4832==ERROR: AddressSanitizer: negative-size-param: (size=-1350667056) 
>#0 0x7fba7c09eecd  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x66ecd) 
>
>#1 0x55fe2de3ca07 in mask_into_output(struct_level*, float*, 
> struct_level*, bool) (/usr/local/bin/
> multiblend+0x19a07) 
>#2 0x55fe2de3ee41 in blend() (/usr/local/bin/multiblend+0x1be41) 
>#3 0x55fe2de42604 in go(char**, int) 
> (/usr/local/bin/multiblend+0x1f604) 
>#4 0x55fe2de2a0ff in main (/usr/local/bin/multiblend+0x70ff) 
>#5 0x7fba7b7bfb96 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) 
>#6 0x55fe2de2a739 in _start (/usr/local/bin/multiblend+0x7739) 
>
> 0x7fb71c8b4800 is located 0 bytes inside of 3926283968-byte region 
> [0x7fb71c8b4800,0x7fb806919ec0) 
> allocated by thread T0 here: 
>   
>#0 0x7fba7c144745 in memalign 
> (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c745) 
>#1 0x55fe2de3eb17 in blend() (/usr/local/bin/multiblend+0x1bb17) 
>#2 0x55fe2de42604 in go(char**, int) 
> (/usr/local/bin/multiblend+0x1f604) 
>#3 0x55fe2de2a0ff in main (/usr/local/bin/multiblend+0x70ff) 
>#4 0x7fba7b7bfb96 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) 
>
> SUMMARY: AddressSanitizer: negative-size-param 
> (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x66ecd)  
> ==4832==ABORTING
>
>

-- 
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/b96a0f39-a160-4a8b-be22-5b9154bafa06%40googlegroups.com.

Re: [hugin-ptx] Re: enblend / black corners and fringes

[Monkey]

On Sunday, 29 September 2019 22:58:09 UTC+1, lukas wrote:
>
>
> you mean lower frequency, right? 
>

No, higher (I said highEST but I meant highER). Lower frequencies would be 
expected to be used, because they will have spread from valid areas. You 
don't want to see the higher frequency components though (which will 
include the hard edge in Enblend's case, although I'm not 100% sure on how 
it works).
 

> Do you know how many pixels are maximally included to both sides (by 
> means of diffuser layers) in enblend and multiblend?  I have never 
> noticed an artefact where there is a grey fringe without black which 
> should result from the seam being close to the edge but not beyond the 
> edge. 
>

That depends on the number of levels, which varies. In Enblend's case I 
think it's related to the size of overlap as each image is added (so some 
images may get blended more or less than others). In Multiblend, it depends 
on the size of the images (either input images or output image, depending 
if --wideblend is specified).

For the same number of levels, Multiblend blends about half as much as 
Enblend does, but it probably picks a higher number of levels. I think the 
total "spread" of a pixel's influence varies with the number of level cubed.

NFT is of course very close to the edge at the two entry points and if 
> either the coarse mask or the optimisation mess up, it might end up on 
> the wrong side ... 
>
> Is there an easy description of how they are constructed?  Do you 
> explicitly penalise close proximity to the edges? 
>

To clarify, Multiblend's seams are still precise in a general sense, they 
just operate with a different metric. Enblend calculates the true Euclidean 
distances, which I think is one reason it is slow (it's optimised, but the 
algorithm is still complicated), whereas Multiblend uses a propagating 
algorithm, increasing distance by (if I remember rightly) 3 for every 
horizontal/vertical pixel and 4 for every diagonal pixel (only addition and 
comparison required). That results in a distance function which is more of 
a fat octagon than a circle, but for calculating seam lines it makes no 
practical difference to how "good" they are, unless you've somehow managed 
to take geometrically perfect photos, which never happens.

So there's no explicit penalty for being close the edges, but I'd say at 
worst Multiblend might stray about 5% closer (in a Euclidean sense) to the 
edges than Enblend.

-- 
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/3d86da2b-4556-44f7-9b60-bbb3b8495b93%40googlegroups.com.

[hugin-ptx] Re: enblend / black corners and fringes

[Monkey]

I think all three should be fixed. #3 was one motivation for writing 
Multiblend, because it can cause problems even when seams don't stray 
(particularly when image edges make a corner). Multiblend assumes any 
out-of-bounds pixel (per image) is the same colour as its nearest in-bounds 
neighbour.

Of course even if you do that, if seam lines stray too close to the overlap 
then you will end up using the higher frequency components of those "fake" 
pixels to fill in that black hole, which is also not ideal, and if the seam 
lines stray *outside* the overlap region then you get those "fake" pixels 
directly visible (black in Enblend's case because it doesn't extend images 
in that way).

NFT seams should never go near the edges, so if it happens without 
optimisation I assume it's down to using a coarse mask. My knowledge may be 
a bit out of date, but my understanding of Enblend's seam generation is 
that the NFT is very precise (geometrically speaking) but very slow (hence 
the option for coarse masks), and the precision is unwarranted given that 
there are much faster methods and geometric precision isn't necessary. 
Multiblend's seams are different, but for practical purposes they are just 
as valid as Enblend's.

I've been doing a lot of work on image pyramids lately so a new version of 
MultiBlend may be a future project. I just did a test with a 70mp 11 image 
mosaic and MultiBlend is still 25x faster than the latest Enblend (with 
like-for-like settings) :D I know a lot more about multithreading and SSE 
now, so I'm hoping for at least double the speed.

On Wednesday, 25 September 2019 22:14:41 UTC+1, lukas wrote:
>
> Hi, 
>
> I have a been looking at the enblend problem that is described here 
> (https://bugs.launchpad.net/enblend/+bug/721136) a bit more. 
>
> In all examples that I know of, the problem is that the seamline(s) 
> run(s) slightly outside of the overlap area.  As a result, pixels are 
> included from one image which lie outside the image's area, or in a 
> transparent area (which apparently is not invalid but black).  This 
> problem can occur for NFT and GC, becomes less frequent with fine and/or 
> optimise but can occur with any combination. 
>
> An obvious example is the result (1) with seamlines (2) which is 
> generated from the example files I have added to the above thread.  This 
> particular example uses coarse/no-opt/gc. 
>
>
> If I understand the relevant algorithms correctly, this problem could 
> be/should be caught in three different places: 
> 1) Neither GC nor NFT should return a seamline outside the overlap 
> 2) the seamline optimisation should return only seams inside the 
> overlapping region 
> 3) the blending should not assume out-of-bound or transparent pixels to 
> be black but either transparent or take a pixel from the other picture. 
>
>
> Which brings me to my question:  Do you have any opinion on where this 
> problem should be fixed?  I would assume fixing 3) is the easiest and 
> safest.  On the other hand, seamlines outside the overlap area, produced 
> by 1) or 2) entirely refute the point of finding a good seamline to 
> begin with (leading to poor quality).  So maybe one should treat this 
> problem in all three places (four actually, because GC, NFT, opt, 
> blending)? 
>
> cheers, lukas 
>
>
> (1) http://78.46.190.157:8080/foo.tif 
> (2) http://78.46.190.157:8080/vis-1.tif 
>
>

-- 
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/e611fb9f-7179-4aaf-9d87-bb3e6204edee%40googlegroups.com.

[hugin-ptx] auto fine-tune not working (Windows)

[Monkey]

I've got auto fine-tune enabled but it doesn't always seem to work. Here 
are some screenshots of me creating two control points:

https://imgur.com/a/iw4THSf

The first is immediately after creating a control point (deliberately being 
a little inaccurate). Both panels are the same image so a perfect match 
should be easy to find, but as you can it's not aligned until I click 
"Fine-tune" myself

Only after manually clicking "Fine-tune" (second screenshot) do the control 
points align perfectly.

The second control point had the same problem (images 3 and 4). The third 
control point fine-tuned itself successfully.

I've reinstalled and reset all preferences to default. Am I missing 
something?

-- 
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/847c0fa6-5f09-4555-a81c-b5bcdff558e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Compilation error on multiblend

[Monkey]

It (probably) won't build without -ljpeg. Try changing the "true" on those 
two lines to "boolean(true)"

For the warnings, you can change p>=0 to p>0 (strictly speaking it is a 
bug, but not one you are likely to trigger unless you have pathological 
input 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/0f14b88e-132d-4a65-af4c-4c238018819c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: Enblend oddity

[Monkey]

There is/was a command line switch to enable DEFLATE, but for some reason 
it's commented out in the source code and I didn't leave myself a note to 
tell me why.

As for enblend, it's hard to say whether it's a bug, but it might be. 
Enblend produces different outputs if you supply images in a different 
order - one reason I wrote multiblend - but I think that's more like a 
slightly unsatisfactory compromise than a bug.

On Sunday, 27 August 2017 00:59:27 UTC+1, B. Schnieders wrote:
>
> Hrrmmm, I'm in a committed long-term relationship with enblend, but seeing 
> that it can't fulfil my needs right now, I had a quick flirt with 
> multiblend works! Most of the images have good overlap and no 
> parallax/moving objects anyway, so hardly any blending was necessary. 
>
> Interesting. Was just about to write that re-ordering didn't work, but 
> wasn't sure if I tried all combinations. Yes, in a certain order, it blends 
> without problems. Maybe that's worth filing a bug report for...? 
>
> (Also, I should add a feature request for multiblend: support deflate 
> compression ...) 
>
> Thanks! You saved my pano. :) 
>
> Best, 
> Benjamin 
>
> Monkey wrote: 
> > Are you wedded to enblend? multiblend would have no such issues, and 
> actually does blend, not just assemble, disconnected images. 
> > 
> > Alternatively, have you tried reordering the images? Rename 
> testing0002.tif to testing.tif and vice versa. 
>

-- 
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/42a0bf5e-a868-4e22-86f3-4da731327113%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Enblend oddity

[Monkey]

Are you wedded to enblend? multiblend would have no such issues, and 
actually does blend, not just assemble, disconnected images.

Alternatively, have you tried reordering the images? Rename testing0002.tif 
to testing.tif and vice versa.

-- 
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/ee0c6943-bb72-41f6-9689-66c21f35418a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] enfuse/enblend discussions?

[Monkey]

I don't think I asked any questions before releasing multiblend, 
more-or-less fully formed (in fact I had previously developed some more 
complex GUI software for image blending, but never released it). The ideas 
behind enblend/enfuse aren't protected; the enblend documentation itself 
goes beyond simple usage and is most helpful in explaining how it works. 
Nor was enblend the first to implement these ideas.

HDR and focus stacking are fairly obvious extensions of the basic enblend 
idea (they don't gel well with the mask compression used in multiblend, 
otherwise I would have added them more-or-less "for free").

-- 
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/7c06c821-4b0f-4a03-9889-d90d114c0c40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Why is part of the stitched image black?

[Monkey]

Rather splitting the panorama in two, have you tried reordering the images? 
Enblend produces different results depending on the input order.



On Tuesday, 17 January 2017 16:19:43 UTC, Hans Bull wrote:
>
> The new default graph-cut algorithm in most cases seems to produce better 
> seams, but sometimes has the black areas as a show stopper. In some cases 
> it helped me splitting the panorama in two partial ones and doing a final 
> enblend on the two intermediate files. But things should no be like this.
>
> HB
>
>

-- 
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/50175d3e-d0f3-480e-bff0-287b1efcb9fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Can Hugin change the projection of a video?

[Monkey]

Avisynth will run under WINE (and an AviSynth script can fed as input to 
ffmpeg), but there is also VapourSynth which was inspired by AviSynth and 
is cross-platform (but using a more complicated syntax). I don't really 
know anything about VapourSynth though.

I did see that you said Equirectangular Panini, but I forgot to type the 
second word.

On Tuesday, 12 July 2016 01:57:53 UTC+1, Robert Giordano wrote:
>
> Hi Monkey,
>
> Avisynth looks very interesting. I'm on a Mac but I have access to Windows 
> machines. I do my editing in Adobe Premiere/After Effects CS6. The only 
> reason I'm using Hugin is because it does *exactly* what I need, but only 
> to single frames, one at a time. It would be nice to convert an 8 minute 
> video shot at 60fps without having to convert it to 28,800 JPEGS and then 
> convert it back to video. 
>
> I really appreciate all the help given here so far and I'm currently 
> experimenting with FFMPEG as suggested above by Cartola
>
> Also, I'd like to point out that I want a PANINI equirectangular 
> projection (or an adjustable Panini), not a plain Equirectangular 
> projection. It just so happens that in the Hugin drop-down menu of 
> projections, there is "Equirectangular Panini" and it does exactly what I 
> want, given the lens horizontal field of view (HFOV) that I input.
>
> Here is a link with TONS of stuff about the panini projection: 
> http://tksharpless.net/vedutismo/Pannini/
>
> At one point he seems to have built a video converter but it hasn't been 
> supported for years and I couldn't get it to work on two different Windows 
> machines. 
>
> I'm REALLY surprised I couldn't find a plugin for Premiere that does this. 
>
> thanks,
>
> Robert
>
>
> On Monday, July 11, 2016 at 6:55:10 PM UTC-4, Monkey wrote:
>>
>> I have to say I* really *think Hugin is the wrong tool for this job!
>>
>> If someone can help me out with the maths behind converting Fisheye to 
>> Equirectangular, there is an Avisynth pluging called xyremap (written by 
>> me!) which will do this in near realtime.
>>
>> (I seem to remember there is an .exe in the distribution which will give 
>> individual transform coordinates on request, from a PTO - but I don't 
>> recall finding out a way to give a full map of coordinates in one call. If 
>> that could be done I could modify my plugin to read the map and apply it to 
>> the video)
>>
>> -Monkey
>>
>> On Sunday, 10 July 2016 10:39:32 UTC+1, Robert Giordano wrote:
>>>
>>> I want to change the projection of all frames in a video from Fisheye to 
>>> Equirectangular Panini. I'm not trying to stitch any images. I'm not doing 
>>> a 360 video. I'm just trying to do a lens correction. I've exported a 
>>> single frame from my video and Hugin changes the image perfectly. Is it 
>>> possible to use Hugin to change all of the frames in the video?
>>>
>>> thanks,
>>>
>>> Robert
>>>
>>>
>>>
>>>
>>>

-- 
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/399d95c5-c7cd-44ba-9cc0-4afbf4019300%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Can Hugin change the projection of a video?

[Monkey]

I have to say I* really *think Hugin is the wrong tool for this job!

If someone can help me out with the maths behind converting Fisheye to 
Equirectangular, there is an Avisynth pluging called xyremap (written by 
me!) which will do this in near realtime.

(I seem to remember there is an .exe in the distribution which will give 
individual transform coordinates on request, from a PTO - but I don't 
recall finding out a way to give a full map of coordinates in one call. If 
that could be done I could modify my plugin to read the map and apply it to 
the video)

-Monkey

On Sunday, 10 July 2016 10:39:32 UTC+1, Robert Giordano wrote:
>
> I want to change the projection of all frames in a video from Fisheye to 
> Equirectangular Panini. I'm not trying to stitch any images. I'm not doing 
> a 360 video. I'm just trying to do a lens correction. I've exported a 
> single frame from my video and Hugin changes the image perfectly. Is it 
> possible to use Hugin to change all of the frames in the video?
>
> thanks,
>
> Robert
>
>
>
>
>

-- 
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/50510418-ba00-466f-a661-2f9f8a8c35f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Multiblend with CMake build support??

[Monkey]

I have no idea about CMake, but it does compile with Visual Studio - well, 
as long as you have a static compile of libtiff, turbopeg, libpng and zlib 
to link against...

Open multiblend.cpp as the only source file and the rest are #included from 
there.

On Friday, 26 February 2016 11:58:29 UTC, Finfa811 wrote:
>
> Hi all,
>
>
> Is there any Multiblend version with CMake build support? I would like to 
> use it in Visual Studio.
>
>
> Thanks in advance.
>

-- 
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/16d0bfe4-0641-4efb-b6bb-055745702e6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Enblend performance on mosaics?

[Monkey]

The problem with your "quadrant" plan may be down to the order you supply 
the images on the command line. It may be that each image must be connected 
to the previous images. So if you had 9 images:

ABC
DEF
GHI

And you supplied them in the order A,B,C,H... enblend might be able to 
blend A,B,C but when it comes to H there is no overlap (yet). If you 
supplied them instead in alphabetical order, the blend might be successful.

The full set may be okay because presumably you are supplying them in the 
order you shot them, in some kind of continuous/snaking grid pattern.

NB Enblend's output differs depending on the order images are supplied on 
the command line.


On Tuesday, 8 December 2015 10:41:59 UTC, bugbear wrote:
>
> I've written a perl script to "chop up" the blend; 
> unfortunately, doing a quick low res test run, one of the quadrants 
> reported: 
>
> enblend: info: loading next image: mapped/big0103.tif 1/1 
> enblend: info: loading next image: mapped/big0102.tif 1/1 
> enblend: warning: failed to detect any seam 
> enblend: mask is entirely black, but white image was not identified as 
> redundant 
> enblend: info: remove invalid output image "1x0sub.tif" 
>
> So I didn't get my quadrant output. 
>
> And yet the "full set" of images blends OK. 
>
>

-- 
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/f0388ea3-983a-49aa-a608-d13fc5ebe48e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Enblend performance on mosaics?

[Monkey]

The problem with your "quadrant" plan may be down to the order you supply 
the images on the command line. It may be that each image must be connected 
to the previous images. So if you had 9 images:

ABC
DEF
GHI

And you supplied them in the order A,B,C,H... enblend might be able to 
blend A,B,C but when it comes to H there is no overlap (yet). If you 
supplied them instead in alphabetical order, the blend might be successful.

The full set may be okay because presumably you are supplying them in the 
order you shot them, in some kind of continuous/snaking grid pattern.

NB Enblend's output differs depending on the order images are supplied on 
the command line.


On Tuesday, 8 December 2015 10:41:59 UTC, bugbear wrote:
>
> I've written a perl script to "chop up" the blend; 
> unfortunately, doing a quick low res test run, one of the quadrants 
> reported: 
>
> enblend: info: loading next image: mapped/big0103.tif 1/1 
> enblend: info: loading next image: mapped/big0102.tif 1/1 
> enblend: warning: failed to detect any seam 
> enblend: mask is entirely black, but white image was not identified as 
> redundant 
> enblend: info: remove invalid output image "1x0sub.tif" 
>
> So I didn't get my quadrant output. 
>
> And yet the "full set" of images blends OK. 
>
>

-- 
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/12fdc632-742a-4290-a90c-bcf30d36a894%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Enblend performance on mosaics?

[Monkey]

You might save time by pre-merging alternate images in each row - not 
blending them, but just joining them into a single image. Then you end up 
with two images:

1-3-5-
-2-4-7

which can blended in one enblend step. This should be a lot quicker.

One of enblend's big problems, as far as I can tell, is that it adds each 
image to the blend one-by-one, adding it to an intermediate image which 
gets bigger all the time, so enblend gets slower and slower with each 
image. Removing all those intermediate steps by the method above should be 
a great saving.

There are quicker (albeit potentially lower quality) blenders ;) 
http://horman.net/multiblend/

You won't be able to blend an entire gigapixel panorama with multiblend and 
2gb, though - it's a memory hog. Whatever you *can* fit in RAM will blend a 
lot quicker though.

-- 
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/82055e92-db90-40e9-838e-b0feb8ee3230%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: Verdandi: the new blender

[Monkey]

A seam map export from Verdandi would be awesome. Then I could feed it into 
multiblend, since multiblend doesn't do seam optimisation.

-- 
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/6937b3e5-57de-4233-8876-42f7f968a39d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: Some curious blending results

[Monkey]

I think those sample images were not the best that could have been chosen 
to illustrate flat stitching, with their abstract design and lack of visual 
clues as to orientation. I had to double check to make sure they hadn't 
been rotated as it's not immediately obvious, nor is it easy to gauge how 
the two images overlap just by looking at them.

I wonder if masking out the blurred areas would help.
>

Undoubtedly. The down side is that you rob yourself of image data that 
could still make a useful contribution to blending (even in this case - the 
fine lines might be blurred but the lower frequency information could still 
be useful).

I'd love to see some sort of seam hinting - perhaps some way of passing on 
to the blender that you don't want seams to cross a certain area, or to 
force them to follow a certain path. Blending water waves, for example, can 
be hard to do seamlessly, and one useful technique is to draw a meandering 
seam line. I did once write a (very basic) GUI that let you manipulate 
blending seams, but only between two images, and these days I use 
multiblend's --save-seams and --load-seams. I think the same thing is 
possible with Enblend, but is much more convoluted.

-- 
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/ff293b3d-feda-439f-8db4-2746546ec283%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: Some curious blending results

[Monkey]

On Wednesday, 22 April 2015 22:53:11 UTC+1, Roger Broadie wrote:
>
> Monkey > commented on Wed, 22 Apr 2015 
> at 
> 04:53:56 -0700 (PDT): 
>
> "The blurred patch [in Terry Duell's screenshot of Tue, 21 Apr 2015 at 
> 17:37:32 +1000] is not down to the blending as such, but is already 
> present in scan-1.jpg." 
>
> I don't see that.  True, there is blurring by the right-hand edge of the 
> image, presumably due to a lifting of the original at the edge of the 
> scanning area, and similar blurring, no doubt for a corresponding 
> reason, by the left-hand edge of tscan-2.jpg. 
>
> *But in neither is there significant blurring in the region of the most 
> noticeable blurring in Terry's enblend example*, which is around the 
> central vein of the nearly 
> vertical leaf on the right of the stitched image, 
> *which is rotated with respect to the original scans in order to orient it 
> correctly.*
>

I don't see that anything's been rotated.

Here's Terry's blend with tscan-1.jpg next to it, with the matching blurred 
areas highlighted:

http://s9.postimg.org/mdpmz69an/screenshot_2.jpg

-- 
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/21b56183-6522-41ed-b1e9-92b211e96703%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Looking for tutorial on making a 3-D image of an object.

[Monkey]

You could look into Photosynth:

http://photosynth.net/

It doesn't actually build 3D models but it may be of interest.

-- 
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/33df2c83-8bd2-4b65-93d9-9f9f130ef65f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Some curious blending results

[Monkey]

I think it's just down to the blender's differing methods of determining 
seams. I don't know how verdandi works, but Enblend and multiblend use 
different methods.

Enblend's initial seaming method is more mathematically "precise," but it's 
a bit of a false precision because it won't practically lead to better 
stitches. Enblend then also refines seams by following the contours in 
image overlaps, which is probably what's making the biggest difference. The 
blurred patch is not down to the blending as such, but is already present 
in scan-1.jpg. multiblend's seam has not run so close to the edge of the 
image, but Enblend has probably refined itself in that direction.

The best like-for-like test between Enblend would be with --no-optimize and 
--fine-mask added to the Enblend command line. However, even with those 
switches, once you start blending more than two images you'll find 
Enblend's seams will differ more and more from multiblend's.

Finally, if you're after timing comparisons, you're going to need a *much* 
bigger panorama. Most of the 6 seconds taken by all the stitchers will be 
loading and saving of images. multiblend's speed advantage over Enblend 
rises exponentially with panorama size. 172x faster was the best I got, and 
that was with Enblend crashing part way through.

-- 
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/6e57b191-ed79-47dc-a4f6-c91c62c965f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Using Multiblend instead of Enblend

[Monkey]

v0.6.2 should solve your problem:

http://horman.net/multiblend/

-- 
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/270a444f-3046-418b-bfc3-be58aa45b0ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Best way to align a stack to base image only

[Monkey]

Is there an easy to generate control points for a set of images, such that 
all images are linked only to the first image? Aligning an image stack 
aligns images in sequence (0-1, 1-2, 2-3, etc) but I would prefer (and 
think it would be better) if all images were aligned to image 0 only (0-1, 
0-2, 0-3, etc). This would stop errors propagating and would ensure that 
the last image was just as well aligned to image 0 as any other.

-- 
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/dc50c221-73b5-4b53-ab3b-9b50e04f8696%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] nona produces small TIFF images

[Monkey]

Not quite on-topic, but out of curiosity, will this generated project try 
to connect all images to every other image? Can it be done so that images 
only align to, for example, the first image?

Otherwise there's going to be a LOT of control point finding going on...

On Wednesday, 10 September 2014 01:45:10 UTC+1, Tduell wrote:
>
> Hello Einar, 
>
> On Wed, 10 Sep 2014 05:50:43 +1000, Einar Høst  > wrote: 
>
> > Hi, 
> > 
> > I am trying to align a long sequence of 1000+ images of a motive 
> changing 
> > slowly over time. My plan is to use pto_gen, cpfind, cpclean,   
> > autooptimizer and nona to produce the aligned sequence. However, the   
> > output I get are 
> > very small images! To be exact, the input files are 2848 × 4272 JPG   
> > files, and the output files are 317 × 434 TIFF files. Why? Obviously I'm 
>   
> > doing 
> > something wrong. Even if I reduce the tool chain to simply pto_gen   
> > followed by nona, my images shrink. I assume I'm using nona wrong, and   
> > not  pto_gen? 
> > 
> > The commands I run are 
> > pto_gen -o sequence.pto *.JPG 
> > nona -o output -m TIFF_m sequence.pto 
> > 
> > Hopefully the newbie mistake I'm doing is obvious to someone. 
> > 
>
> Try this... 
>
> pto_gen -o seq.pto *.JPG 
> pano_modify  --projection=0 --fov=AUTO --center --canvas=AUTO --crop=AUTO 
>   
> -o seq2.pto seq.pto 
> nona -o output -m TIFF_m seq2.pto 
>
> This produces TIFF almost same size as inputs, for my test images. 
>
> Cheers, 
> -- 
> Regards, 
> Terry Duell 
>

-- 
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/f7f4e5f3-b9e8-4417-9945-4be108c54851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: unblended triangle in fused version?

[Monkey]

The following applies to a 2012 Windows build, but...

Go to File->Preferences, Programs tab, tick "Use alternative Enblend 
program" and specify the path to a multiblend executable. If that doesn't 
work, you could just replace the enblend executable, though that's not a 
neat solution.

Multiblend's speed comes at a cost, of course - it uses more memory than 
Enblend and isn't quite so smart about the paths of seams (although the 
initial calculation of seams is better). Also for 360 degree panos, you 
will need to run Hugin's stitched and blended single output file through 
multiblend again to blend around the left/right edges.

-- 
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/3fe17bf8-8cf8-4fca-96b0-afd557c7b794%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: unblended triangle in fused version?

[Monkey]

I had a similar problem crop up while I was developing multiblend, though 
that had a slightly different cause. My guess at what may have happened is 
that, given three images in horizontal order, A B C, enblend has blended 
the small overlap between A and C before considering B. When it does come 
to add B to the composite, some parts of the blended A/C end up being 
included in the output image, when ideally that whole area should have been 
covered by B.

Another possibility is that neighbouring images overlap so much that, 
despite A being largely to the left of B, some parts of remapped A are off 
to the right of B, again giving them the chance to appear in the final 
composite when they should be covered up (this isn't likely in your single 
row pano).

Those sweeping spurs at the corners of remapped fish eye images could be 
the cause of just such problems.

Putting the images in shot order or overlapping a little less could stop 
the first case happening. Or you could use http://horman.net/multiblend";>multiblend ;)

Just a guess!

David

-- 
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/2b971b9e-a3d0-45b3-b84b-aea849e60678%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Strange haze on panorama photo stitched in HUGIN

[Monkey]

Is anybody else worried about what's in the bag? :S ;)

-- 
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/d69a5908-7e9d-4fdc-a6cd-df9702397bd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] A curious omission

[Monkey]

>
> The option for stitching with no exposure correction is to reset the 
> exposure parameters before stitching.
>

That seems unnecessarily opaque, but okay.

But then why should there be separate "Exposure correction/No exposure 
correction" options under Remapped Images? It seems inconsistent to me.

-- 
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/cd422e33-99c9-4879-a9ef-528ee2b7a5d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] A curious omission

[Monkey]

Sorry Bruno, you've only confused me further!

I wasn't considering fusing stacks or anything that advanced. What is the 
suggested procedure if I just want a blended, single-file output panorama 
with no exposure correction from a basic mosaic of images? It seems to me 
that none of the options really suggest this.

I usually end up going for "Remapped Images->No exposure correction, low 
dynamic range" and blending them myself with a separate command, just so I 
can be sure I understand what's happening to my 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/a04c2a35-d52d-4142-bb20-c5354b0bda43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] A curious omission

[Monkey]

Why does Hugin include "No exposure correction, low dynamic range" among 
the "Remapped images" options, but it doesn't have a related no-exposure 
entry under "Panorama Outputs"?

Might it not also be clearer to disable the "Exposure corrected" options 
when no Exposure optimisation has been done/no Exposure information is 
available? I find this confusing every time I look at it.

David

-- 
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/16cd43ed-f9e6-487e-be19-988b4d2fa5f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Scripted stitching of webcam pictures - advice appreciated

[Monkey]

1. Just a guess.

2. I don't what the bar means - perhaps it is to do with the supposed 
quality of the control points, since any manual ones are likely to be in 
areas that don't look very visually similar (since the auto control point 
function would have already put good control points in the areas that do 
look similar).

3. That's exactly what it should do, because you've already set the control 
points and optimised.

4. Not sure about that - it could be that you've optimised exposure. Try 
changing to Remapped Images: Exposure corrected, low dynamic range on 
Stitcher tab, Stitch, and then look at the individual remapped images that 
get created.



As for my dragging problem in the GL viewer, I think perhaps you are meant 
to optimise again after repositioning images. I still don't get why the 
image don't stay fully attached to each other, but I don't really know how 
it works (or is supposed to work).

On Friday, 6 June 2014 10:46:28 UTC+1, Jacob Hämmerle wrote:
>
> Hey Monkey,
>
> thanks for your advices! I've tried to reproduce and the result is pretty 
> ok.
>
> 1. Why did you choose 45 for HFOV? The Cameras are nearly set to full 
> wideangle which acc. to the specs is about 105° each! However with the 45 
> it seems to work much better - STRANGE!
>
> 2. Another thing. In the controlpoint editor it shows how good the 
> images/cp match. When adding manual ones the bar goes much more smaller and 
> red ... thats lil strange to me.
>
> 3. An most important. When using the same .pto and lets say the weather is 
> foggy. Will it stich the sam way just using the positions of the stored 
> control points independently from the image content? That would be awesome!
>
> 4. In the new result (attached) when you look at the left border of the 
> right image in the pano ... there is some ... lets call it grain. Where 
> does this come from? How to prevent that?
>
>
> Thank you for your time - appreciate it!
>
> Cheers, Jacob
>
>
> On Thursday, June 5, 2014 12:34:49 PM UTC+2, Monkey wrote:
>>
>> Actually, having said all that, I now find that when dragging the images 
>> around in the GL viewer, they don't stay fixed together as I was expecting 
>> them to, so maybe I'm entirely wrong to suggest doing it that way!
>>
>

-- 
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/dcf8fce0-c435-4d80-acc1-5c777996d82c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Scripted stitching of webcam pictures - advice appreciated

[Monkey]

Actually, having said all that, I now find that when dragging the images 
around in the GL viewer, they don't stay fixed together as I was expecting 
them to, so maybe I'm entirely wrong to suggest doing it that way!

-- 
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/78a69d8f-78bf-4f7d-a13d-b65a9406bc99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Scripted stitching of webcam pictures - advice appreciated

[Monkey]

"4. Last and least: How would you do it? What is your advice to me?"

I got a pretty good result by doing the following:

Load the images into Hugin, and set an approximate HFOV (I used 45 degrees) 
and a projection of equirectangular

Create some control points - I used "Create control points" on the Images 
tab, then added a couple more for good measure.

Then I optimised with custom parameters: I ticked y, p, r, X, Y, Z, v for 
image 1. Definitely don't tick b; Hugin went crazy when I did that!

Then I used the GL viewer, set the projection to equirectangular (you'll 
see more with this) or rectilinear (you'll get straighter lines, but either 
a lot of cropping or a lot of black), and dragged the images around until 
they were straight and more or less face on (if you click and drag on 
different points on the view, you get slightly different effects, so you 
can rotate as well as translate by click-dragging, it's quite nice)

Once that's done, you're ready to stitch. I didn't bother optimising 
exposure since the cameras seem pretty well matched, and blending will take 
care of some of that.


Now that's done, all the parameters should be saved in the .pto file. Now 
you can replace the input images with new images (same filenames), go 
straight to Stitch (or run it via the command line) and you'll have your 
new output.


Lastly, I'd recommend my http://horman.net/multiblend/";>multiblend as an alternative to 
enblend, as it does a nicer job with narrow overlaps, is much faster, and 
doesn't suffer from vignetting in corners.

-- 
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/ae9b8085-98c9-449b-ae97-502e2a52915f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Map Difficulties 2

[Monkey]

Quick and dirty multiblend attempt with a handmade mask:

http://i62.tinypic.com/24b29vb.jpg

-- 
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/e35a3a21-fa4e-4399-83a8-70ba0af6bd9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Map Difficulties 2

[Monkey]

On Monday, 28 April 2014 11:02:10 UTC+1, Bruno Postle wrote:
>
> On 28 April 2014 10:24, paul womack wrote: 
>
> > On this particular map, some of the tiles have borders, 
> > which I am attempting to remove using Hugin's 
> > crop/mask features. 
>
> Yes, masking in Hugin isn't very useful where there are tiny overlaps. 
> Enblend also probably isn't appropriate for this sort of thing, you 
> might do better with and image editor: masking with the eraser tool 
> and flattening layers. 
>

May I suggest giving multiblend  a try? It 
can blend (after a fashion) images without overlap.

David

-- 
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/985a84e4-d785-44cc-b8c1-ed94e6e698a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Multiblend option like --no-ciecam?

[Monkey]

Oh, *that* kind of glaring! (emailed images show red and blue channels 
swapped in output) You just need the --bgr switch :)

David

On Thursday, 20 March 2014 16:29:47 UTC, Monkey wrote:
>
> It doesn't, but if you can send me some example files (address at the 
> bottom of the homepage, http://horman.net/multiblend/) I'll take a look.
>
> On Wednesday, 19 March 2014 20:08:10 UTC, Donald Johnston wrote:
>>
>> Hi, I’ve had to switch back to enblend and use the --no-ciecam option to 
>> fixed some really glaring colour issues.  Does multiblend have a similar 
>> option? 
>>
>> The input files I used are TIF files that were generated by Sony’s “Image 
>> Data Converter” and use the AdobeRGB colour space. 
>>
>>

-- 
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/b150e513-b4cf-425d-84f0-d1e1a0368330%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Multiblend option like --no-ciecam?

[Monkey]

It doesn't, but if you can send me some example files (address at the 
bottom of the homepage, http://horman.net/multiblend/) I'll take a look.

On Wednesday, 19 March 2014 20:08:10 UTC, Donald Johnston wrote:
>
> Hi, I’ve had to switch back to enblend and use the --no-ciecam option to 
> fixed some really glaring colour issues.  Does multiblend have a similar 
> option? 
>
> The input files I used are TIF files that were generated by Sony’s “Image 
> Data Converter” and use the AdobeRGB colour space. 
>
>

-- 
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/dda7070b-524a-4151-b487-98ba55ea0619%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] multiblend 0.6.1 released (bugfixes)

[Monkey]

Hi all,

multiblend, the super-fast blender and drop-in replacement for Enblend, has 
been updated to version 0.6.1 in order to fix a bug which could cause a 
dark band to appear at the bottom of the image. It also fixes another bug 
introduced in a previous version relating to large uncropped images.

Homepage: http://horman.net/multiblend/
Windows binaries (x86 and x64): 
http://horman.net/multiblend/multiblend0.6.1.zip
Source for Linux, FreeBSD, Mac etc: 
http://horman.net/multiblend/multiblend0.6.1.tar.gz

-- 
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/17d1f33c-e2ed-4fd1-8d60-3bd379932724%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] Stacking stars with Hugin's help (show and tell)

[Monkey]

Nope, I wanted to remap the images so as *not* to generate star trails. 
There is software around that does this, but I've never found one I'm 
completely happy with - either they only support simple remapping 
(sometimes only translation, sometimes also rotation but that isn't always 
enough), or the interface is bizarre, or they just plain 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 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/9970633e-b2a7-4faf-ade3-8c4e5b87b14f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] Batch stitching multiple panoramas

[Monkey]

Thanks Bruno (and Pablo, who wrote it!), that has a lot of promise.

-- 
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/27d8ab09-852d-411d-95b7-72ec2f508b34%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] Batch stitching multiple panoramas

[Monkey]

If there was a way to export nona's pixel mappings, someone (possibly me) 
could write an Avisynth (Windows, but runs under Wine) video filter to do 
the heavy lifting. If it's all rectilinear and doesn't involve any of the 
fancier stuff, you might be able to do it with a http://forum.doom9.org/archive/index.php/t-165978.html";>quad 
transform filter, if you can figure out (manually or otherwise) where 
the corners of the images end up.

A pixel mapping import/export would also be useful for Erik's problem https://groups.google.com/forum/#!topic/hugin-ptx/E8MhOKlhvk0";>here.

-- 
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/9c1c636b-4b5d-4f94-8def-6018e468ef05%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] Re: Stitching of many-channel images

[Monkey]

Hi Erik,

I'm replying more out of curiosity towards what sounds like an interesting 
project than being able to contribute any ideas, but it seems to me that 
there may not be much room for shortcuts even if Hugin could handle 
multi-channel images. As my best guess, it would still need to do the same 
amount of disk I/O and the same number of calculations.

Does each channel correspond roughly to a particular frequency of light, as 
with RGB? Is there a specialised viewer for the 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/cabea6f0-6a4b-4296-9700-27ff9808c2ed%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] Re: Stitching of many-channel images

[Monkey]

Okay, I've been foolish - of course, Hugin wouldn't have to recalculate all 
the pixel coordinates, though I'm unsure how much time this could save. I 
can imagine the ability to export those coordinates could be useful for all 
kinds of things, though.

-- 
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/56a35310-a58d-4b1c-bf75-da702b5f6e9c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] Some fast bicubic code of any use to Hugin?

[Monkey]

Some time ago I wrote what, for me, was some fast and highly efficient code 
(using look-up tables and SSE) to do bicubic (or any 4x4 window) 
interpolation on 8-bit RGBA images. It can remap an HD image (1920x1080) in 
about 0.07s on my quad core 2.20GHz laptop - to be honest I don't really 
know if this is good or bad compared to Hugin, but would it be of any use 
to the project? It could also be modified for 16-bit images but it would 
lose some speed.

David

-- 
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/0e28699f-ed37-446e-aacb-d3be0e235d6f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.