Re: [hugin-ptx] Is there any way to keep pixels unchangeable with Hugin?
Are you sure that working on a gray scale representation of the thernographys looses information? Normally a thermocam has an 8-bit ADC, and allows to save pictures in 256 different gray levels or alternatively using a palette that provides 256 colors that are easier to distinguish visually. It also most certainly comes with software that losslessly converts images from one of these formats to the other. Ergo the correct workflow would be: Losslessly convert the pictures to gray scale, then stitch them and then convert them to the fancy colorful palette. -- 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/D5F75D3F-73B6-4384-95F5-120AD016EA0F%40gmail.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.
Re: [hugin-ptx] Is there any way to keep pixels unchangeable with Hugin?
On Mon, 28 Jun 2021 at 12:08, Álvaro Huertas wrote: > > thanks you so much for the response! > > I tried your tips but with no results, hugin still modifying pixels in the > false color panorama. Since I'm working without interface (i'm scripting in > python through CLI commands) I found some issues: > > - Once I import any photo Er and Eb photometric parameters are set to 1 > automatically. If I try to set it up to 0 with pto_var then nona throw the > following exception: Sorry my mistake, yes the Er and Eb parameters should be set to 1. If you are doing all this outside the Hugin GUI, then probably you only need to reset the Ev photometric parameters. > - I'm using the nona '--seam=hard' option in the CLI so I think tip nº2 its > working fine. > > - About the interpolator choice: I can't select the interpolator in CLI > command of nona: The interpolator is set in the 'i' parameter of the 'm' line in the PTO file, so you need to edit the line that looks something like this: m g1 i0 f0 m2 p0.00784314 ..and change i0 to i6 (the format is described in the nona.txt file: https://sourceforge.net/p/hugin/hugin/ci/default/tree/doc/nona.txt ) > Even if I do this step in interface, pixels still beeing modified (maybe > because of the issue with step 1). -- Bruno -- 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/CAJV99ZjU-Vm7CngmCrsu29edB3N-gETOePy307TJbp3%3DLcH9sA%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.
[hugin-ptx] Re: Is there any way to keep pixels unchangeable with Hugin?
El domingo, 27 de junio de 2021 a las 12:18:04 UTC+2, Monkey escribió: > Is there any way you can convert your false colour images to a linear > greyscale first? > > No, there isn't. Losing a lot of information converting the original temperatures to just 255 value of grayscale. -- 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/2ad780fd-1775-435c-92b7-dec23737fb44n%40googlegroups.com.
Re: [hugin-ptx] Is there any way to keep pixels unchangeable with Hugin?
El domingo, 27 de junio de 2021 a las 11:10:35 UTC+2, bruno...@gmail.com escribió: > > There are three things you need to do: > > 1. Disable any photometric optimisation. Set all the photometric > parameters of all your input photos to zero, and the EV of the output > panorama to zero. This will prevent Hugin from trying to 'fix' the > exposure for you. > > 2. Disable blending between photos. In the Stitcher tab, set a blender > command-line option of '-l 0', or just use the 'built-in' blender > option with 'hard-seam' set. This will prevent mixing of colours from > adjacent photos. You will now see a hard-edge between photos in the > stitched output. > > 3. Disable interpolated sampling. In the stitcher tab, remapper > options, set the interpolator to 'Nearest neighbour'. Hugin is usually > averaging several adjacent input pixel values to generate an output > pixel, you don't want this 'anti-aliasing' behavior. The results will > not look as smooth, and arguably you are losing data with 'Nearest > Neighbour', but each output pixel will get its value from a single > input pixel. > > Hi Bruno, thanks you so much for the response! I tried your tips but with no results, hugin still modifying pixels in the false color panorama. Since I'm working without interface (i'm scripting in python through CLI commands) I found some issues: - Once I import any photo Er and Eb photometric parameters are set to 1 automatically. If I try to set it up to 0 with pto_var then nona throw the following exception: [image: 1.JPG] Variables will look like this in the .pto file: *#-hugin cropFactor=1* *i w640 h512 f0 v17 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er0 Eb0 r0 p-0.82153530183907 y-33.6586917800566 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 Vm5 n"000_encoded.png"* There will be no problem with Er and Eb set to 1 so I think 0 is a not valid value. I'm not using any kind of automatic geometric or photometric optimization, I'm selecting the variables I want to opmitize through pto_var. Could this be causing problems? - I'm using the nona *'--seam=hard'* option in the CLI so I think tip nº2 its working fine. - About the interpolator choice: I can't select the interpolator in CLI command of nona: Even if I do this step in interface, pixels still beeing modified (maybe because of the issue with step 1). Let us know how you get on. When I was (briefly) surveying solar > arrays the drone was using a multi-spectral imaging camera, is your > data converted to RGB? Changing the Hugin stack to work with more than > three channels would be _very_ difficult. > > -- > Bruno Yes, I'm turning the thermal matrix from video frames of SEQ files (FLIR propietary thermal video files) into coded RGB images that i'm stitching. Once I stitch them I retrieve the thermal info back from coded pixels of the panorama. I know I'm losing thermal precision with this technique but its enough to do the job. Thanks in advance! Álvaro. -- 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/5a463ee8-5245-4e10-87ad-72adb1a60e42n%40googlegroups.com.
[hugin-ptx] Hugin++ : fast geometrical optimization and other features
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/254465cd-58af-4642-9442-b9bf7815285dn%40googlegroups.com.
[hugin-ptx] Hugin++ : fast geometrical optimization and other features
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/ -- 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/7093d772-d5d1-4824-bb4b-6574eddf0f76n%40googlegroups.com.
