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

2021-07-15 Thread Florian Königstein

I did the following changes on Hugin++:

* When stitching the panorama, a temporary file with the image filenames is 
created if the command line would be longer than about
7000 characters (to be exact: 8191 - 1024, older versions of Windows 
support only 8191 chars in a command line,
and for other arguments I reserved generously 1024 chars). So Hugin++ works 
both with enblend and with my modified Multiblend if the command line would 
be too long.

In the control point list the following is changed:

* Added the buttons "next new image pair" and "previous new image pair". A 
click on
  "next new image pair" causes the next image pair (down) in the current 
ordering to
  be selected that is not used by the current or any of the above control 
points.
  I find it useful because I order the list by descending errors. I begin 
with image
  pairs with control points with high errors and delete bad CPs or increase 
weights of good CPs.
  Then I go down in the list, but often there are CPs from the same image 
pair that I have
  already checked. So by clicking on "next new image pair" I don't loose 
time by looking at
  the same image pair several times.
  
* "Stable ordering": You know that the list is sorted when clicking on the 
list header in one column.
  It is sorted by the "sort keys" in that column.
  Stable ordering means that - if there are CPs with equal sort keys - they 
are sorted by the (subordinated) sort key
  of the column on whose header was previously clicked. If there are CPs 
whose subordinated sort keys are also
  equal, they are sorted by a sub-subordinated sort key (in the 2nd 
previously clicked column).
  
* Added "average yaw" and "average pitch" in respective new columns of the 
list. These are the
  average yaw or pitch of the two images of the CP. The yaw and pitch can 
be used just for information or for
  sorting. Since yaw and pitch are real (not integer) values, CPs with 
equal "average" yaw or pitch are typically
  only those belonging to the same pair of images.
  
However you may want to view e.g. all control points with yaw between 20 
and 40 and pitch between 0 and 20 and
sort them by descending error.
This is possible by not using the average yaw or pitch directly as sort 
key. Instead the average yaw and pitch can be
projected into one interval inside a "stack" of equally-sized intervals. 
Then the number of the intervals can
be used as sorting key.
The sorting from the above example can be achieved as follows: First, click 
on the "error" column header once
or twice, so that sorting is done by descending errors.
Then click on the header of the "average pitch" column. A dialog appears in 
that you can specify the pitch interval
from 0 to 20. Chose OK. Now sorting is done by the average pitch interval 
number, followed by the error as subordinated
sort key. Now click on the "average yaw" column header. In the appearing 
dialog choose the interval from 20 to 40.
Now sorting is done by the average yaw interval number, followed by the 
average pitch interval number as subordinated
sort key and by the error as sub-subordinated sort key. All CPs that have 
an image pair with average yaw and pitch in
the respective interval have yaw and pitch interval numbers 0. Scroll the 
list to where these CPs are. They are
sorted by descending errors.

Florian Königstein schrieb am Donnerstag, 1. Juli 2021 um 22:01:19 UTC+2:

> There's a bug both in Hugin++ and in the latest official Hugin release 
> (Hugin-2020.0.0):
> To reproduce it, start Hugin, and open a PTO file that is large enough so 
> that the loading takes some seconds.
> Before the loading has finished, press the grayed out button for 
> geometrical optimization in the "images" tab TWO times.
> After loading has finished, two windows with title "Panorama Tools" will 
> appear. In one the text 012345678901234567890123456789... appears
> and nothing changes over time.
> The other "Panorama Tools" window behaves normally. When finished 
> optimization, accept the results.
> Then Hugin / Hugin++ will crash.
>
> I didn't have the time to fix the bug. Maybe later.
>
> Florian Königstein schrieb am Donnerstag, 1. Juli 2021 um 21:46:47 UTC+2:
>
>> I have an update for fastPTOptimizer and also for the Windows installer 
>> for Hugin++ that also installs the binaries for fastPTOptimizer.
>> When there are weights for CPs other than 1, say a weight 'w', it should 
>> be exactly as if you had 'w' CPs with weight 1 at the same position. In the 
>> old version of fastPTOptimizer the reported error during the optimization 
>> wasn't correct. If e.g. all weights are 1000, the reported error should be 
>> the same as if all weights were 1 since the error is an average over all 
>> CP's errors. In the old version the error was too high if weights > 1 were 
>> used. I have corrected it.
>>
>> bruno...@gmail.com schrieb am Donnerstag, 1. Juli 2021 um 12:14:54 UTC+2:
>>
>>> Apologies, I was wrong about this. Sourceforge does support the usual 
>>>

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

2021-07-15 Thread Florian Königstein
Now I know what Gunter meant with passing @filename to a program. This is 
not a feature
of the Windows OS, but enblend and enfuse support it.
So I changed my modification of multiblend so that you can (and must) use 
@filename instead of
-argfile=filename of -argfile filename.

Enblend and enfuse seem to support also nested "response files" and 
wildcards in the filenames. And
the lines in a @filename - file seem to be all interpreted as images - not 
as other parameters.
In my modification of multiblend they are interpreted as further arguments 
- these can be images if placed
after the -o outputfile.

I also changed my fork of Hugin (Hugin++) so that a temporary file with the 
image filenames is created if
the command line would be longer than about 7000 characters (8191 - 1024, 
older versions of
Windows support only 8191 chars in a command line, and for other arguments 
I reserved generously 1024 chars).
So Hugin++ works both with enblend and with my modified Multiblend if the 
command line would be too long.

Florian Königstein schrieb am Sonntag, 4. Juli 2021 um 20:36:19 UTC+2:

> 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 = (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...
 Processin