Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
I also changed the columns with the "left image" and the "right image". You know that every control point connects two images. One of the image is declared to be the "left image" and the other the "right image". But for the functionality of the control point it doesn't matter whether it's declared so or vice versa (reversing the assignment of "left image" and "right image". It seems that when creating CPs with CPfind (Hugin's automatic CP detector), the image with the smaller image number is declared as "left image" and the other (with bigger number) the "right image". But if you add CPs manually in the CP editor, you may select an image with a bigger number in the left image pane and the other in the right pane. Then when adding CPs manually, they have the bigger image number "left" and the smaller number "right". When using Hugin, I may want to see in the control point list all CPs that connect one special image (say image Nr. 100) with any other image. In Hugin version 2020 I can sort the column "left image" by clicking on its header. Sometimes I made the error to assume that by scrolling to the CPs with "left image" 100 I could see all CPs that connect image 100 with some other. But this is not right because there are also CPs that have image 100 as "right image" and some other as "left image". So I decided not to use the columns "left image" and "right image", but instead the columns "Min Image Nr" and "Max Image Nr". The problem with finding all CPs with and image Nr 100 and any other image is still there in my version of Hugin (with the new columns), but in my eyes it's clearer with my solution. When sorting by ascending "Min image" and go to where the min images Nr 100 are, it's clear that the corresponding "Max images" cannot be smaller that 100. So you must afterwards sort by "Max image Nr" and goto max images 100. So you can see the min images with numbers < 100. Of course the problem of finding all CPs that connect e.g. image Nr. 100 with some other image can also be solved in the CP editor by selecting image Nr. 100 left and seeing the images that are highlighted in the drop-down list right. When selecting two images in the left and right drop-down lists in the image editor all CPs are shown if they connect these two images - even if the assignment to "left" and "right" image is reversed. This also shows that the order in that "left" and "right" are assigned to the images of a CP doesn't matter for the functionality. . Florian Königstein schrieb am Donnerstag, 15. Juli 2021 um 09:36:42 UTC+2: > > 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 inter
Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
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: Hugin++ : fast geometrical optimization and other features
There's a bug both in Hugin++ and in the latest official Hugin release (Hugin-2020.0.0): To reproduce it, start Hugin, and open a PTO file that is large enough so that the loading takes some seconds. Before the loading has finished, press the grayed out button for geometrical optimization in the "images" tab TWO times. After loading has finished, two windows with title "Panorama Tools" will appear. In one the text 012345678901234567890123456789... appears and nothing changes over time. The other "Panorama Tools" window behaves normally. When finished optimization, accept the results. Then Hugin / Hugin++ will crash. I didn't have the time to fix the bug. Maybe later. Florian Königstein schrieb am Donnerstag, 1. Juli 2021 um 21:46:47 UTC+2: > I have an update for fastPTOptimizer and also for the Windows installer > for Hugin++ that also installs the binaries for fastPTOptimizer. > When there are weights for CPs other than 1, say a weight 'w', it should > be exactly as if you had 'w' CPs with weight 1 at the same position. In the > old version of fastPTOptimizer the reported error during the optimization > wasn't correct. If e.g. all weights are 1000, the reported error should be > the same as if all weights were 1 since the error is an average over all > CP's errors. In the old version the error was too high if weights > 1 were > used. I have corrected it. > > bruno...@gmail.com schrieb am Donnerstag, 1. Juli 2021 um 12:14:54 UTC+2: > >> Apologies, I was wrong about this. Sourceforge does support the usual >> fork/pull-request workflow, with both mercurial and git. >> >> -- >> Bruno >> >> On 28 June 2021 20:51:13 BST, Bruno Postle wrote: >> >> >This is an illustration of our creaking infrastructure. Sourceforge >> >doesn't support the fork/pull-request/merge workflow that we have >> >become used-to with github/bitbucket, so anyone wanting to work >> >separately on Hugin needs to create a new repository or create a >> >branch in the main repository. Florian, do you need access to work on >> >this in a Hugin branch? >> > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/6af9b651-69b7-4474-bcb7-cb4c7cca0d2fn%40googlegroups.com.
Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
I have an update for fastPTOptimizer and also for the Windows installer for Hugin++ that also installs the binaries for fastPTOptimizer. When there are weights for CPs other than 1, say a weight 'w', it should be exactly as if you had 'w' CPs with weight 1 at the same position. In the old version of fastPTOptimizer the reported error during the optimization wasn't correct. If e.g. all weights are 1000, the reported error should be the same as if all weights were 1 since the error is an average over all CP's errors. In the old version the error was too high if weights > 1 were used. I have corrected it. bruno...@gmail.com schrieb am Donnerstag, 1. Juli 2021 um 12:14:54 UTC+2: > Apologies, I was wrong about this. Sourceforge does support the usual > fork/pull-request workflow, with both mercurial and git. > > -- > Bruno > > On 28 June 2021 20:51:13 BST, Bruno Postle wrote: > > >This is an illustration of our creaking infrastructure. Sourceforge > >doesn't support the fork/pull-request/merge workflow that we have > >become used-to with github/bitbucket, so anyone wanting to work > >separately on Hugin needs to create a new repository or create a > >branch in the main repository. Florian, do you need access to work on > >this in a Hugin branch? > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/2ba6afce-aaa2-440f-9c97-fa1b7ef98b35n%40googlegroups.com.
Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
Apologies, I was wrong about this. Sourceforge does support the usual fork/pull-request workflow, with both mercurial and git. -- Bruno On 28 June 2021 20:51:13 BST, Bruno Postle wrote: >This is an illustration of our creaking infrastructure. Sourceforge >doesn't support the fork/pull-request/merge workflow that we have >become used-to with github/bitbucket, so anyone wanting to work >separately on Hugin needs to create a new repository or create a >branch in the main repository. Florian, do you need access to work on >this in a Hugin branch? -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/190626BF-0F44-47E3-B232-991E76969BA9%40postle.net.
Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
@Bruno: Thanks, but I think for the moment I put my work into Hugin++ / fastPTOptimizer. Maybe later. gunter.ko...@gmail.com schrieb am Montag, 28. Juni 2021 um 22:08:55 UTC+2: > If weighing control points by cpfind's confidence that this is a valid > control point makes sense? If there are repeating structures like window > fronts sometimes control points look excellent even at the second glance, > though... > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/719fed66-9b4c-4a55-b043-a79255282aaan%40googlegroups.com.
Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
If weighing control points by cpfind's confidence that this is a valid control point makes sense? If there are repeating structures like window fronts sometimes control points look excellent even at the second glance, though... -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/FECFD97A-86ED-45E2-AFF4-33070751CD86%40gmail.com.
Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
On Mon, 28 Jun 2021 at 16:19, Tobias wrote: > > what is the reason, that fastPTOptimizer is not part of the official hugin. It is in a branch of libpano13, but this code is still being worked-on, so ready for testing but not ready for release: https://sourceforge.net/p/panotools/libpano13/ci/libpano13-2.9.21/tree/ This is an illustration of our creaking infrastructure. Sourceforge doesn't support the fork/pull-request/merge workflow that we have become used-to with github/bitbucket, so anyone wanting to work separately on Hugin needs to create a new repository or create a branch in the main repository. Florian, do you need access to work on this in a Hugin branch? -- 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/CAJV99ZheqBZgoJuV92jVrCXp%3D%2BUs-Ayy%2Bwafm_2BNAXp8ZZvUA%40mail.gmail.com.
Re: [hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
On Mon, 28 Jun 2021 at 16:19, Tobias wrote: > > what is the reason, that fastPTOptimizer is not part of the official hugin. It is in the -- 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/CAJV99ZhwYi7wtdH5F3nzN3d%2BqKziNT6qFkBx2A7-TATT%2ByftmQ%40mail.gmail.com.
[hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
I believe that fast optimization like in fastPTOptimizer will also be available in Hugin in the next official release. I see fastPTOptimizer and Hugin++ as a possibility to publish my ideas as sources and also binaries a bit earlier - for encouraging discussions and also because I like using these features for my own panoramas. Maybe there are some features in Hugin++ that shall not be integrated into Hugin for some reasons, e.g. there was a discussion whether weights for control points make sense. Anyway I try to avoid unnecessary changes to the source code in order to facilitate a possible integration of my new features into Hugin. Florian Tobias schrieb am Montag, 28. Juni 2021 um 17:19:18 UTC+2: > Hello, > > what is the reason, that fastPTOptimizer is not part of the official hugin. > > Regards, > Tobias > > Florian Königstein schrieb am Montag, 28. Juni 2021 um 09:31:08 UTC+2: > >> Hugin++ is a fork of Hugin that is linked to fastPTOptimizer, a fork of >> the libpano13 library. >> >> When you have only a small or medium number of images and control points, >> the original optimizer does the optimization in a fairly short time. >> However if you have a large number of images (several hundrets or even more >> than thousand) and many control points, the original optimizer typically >> needs much time for the optimization of the parameters. >> >> With Hugin++ the time for the geometrical optimization is much shorter >> for large panoramas. Speedup factors of 100 or more are possible. >> >> Update 28.06.2021: >> >> I have added support for weights for control points. The default weight >> for each control points is 1. Assigning a weight higher than 1, say 'w', to >> a control point is equivalent to have 'w' control points with weight 1 at >> the same position. This causes the control point's error to contribute 'w' >> times more to the (weighted) sum of squares that the optimizer tries to >> minimize. >> >> A control point with a high weight tends to have a small error after >> optimization - if this is >> possible. But high weights should be used with care: In the extreme case >> that all control points have a weight of e.g. 1000 the optimizer finds >> exactly the same parameters as if the control points had the weight 1. What >> counts is the relation of the weights for the different control points. >> >> What makes sense is assigning higher weights to control points that are >> likely placed precisely and lower weights to points that are less precise, >> e.g. if the object where they are placed may have moved in the meantime >> between shooting the two images. >> You may also assign high weights to control points on objects where >> larger errors would be visually striking - if you are sure that these >> objects have not moved much. >> >> For example, I have shot photos for a panorama where are trees, a stream >> and a bridge over the stream. After optimization without weights for >> control points (or all CPs having equal weight) there were visually >> striking errors on the bridge. On the other hand I know that the bridge has >> not moved noticeably. >> So I could assign higher weights to CPs on the bridge. Other CPs, e.g. on >> the trees, might have moved - especially if they are on leafs of smaller >> branches of trees. Of course I tried not to place CPs on leafs but instead >> on trunks or bigger branches of the trees. But this in not always possible >> - especially if you use a high focal length (low angle of view). >> >> Generally, assigning higher weight to a control point can lead to smaller >> errors of the CPs - if this it possible. But this is on the cost of getting >> larger errors on other control points. >> If the CP with a higher weight is placed precisely, the increase of >> errors on other control points will probably be tolerable. A counterexample >> is the following: If a "bad" control point, e.g. an outlier (placed on >> different objects) or on a moving object, is assigned a higher weight, the >> error for this CP might decrease, but all other errors might increase in a >> non-tolerable way. >> >> The "weights for control points" feature is currently available in a >> development version of Hugin++: >> https://sourceforge.net/projects/huginplusplus/files/development/ >> >> Currently the only way to assign weights other than 1 to control points >> is changing the weight manually in the "control points" tab of Hugin++. >> Control points that are generated automatically, e.g. by CPfind, will >> currently have weight 1. >> A nice task for the future would be to change CPfind so that the control >> points get a weight other than 1 automatically. Some algorithm - including >> machine learning algorithms - might predict whether the control points >> might be on a moving object and how large a possible movement might be. >> With this information the CP detector could assign reasonable weights to >> the control point. >> > -- A list
[hugin-ptx] Re: Hugin++ : fast geometrical optimization and other features
Hello, what is the reason, that fastPTOptimizer is not part of the official hugin. Regards, Tobias Florian Königstein schrieb am Montag, 28. Juni 2021 um 09:31:08 UTC+2: > Hugin++ is a fork of Hugin that is linked to fastPTOptimizer, a fork of > the libpano13 library. > > When you have only a small or medium number of images and control points, > the original optimizer does the optimization in a fairly short time. > However if you have a large number of images (several hundrets or even more > than thousand) and many control points, the original optimizer typically > needs much time for the optimization of the parameters. > > With Hugin++ the time for the geometrical optimization is much shorter for > large panoramas. Speedup factors of 100 or more are possible. > > Update 28.06.2021: > > I have added support for weights for control points. The default weight > for each control points is 1. Assigning a weight higher than 1, say 'w', to > a control point is equivalent to have 'w' control points with weight 1 at > the same position. This causes the control point's error to contribute 'w' > times more to the (weighted) sum of squares that the optimizer tries to > minimize. > > A control point with a high weight tends to have a small error after > optimization - if this is > possible. But high weights should be used with care: In the extreme case > that all control points have a weight of e.g. 1000 the optimizer finds > exactly the same parameters as if the control points had the weight 1. What > counts is the relation of the weights for the different control points. > > What makes sense is assigning higher weights to control points that are > likely placed precisely and lower weights to points that are less precise, > e.g. if the object where they are placed may have moved in the meantime > between shooting the two images. > You may also assign high weights to control points on objects where larger > errors would be visually striking - if you are sure that these objects have > not moved much. > > For example, I have shot photos for a panorama where are trees, a stream > and a bridge over the stream. After optimization without weights for > control points (or all CPs having equal weight) there were visually > striking errors on the bridge. On the other hand I know that the bridge has > not moved noticeably. > So I could assign higher weights to CPs on the bridge. Other CPs, e.g. on > the trees, might have moved - especially if they are on leafs of smaller > branches of trees. Of course I tried not to place CPs on leafs but instead > on trunks or bigger branches of the trees. But this in not always possible > - especially if you use a high focal length (low angle of view). > > Generally, assigning higher weight to a control point can lead to smaller > errors of the CPs - if this it possible. But this is on the cost of getting > larger errors on other control points. > If the CP with a higher weight is placed precisely, the increase of errors > on other control points will probably be tolerable. A counterexample is the > following: If a "bad" control point, e.g. an outlier (placed on different > objects) or on a moving object, is assigned a higher weight, the error for > this CP might decrease, but all other errors might increase in a > non-tolerable way. > > The "weights for control points" feature is currently available in a > development version of Hugin++: > https://sourceforge.net/projects/huginplusplus/files/development/ > > Currently the only way to assign weights other than 1 to control points is > changing the weight manually in the "control points" tab of Hugin++. > Control points that are generated automatically, e.g. by CPfind, will > currently have weight 1. > A nice task for the future would be to change CPfind so that the control > points get a weight other than 1 automatically. Some algorithm - including > machine learning algorithms - might predict whether the control points > might be on a moving object and how large a possible movement might be. > With this information the CP detector could assign reasonable weights to > the control point. > -- 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/7d138fac-4055-4e74-82a6-4868725b438cn%40googlegroups.com.
