Re: [hugin-ptx] Trying to compile Hugin: what is this MSGFMT error?
On Thursday, October 6, 2022 at 7:38:43 AM UTC-4 kornel wrote: > why don't you use 'make package'? That way. you should get a file like > hugin-2021.1.0.8500-Linux.deb, which may be installed with > # sudo dpkg -i hugin-2021.1.0.8500-Linux.deb > > I have no guess why the OP chose not to do that. But I always choose not to do that because I want to build and test my own binaries separate and not interfering with downloading and testing the distribution's binaries. Feel free to teach me something about the process that I am misunderstanding (I'm an expert C++ programmer, stumbling around in the dark on many of the build vs. distribution topics), but so far as I have discovered, building all the way to an installable package makes it harder to do an isolated test of your new binaries. -- 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/c8e8e30d-de8a-40fe-b7bd-2cc9d69d6a5bn%40googlegroups.com.
Re: [hugin-ptx] Trying to compile Hugin: what is this MSGFMT error?
How is what finally worked different from what earlier didn't work? For example, the instructions had /PATH/TO/HUGIN/SOURCES where your final working version had .. I assume .. is the path to hugin sources (from the place where you had your build directory). It is starting to sound like there was a problem in that aspect originally. I personally would not make the build directory of a complicated open source project be a sub directory of the repository (except in projects with brain dead build tools giving you no choice). As you discovered, that method does work. But it still is not a great idea. On Wednesday, October 5, 2022 at 11:25:49 PM UTC-4 GnomeNomad wrote: > On 10/5/22 02:02, Kornel Benko wrote: > > Am Tue, 4 Oct 2022 21:54:17 -1000 > > schrieb "David W. Jones" : > > > >> On 10/4/22 20:40, Gunter Königsmann wrote: > >>> Either you haven't gettext installed > >> > >> I have gettext 0.21-4 installed. > >> > >>> or your cake is too old to know about it. > >> > >> Cake? You mean cmake? cmake is v3.18.4. > >> > >> This is on Debian 11. It's been almost a year since the last time I > >> compiled Hugin. I successfully compiled Hugin 2021 to a /usr/local > >> installation 1 January 2022. > >> > >> Ideas? > >> > > > > It is part of hugin sources. Don't know, why cmake is not finding it. > > > > Look foe 'CMakeModules/FindMSGFMT.cmake' in your cloned hugin. > > > > Kornel > > I find that one in the cloned hugin tree. Cmake is still not finding > MSGFMT, although that is installed. > > Here's what cmake tells me: > > CMake Error at celeste/CMakeLists.txt:71 (set_target_properties): > set_target_properties called with incorrect number of arguments. > > CMake Error at translations/CMakeLists.txt:7 (find_package): > By not providing "FindMSGFMT.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by > "MSGFMT", but > CMake did not find one. > > Could not find a package configuration file provided by "MSGFMT" with any > of the following names: > > MSGFMTConfig.cmake > msgfmt-config.cmake > > Add the installation prefix of "MSGFMT" to CMAKE_PREFIX_PATH or set > "MSGFMT_DIR" to a directory containing one of the above files. If > "MSGFMT" > provides a separate development package or SDK, be sure it has been > installed. > > Gettext and msgfmt are installed here. > > Anyway, here's what finally worked: > > 1. Run "cmake .." in the build directory. That put the missing MSGFMT > .cmake files in a subfolder under the build directory. > > 2. Run "make". > > 3. Run "sudo make install". > > That gave me a Hugin reporting itself as "Version: Pre-Release > 2021.1.0.33b93e37f209". Is that correct? > > -- > 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/f83830f5-48b1-4749-a78d-9839cf160634n%40googlegroups.com.
Re: [hugin-ptx] Re: Repeated failed stitching
On Sunday, September 18, 2022 at 3:16:14 PM UTC-4 alexande...@gmail.com wrote: > So I shot the image sequences with the camera attached to a handcart in a > rigidly fixed position so there should be hardly any plane pitch or yaw. > And for optimising, my process was the following: > > - Optimize for TrX only, which produced an average unit distance under 1 > (can't remember exact figures off the top of my head) > - Optimize for TrY and TrZ only, producing an average unit distance in the > .4-5 range > - Optimize for yaw, pitch and roll at which point the unit distance was > around .2 > > The resulting panorama looked great to my eyes but are these differences > still to great? > There is no simple scale for what values are good enough from optimize. But typically, values under 0.5 are good. Did you look individually at a few of the worst fitting control points? How bad were they? Was it really a locally bad optimize result or were the control points on non matching actual points? When you find bad control points, it is usually worth the effort to fix or delete them and then rerun the optimize (you don't need to reoptimize from scratch. Your current best fit is a good starting point). If instead it is a locally bad fit, I next got to the final panorama and zoom in near the locally bad fit and try to spot the seam. If you can find the seams by zooming in on the panorama, that is a defect that is likely worth fixing. Looking great when you look at a whole panorama is usually not good enough (for me anyway). It should look great even if you pan around a zoomed image looking for seams. -- 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/47e7f678-67c6-464e-8f5b-20f31d4b4e94n%40googlegroups.com.
Re: [hugin-ptx] Re: Repeated failed stitching
There is a correct fov for each image (assuming it was taken with a camera, rather than a scanner). Giving it an incorrect low fov for each image can solve some problems. But it does create other problems, so I don't think you should leap to that choice so quickly. The fov of each image together with the way they connect gives you the field of view of the entire panorama. So I don't think anything useful could be accomplished by setting the panorama fov low relative to the value accumulated from stitching. I haven't read this thread carefully enough to be sure, but I think you are doing the optimize step without enabling translationX to be changed. But in taking the photographs, translationX is the primary change. I think you should use expert mode and redo the optimization (from a reset state) with just tx, ty and tx enabled (yaw, pitch and roll disabled). Once that is approximately correct, optimize again from that stating point also enabling yaw, pitch, roll and maybe other parameters. Once you have good parameters, to get a more realistic fit of control points, I'm not sure what to do with projection issues. I expect you'll still have projection issues. But I think the path forward will be easier once the tx values are reasonable. -- 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/8ef294b5-6aa4-41e6-b1ca-65c034a017cfn%40googlegroups.com.
Re: [hugin-ptx] Shooting Panoramas in Tight Spaces
On Thursday, September 8, 2022 at 11:41:00 PM UTC-4 alexande...@gmail.com wrote: > . Relative depth may be the main issue I run into here because there are > parts of a house as well as trees visible behind the wall at various > distances. In that case, your idea of working from a hypothetical nodal point might be good (but the split into component images based on that point still doesn't make sense). Imagine you had drawn lines from the nodal point to places on the image, and wherever you stand about 30 feet from the wall, you are on those lines. If you adjust the yaw of the camera to point down that line from each point, you would eliminate a lot of the parallax. Compare to a normal panorama in which you change only yaw with no sideways motion, and compare to normal stitching of a long mural etc. in which you have only sideways motion and not a change in yaw. If you could exactingly change both together to create the point of view of the hypothetical nodal point, you could greatly reduce parallax. Having never tried that, I don't then know the best path through hugin optimize. You would have a panorama that could stitch very well once the correct yaw and Tx values are computed, but the optimizer will still see Tx and Yaw as locally ambiguous. It might take some manual tweaking to get the values close to what you know you did with the camera, then optimization could fine tune. In stitching from that, the parallax would be largest on the seams where stitching is choosing between two different images. Hopefully, either automatically or with some masking, the actual seams could be along contours that don't show the parallax. All that might be too much work. It is just an idea. -- 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/1ae6e3dc-deff-4092-a730-d3ae891f5d04n%40googlegroups.com.
Re: [hugin-ptx] Problem: Only 1/4 of Fast Panorama Visible
It has been asked before and I see no answer https://groups.google.com/g/hugin-ptx/c/qWe1L4QhlDk/m/QgV5TTeWAwAJ If (unlike those who asked before) you have the problem on Windows or Linux, I could probably diagnose it with more information. If it is mac, were you using the version posted in this thread https://groups.google.com/g/hugin-ptx/c/RBazQ8bBOSY/m/uGT4M7t_AwAJ or an older version? If it was that version, maybe the person who built it can diagnose it. Most of us here cannot diagnose mac specific defects. -- 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/62bce236-6f03-40ac-9ffd-6b1e831b56ddn%40googlegroups.com.
Re: [hugin-ptx] Re: What am I doing wrong optimizing with Hugin 2021.0.0
On Tuesday, August 16, 2022 at 3:25:26 PM UTC-4 Florian Königstein wrote: > >> But I took parts of the old code and built a command line utility named >> Hugin2PTOptimizer that converts a Hugin .pto file to a .pto file readable >> by PTOptimizer. >> I have messed a bit around in the code and put all into one file >> Hugin2PTOptimize.c. Therefore it's not maintainable, but hopefully it does >> what it shall do. >> I compiled it with VS 2019. If there are problems compiling it with >> Linux, let me know. >> >> It does not compile in mingw64 and I'm certain would not in Linux, and there are far too many problems to fix. I had started a similar program myself, before you sent that. My biggest problem was (and partially still is) identifying the relationship of tags in the .pto file to fields in pano13 data structures and fields in Hugin data structures. I used y Hugin2PTOptimize.c as an extra source (on top of the pto reading and writing code in hugin and pano13) for understanding the relationship of fields to tags. My version reads a .pto file (hugin format or pano13 format) and combines the data from a previous run of optimize (if present) into the image data, then optionally adds a specified amount of random noise to the optimized values, and writes out a new .pto file. As a tool, this is intended for testing the benefits of changes to optimize. Optimize is an unstable enough process that insignificant differences can cause massive result differences (likely including the case that led me to start this thread). So if you make a small change that ought to on average cause a small improvement, testing giving a giant degradation or giant improvement is more likely than "average" results. So ordinary testing can't tell you whether the coding change doesn't work as expected vs. something is flawed in the example vs. basic instability of optimize. My theory and hope is that running a program versions to be tested against each optimize problem many times with different random noise added, will give results that show meaningful differences between versions. As a coding exercise, I built this C++ program to 1) Figure out good methods to use headers and structs from the pano13 C code and ultimately maintain a compatible C interface while rewriting a lot of the operations in C++. There are problems with those headers and those structs for C++, but solutions aren't very difficult. 2) Find a better and more unified way to act generically across fields. This is done and/or not done in many different ways across hugin and pano13 and I did not like any of them. Use of #include tricks and heave use of #define obfuscates that code and makes debugging the code much harder. At the opposite extreme, use of switch statements to split out tags causes massive code bloat and related maintenance problems. I created a better method with templated maps and very minimal use of #define. That will need a bit more touch up (as I get a more complete understanding of the whole system of tags and fields) before I use it in a C++ rewrite of optimize and other parts of pano13. Like you, I put all the code in one file (except for use of the unmodified filter.h and other headers it pulls in). Once the code is more stable, it should be clear how to split to multiple cpp and hpp files. If anyone want that code, ask and I'll put it somewhere accessible. I'm open to suggestions. I put a ??? comment in the code in places where I didn't know the right way to do something because I don't understand the related parts of the pano13 package well enough. -- 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/750f3884-b1e8-4f7f-9735-3f8938fb45c8n%40googlegroups.com.
Re: [hugin-ptx] Pano curves upward despite level images
I wish my panoramas came together as well or as easily as that one. After I emailed back the .pto with several garbage CPs removed, I tried stitching and the result is better than I've ever gotten without major effort. The automatic CP detection sometimes creates a few garbage ones. If I remember correctly, all but one of your garbage CPs were on clouds. I never use the tool for auto removing CPs from clouds, but there is one. Likely it works. Many people also use the main control point table (from the view menu) sorted by distance, to identify garbage CPs. In the state you sent the file, the approach was hopeless. The highest distances were perfectly good CPs and the bad ones were down of few positions on the list. Likely after removing the ones on clouds and reoptimizing, the last garbage one would have stood out on that list. I didn't try that. In the control Points tab, the garbage CPs were so obvious, no real effort went into finding and deleting them (never works that way for my panoramas). Once the garbage CPs were gone, your panorama had a better fit than I ever get even after being sure all my CPs are perfect to a fraction of a pixel. Anyway, it is not an example for my enhancements to huggin++ for hard examples. But I'm glad I could help. And it is good for me to see examples demonstrating that my own are not that representative. -- 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/cf8b2019-d83a-4cf6-be61-01a4962918dfn%40googlegroups.com.
Re: [hugin-ptx] Pano curves upward despite level images
I'm not seeing at all what I expected. So I may have been entirely wrong about all that lens stuff. So ignore most of what I said. Instead you have some very very wrong control points that must be deleted and that might be the only important problem. For example the two CPs connecting image 0 to image 2. As I said before, the CPs on clouds connecting image 1 to 2 are also bad and also should be deleted. But as I said before, they are actually doing only a little harm (less than typical for CP's on clouds) while other wrong CP's are doing severe harm. -- 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/6fa01946-fa47-4903-9390-faa8ea12066dn%40googlegroups.com.
Re: [hugin-ptx] Re: What am I doing wrong optimizing with Hugin 2021.0.0
On Friday, August 12, 2022 at 12:37:53 PM UTC-4 Florian Königstein wrote: > Probably it's best here to first optimize only raw, pitch and roll and > then only translations. I gave that a lot of thought, and I have not yet coded/tested what I decided to do instead. But I think there is a better way to structure the idea of "first optimize only ...". My testing so far has caused me to conclude I need to first stabilize the behavior of what is there now, before making the big changes I really want. There is too much tendency for giant changes in performance and result quality from what is essentially luck (chaotic magnification of initial rounding error). To stabilize what is there now (reduce the luck element in its results): I think the ambiguity between rotation and translation is not a big problem. The two big problems that I think I understand are: 1) images that are not directly connected to the anchor image 2) the instability of the lens correction and fov optimization. I don't understand the benefits of the first stage optimizing one distance rather than two directional distances. But for now I'll trust that concept and expand on it. I want several initial stages, and lens parameters changeable only in the last initial stage. After all the initial stages, the "stage 2" would run exactly as it does now. As they do now, the initial stages would all run with cutoffs that should make then stop quickly (get only a rough fit). 1) First it would take the anchor image plus all those images that share 3 or more CPs with the anchor. 2-?) For subsequent initial stages, each time add all images that share 3 or more CPs with the union of all images of the prior stage. ?+1) If necessary (implying a very badly connected panorama) add all the rest of the images ?+2) Enable lens and fov if those were specified to be optimized. In cases where lens correction is major enough, it becomes a user problem to get the lens right (or at least close) first. In normal expert use, I expect the lens was solved earlier and not subject to further optimization. In normal beginner use, I expect the whole lens correction is subtle enough that delaying its optimization (earlier initial stages use whatever values were already there) is fine for the rough estimate intent of those stages. Each initial stage will only happen if it adds something to the previous initial stage. So simple panoramas with lens and fov already fixed would have the same single initial stage they have now. BTW, do you have any .pto files (in the format read by PToptimize.exe) that you think I should include in my testing? Is there some simple way (especially when you don't have the image files) to create a .pto in the PToptimize.exe format from a .pto in the hugin format? -- 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/777343f9-5ea9-4379-be85-8c03e59a42a5n%40googlegroups.com.
[hugin-ptx] Re: Easiest way to retain dynamic range?
Your last two posts seem to be about one image. I assume you have more than one to combine via hugin. So when I asked about the different exposures across the multiple original images, I think that was important. I don't see any answer. I'm still guessing that hugin is adjusting the exposures to eliminate that differences in original exposure across the images, and that is where the highlights are lost, meaning 4 bits added (to the original 12) are not enough to bridge the exposure differences. You seem to have already figured out that a different conversion from raw to tiff would result in protecting those highlights from subsequent destruction. I know far less about Rawtherapee than you know. So my terminology is likely wrong. But logically, a less linear mapping in the original conversion from 12 bits to 16 bits would provide the extra room to protect the highlights from the subsequent adjustment (that normalizes exposure between photos). -- 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/79b63d96-528b-4c62-899d-6cbdddaa0f17n%40googlegroups.com.
Re: [hugin-ptx] Re: In Pano13 the tilt parameters TiX, TiY, TiZ and TiS?
On Wednesday, August 10, 2022 at 5:15:33 PM UTC-4 bruno...@gmail.com wrote: > On Wed, 10 Aug 2022, 22:07 johnfi...@gmail.com, <> wrote: > >> >> I still hope this question gets a reply from someone who does know what >> those parameters are intended for and what other tools might be using them. >> > > 'Mosaic' XYZ control points are mapped onto a vertical plane that is > directly in front of the 'camera'. > > These other parameters allow different planes. The basic use is for > stitching a spherical panorama where the ground surface is a horizontal > plane, but there is parallax movement that needs to be corrected using the > usual mosaic functionality. > An example would really help, especially a runable example. I can't relate what I see in the source code to what you are saying. I also can't distinguish what you are saying from the Tpy and Tpp parameters (though it does seem like a third component should be needed to use them that way). > > In principle you can have multiple planes in a single scene. > With these parameters? Or do you mean with some feature added to the optimizer? These seem to apply to at least a whole image at a time. Part of what I was asking was whether these are logically associated with the lens as I would guess from the source code (which would mean they typically would apply across more than one image). > I have in the past wondered if (with a modified GUI) this functionality > could be used to build a hybrid photogrammetry application, where you match > control points, but also indicate which points are coplanar - this would be > very useful for architectural surveying where you are only really > interested in placing planes and the intersections between them. > >> Again, I really can't see how that is *this *(TiX etc.) functionality could be used that way. But I'm glad you mentioned that idea. I think there are more common use cases than the one you mentioned. A big part of my intent here is due to dissatisfaction (as a user) with the two basic models hugin effectively has for the parallax problem: 1) Assume there is no parallax problem (such as with no translation) or 2) Assume all CPs of an image are coplanar and if that assumption is mostly correct, that eliminates the optimization errors due to paralax, leaving only the fundamentally intractable part of the parallax problem. I really dislike that coplanar assumption for all CPs of an image and want to offer an alternative that is much more general (but has its own limitations, so it can only be an alternative, not a complete replacement method). But I do like the idea of letting the user identify a set of CPs (across multiple images for it to really be useful) that are coplanar. I don't immediately have an idea what the UI should look like. I do immediately think I know what the optimization math would look like (and I can't see any similarity to TiX etc.) It is compatible as a sub alternative to my main idea and shares the same issues (and I think solution) for changes needed in stitching (though not needed in the use case you described). There really is a fundamentally intractable part of the parallax problem. But in most cases you don't need to let that drive optimization to an incorrect result; Then after optimization is correct, you can't really stitch correctly, but I think you can stitch in a way that looks correct. Feel free to tell me I'm wrong about any of this (I often am at a stage like this). But hopefully you can do so in an informative 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/5f44a5fb-f8df-45ca-97cc-27d68bcc0b8cn%40googlegroups.com.
[hugin-ptx] Re: Easiest way to retain dynamic range?
Can you clarify some points. (I'm partially asking in case this helps someone else give you a better answer, but also because I also want to do some dynamic range things better in hugin than I currently know how to, so I think your clearer question might draw out a better answer for me). Your starting point has "great dynamic range". Does that mean the starting point has enough extra bits (beyond the basic 8 per channel) to directly represent that dynamic range? Does it mean the multiple images have many different exposures (multiple per stack and/or each appropriate to the brightness of its own content)? Or both extra bits and varying exposure? Your "output does not". What output? From doing what to the input images? And is that 8 bit or 16 bit output? How do you hope to represent high dynamic range in the final result? Do you want to stay in 16 bit (so depend on that to have enough range *and *depend on the viewing tool to convert that range usefully to display range when displaying)? Do you want to do mask adjustments to brightness after stitching (I want to and don't yet know how to put that whole work flow together) so the final image is "dishonest" in showing the brighter parts of dark areas as brighter than the darker parts of bright areas, even though the real world scene had those dark parts of bright areas brighter than bright parts of dark areas? Do you want to find a good non linear mapping from 16 bit to 8 bit (probably after stitching) to provide a more "honest" image: So brighter pixels in the true scene are consistently brighter in the result than less bright pixels from the scene? In other words global scaling to make the original dynamic range more visible in the result without being supported by the display hardware. Do you want to mainly defeat hugin's automatic exposure correction. So far as I understand, hugin generally tries to change all the images to what they would have been if they had all been taken at the same exposure. I almost never want that and don't have a good understanding of what is involved in preventing it. The boundaries become harder to deal with if that feature is disabled. Blending an overlap where the two images have different exposures of the same content and you haven't permitted an exposure correction, can cause a very ugly blend operation. But the original exposures are often different for good reason and "correcting" that is uglier than dealing with the more difficult blend. Not correcting it and successfully blending gives roughly the same kind of "dishonest" image (that I want but don't know whether you do) as the mask based final adjustment would, but unlike those doesn't even depend on 16 bits being enough to allow undoing the harm of automatic exposure correction. -- 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/a51f5190-c980-43b9-88db-c61a92cadaafn%40googlegroups.com.
[hugin-ptx] Re: In Pano13 the tilt parameters TiX, TiY, TiZ and TiS?
On Wednesday, August 10, 2022 at 3:24:57 PM UTC-4 Florian Königstein wrote: > I searched all source code files of Hugin++ for the string "tilt" (e.g. > there could be variables tilt_x, tilt_y, tilt_z like in libpano13). But > there wasn't found anything. > So Hugin probably does not use tilt. > > I don't know the meaning of it. > > But I wouldn't delete the tilt from libpano13. Hugin and libpano are > widely used software, and surely some people have made other tools that can > be used with libpano13 and Hugin. > If there are no ** very good ** reasons against it, you should keep > backward compatibility when developing Hugin++ and libpano13 / > fastPTOptimizer further. > > One possibility is adding alternate code under a different internal name, such that it can be selected by the caller, but isn't used by default. So, there would be two optimizers there, one with the original performance and features, the other with better performance, removing some features I don't understand and don't think hugin++ uses, and adding the features that I want to add. The features I want to add would also change stitching. I'm not yet even looking at what backward compatibility for that would look like (but don't expect it to be difficult). For optimization, I will need to have new and old versions coexist in one build anyway during development. Once I think the new optimization is across the board better than the old one for hugin++, that doesn't necessarily give a good reason to remove the old one from the build. I'm not sure yet, but I think a parameter based internal (to the dll) run-time selection of which is being invoked (through the same call) would be better than simply giving the new one a new name. But either is practical. I'm a big believer in extern "C" interface across exe to dll boundaries wherever practical, even if both sides are coded in C++. That solves some problems in Linux, and a far larger number of uglier problems in Windows. If I make any big change to fastPTOptimize, the new code will be all C++. I doubt that will present any problems for those building it from source (as it might have presented problems back when libpano13 was first invented). But I certainly don't want to do anything that stops a caller of all the features of the DLL from being coded entirely in C. Having a C interface to the DLL (because it is currently coded in C) is a good starting point for having a C interface because I prefer a C interface on that boundary. I still hope this question gets a reply from someone who does know what those parameters are intended for and what other tools might be using them. -- 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/f76526c9-16b7-4703-b596-15a9eeb3856dn%40googlegroups.com.
[hugin-ptx] In Pano13 the tilt parameters TiX, TiY, TiZ and TiS?
Do the Pano13 tilt parameters TiX, TiY, TiZ and TiS exist in some form in Hugin or only in libpano13? What are they tilting? Looking at the code, I can't backtrack from implementation to intent. They are effectively lens parameters, right? I am thinking in terms of a division between lens parameters and "camera?" parameters: The former is all part of the mapping between an x,y pixel position in the image and a correct yaw,pitch relative angle (direction of the obect that pixel imaged relative to the direction the camera is pointing). The latter is involved in mapping from that correct relative yaw,pitch to the true location (in some coordinate system) of that object. Computing the actual direction by combining the camera's yaw, pitch, roll with that relative yaw,pitch. Combining that with the camera's X,Y,Z location (TrX, TrY, TrZ) to compute the line of sight. *Intersecting *that line of sight with something to determine the object seen. I'm investigating rewriting parts of libpano13 for various possible benefits for hugin++. My first impulse is to leave out TiX, TiY, TiZ and TiS. But if that would be a bad idea, I hope someone will tell me why. If I don't leave them out, I'd really like to understand them better before including them. That "Intersecting" step is something I want to provide an alternate version of. The rest, I'd like to match behavior but with new code. -- 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/490292d9-8564-482e-ad23-c3adca15a85dn%40googlegroups.com.
[hugin-ptx] Re: What am I doing wrong optimizing with Hugin 2021.0.0
On Tuesday, August 9, 2022 at 1:38:07 PM UTC-4 Florian Königstein wrote: > Some time ago I tried whether analytical calculation of the partial > derivatives is better (faster convergence). I wrote code for analytical > calculation (via automatic differentiation), but it seemed that there was > no advantage (longer time and little or no reduction in the number of > iterations). > I had somehow missed the fact that the term "automatic differentiation" meants that and I thought "analytical" meant symbolic. Now that I googled it again, I see what I'm talking about is within the scope of "automatic differentiation". Of course, the devil is in the details. If you do it right, I would not expect it to be slower per iteration than finite difference in the pano13 problem space (but I won't know until I try, as it can take twice as long in some problem spaces). As you found, I also would not expect a typical reduction in number of iterations. More accurate derivatives typically provides little benefit in the common cases. Its benefit should be in reducing the number of pathological cases. But I'm more interested now in the possible speedup (per iteration) relative to finite difference (most, but not all, of which comes from assuming an average of more than one image per lens). -- 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/4e992397-48d1-43b7-a3e8-e7519cea4595n%40googlegroups.com.
[hugin-ptx] Re: What am I doing wrong optimizing with Hugin 2021.0.0
I worried this sidetrack of the discussion may be stopping someone who knows more about the answers I'm looking for from replying in this thread. I really want a better understanding of why results differ so much in the same optimization problem among version and builds of pano13 (and maybe of hugin). I half remember seeing some user option somewhere for how hard the optimizer tries before stopping. But now I can't find it in the UI or the code. Am I remembering something that wasn't there? (I have worked on a LOT of different optimizers in recent years in different projects). Or am I failing to find something that ought to be obvious? (I've been known to do that too). What makes the 2021 official version give so much worse results than the 2020 official version? To the very limited extent to which I understand lev-mar stopping rules, it might stop because it hit A: A limit in the number of iterations B: A limit in the number of function evaluations C: A limit in the rate of change of the parameter values D: A limit in the rate of change of the total error ?: There seem to be several other possibilities. The code seems to report which of those it was to the caller. I haven't yet figured out how to get any of that reported to the user. Use of sparse lev-mar, combined with the choice of where the finite-difference approximation of partial derivatives is done, greatly affects the number of function evaluations. So comparing identical versions with and without that build option (as I have) and guessing that the stopping condition is B, you would expect the build with sparse lev-mar to do more iterations for the same number of function evaluations (as long as there are 3 or more images). So sparse should get a better final answer. As long as there are 4 or more images, you would expect sparse to take less time per iteration. Above some number of images (much harder to predict and also depending on a bunch of other factors) the factor of faster per iteration should exceed the factor of more iterations, so sparse should take less total time in addition to producing a better result. In fact doing that comparison, with the current repository contents of hugin and libpano13 (not your fork of them), gives results semi consistent with all that. Sparse is much faster. Sparse gives a much smaller max value, but a slightly worse average value. Since it is a least squares problem, a much better max is a better indicator of a better solution to the optimization problem than the opposite change in average. But the absurdly large number of CP's weighs against that. Anyway, I think that result supports the guess that the stopping condition is B. For all other stopping conditions, I think the result difference with/without sparse should be smaller (with a timing difference more favorable to sparse). But I feel like I'm missing other important factors. Other differences among the various versions don't reasonably fit any guess at stopping condition or other cause. As a development aid, there ought to be a way to adjust the individual stopping conditions, primarily to raise the limit on B to understand the other differences. I think that also would be a good expert-user feature for some situations (and thought I remembered it being there). I am going into too many coding sidetracks already. But maybe I should sidetrack into finding a way to fit that user option in. Another BIG sidetrack I'll likely take: During high school in the 70's, I invented a way to compute partial derivatives other than either the finite difference or analytical. It gives more correct partial derivatives than finite difference but doesn't have the potential complexity explosion of analytical. After using it in a couple work situations years later, I took a job on a team that was already using the exact same method, and later interacted with other teams (within a big employer) that also independently came up with it. (Despite that I've never found a description of it online and don't know what it is called). On a basic timing level, for N partial derivatives, you do N+1 times as much work during one evaluation instead of N+1 times as many function evaluations for finite difference. Depending on other factors the total time might range from twice as long as finite difference down to a small fraction as long. Usually it is done for accuracy, not time. I think pano13 doesn't need that improved. But taking advantage of several images per lens in hugin would cause my method to take significantly less time than finite difference. If I do that, I should remember to kludge the counter of function evaluations to pretend it is doing N+1 times as many as it actually is, both in order to keep the stopping condition reasonable and to keep result accuracy comparable. I first wrote that in APL and later in C. But it is really ugly code in C and I won't do that again now that
[hugin-ptx] Re: What am I doing wrong optimizing with Hugin 2021.0.0
On Monday, August 8, 2022 at 3:29:44 PM UTC-4 Florian Königstein wrote: > Before I answer to your post more detailed, could you please send me the > images per Mail so that I can load the pano without the need for dummy > images. Maybe the optimization was faster for me since some CPs were > deleted due to my dummy image. Having your images I can see the speed in > exactly your configuration. > I put them on a google drive and sent you a link. If I messed that up and you can't access, ask me again. > > I just tried out a pano with only two images. The camera was rotated by an > angle of about 22 degrees between the images. I also held the camera by > hand, but translation is anyway small compared to rotation. When I optimize > only yaw, pitch and roll, the optimizer finds the yaw of about 22 degrees. > When I optimize yaw, pitch, roll, TrX, TrY, TrZ, the optimizer finds a yaw > of 6 degrees and some rather big translation. That is nonsense. This > example confirms that estimating both rotation and translation when the > translation is zero or small is very difficult. > > Do you have enough overlap and control points distributed over the overlap area to make the distinction between translation and roll possible? Are your lens parameters likely correct so that lens parameter errors are not interfering with with the optimization? If yes to both, I'd like to see those images and project to try to understand what when wrong. With a true Yaw of 22 degrees and just two images, and limiting the optimization to yaw, pitch and roll, I would certainly expect hugin to get near the correct yaw, even if it is getting a fairly poor fit. If the overlap and CPs aren't very good, then it is also understandable that a better fit for the CPs could give a wildly wrong actual result, including a wildly wrong yaw. But that doesn't make the general case against optimizing all 6 basic camera point of view parameters. With multi-way overlap (as in the group of photos I sent) misinterpreting yaw for TrX in one limited overlap tends to be forced out of the solution by the circular interconnection of those two through other images. I don't EVER get as good results from hugin or hugin++ as I think I ought to. That was the original reason I started working on the code, though I delayed a long time before recently digging into the optimization. So I don't want to pre judge whether the two photo problem you just described is a fundamental limitation due to low CP overlap vs. hugin not really doing what it should. But I am confident that in the cases with more overlap (including virtual overlap through other connection routes) there is no basic flaw in optimizing all six of those camera point of view parameters. -- 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/e6a08dbf-5613-48fb-b900-86e26813732cn%40googlegroups.com.
[hugin-ptx] Re: What am I doing wrong optimizing with Hugin 2021.0.0
On Monday, August 8, 2022 at 11:32:07 AM UTC-4 Florian Königstein wrote: > Hi John, > > Optimization ran fast for me, > What is "fast" and which hugin did you use? It runs "fast" (17 to 36 seconds) using any build of pano13 with sparse lev-mar. But I still want it to be faster and I want much bigger examples (even though I don't currently have any) to also be fast. With one exception, it runs "slow" (85 to 212 seconds) in any build without sparse lev-mar. That is exactly as I'd expect and I'm not much interested in those. The exception I asked about was: 2021.0.0.52df0f76c700 built by Thomas I'm pretty sure that does not have sparse lev-mar. It optimizes in 21 seconds producing garbage results (large average, 158 worst case). The worst CP is not a poorly chosen CP. All the other versions have worst CP 30 to 38. My question was why that build is so fast and bad. The fact that the average can be below 3 and the worst 30 means I want to be able to do that well regularly. So I have the second issue of why fastPTO does slightly worse. It should simply be faster, not a tradeoff of much faster for slightly worse. But that is too complicated and detailed for me to want to ask here. I'll need to figure it out myself. But why the official hugin build is so much faster and worse than it should be seemed like somethings others might weigh in on. First I assume: > ** You took the images in a "standard way", i.e. by rotating the camera > around a tripod or panoramic head. > No. I did not set up my tripod for that one. I hand held as carefully as I could and came pretty close. So I certainly needed to optimize the six basic parameters of camera position as well as one lens parameter. > ** You just want so see how the optimizer works when you select nearly all > variables to be optimized. > I avoided opening the FOV can of worms. The correct FOV is known and using incorrect FOV as a coverup for other issues is one of my frequent tools, but not a valid tool either for this panorama or for this performance test. Some other parameters are in there mainly for "maybe they help" in addition to performance testing purposes. The problem is that you select both rotation and translation to be > optimized. Normally, you should only optimize for yaw, pitch and roll, but > not for trannslations - if you rotated the cammera but didn't perform > bigger translations. > Instead if you kept the orientation of the camera the same and translated > it for the different photos, then you should optimize for translations, but > not for yaw, pitch and roll. > I certainly needed all six of those. Otherwise, the panorama is garbage. I did my best to hand hold the camera varying only Yaw and Pitch, not Roll, TrX, TrY, and TrZ. But I didn't do that well enough. Tr value are tiny compared to the physical distance to nearest CP but they still matter. I haven't yet taken any mural shots, so varying translation without also Yaw is not in any of my examples. > > The reason is the following: > Suppose you have a FOV that is not big (like you have). Imagine first you > rotate the camera a bit horizontally. Then you rotate it back to the > original position and trannslate it a bit horizontally. If the amout of > rotation and translation have an appropriate ratio, then the control points > will move in a similar way (not much difference) in the image both by > rotation and by translation. So the optimizer cannot decide whether you > rotated or translated the camera. > There is enough difference. If the real world location of the CPs in an image are relatively co planar (with each other) then optimization should be able to distinguish rotation from translation. I have refined my ideas (but not yet written code) for handling the case that the real world CPs are not actually co planar. I think I will then do vastly better than 3 average and 30 worst case in this example. But before coding that, I want a somewhat better understanding, and maybe do a cleaner re-coding, of what is already there. In some cases you can determine both rotation and translation of the > camera, but these cases are usually not relevant for panorama photography: > Assume for simplicity you have an ideal (pinhole) camera (no lens > distortion). Assume you have 5 (or better 8) points in 3D space that will > get control points in the photos. You take two photos of these points by > both rotating and translating the camera between these photos. Then there > are mathematical algorithms with that you can determine both the relative > rotation and the relative translation of the camera. But there are at least > two cases in that the algorithms fail or yield bad results (big errors): > 1. There is no or little translation in the camera position between the > two photos > That is the area in which my current ideas are least solid: Hugin is already good for where all the cameras have little of no
[hugin-ptx] Re: Definitions of axes and direction?
Despite trying to be careful in testing and organizing the above, I seem to have made a big mistake on the Z axis. My testing actually shows Hugin's TiX, TiY and TiZ are not a right handed coordinate system. Then I missed that fact in reporting those results. Maybe my test was wrong. The direction of Roll that I measured is negative (or left handed) on the direction of TiZ that I measured. -- 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/2ec86e38-e0a2-427a-bbfa-cd7ccddefffdn%40googlegroups.com.
[hugin-ptx] Definitions of axes and direction?
Is there a place in the hugin documentation that explains the axes and directions hugin uses? Both as a user and as a developer, this is a topic I have repeatedly needed, looked for, failed to find, experimented and learned, and then forgotten. Until I recently finally took notes. I primarily care about the six parameters of the camera's point of view: Yaw, Pitch, Roll, TiX, TiY, and TiZ. But other parameters likely also clearer definition of direction. I think of those as all describing both the motion of the camera in moving it from a hypothetical centered position to its actual position* and* the motion of individual pixels as they are moved from their positions in an input image to their positions in the output image (those two are the same direction of motion). The opposite direction (from output position to input position) is an equally valid set of definitions, but I like those less. As best as I can tell by experimenting: Hugin's X axis points right Hugin's Y axis points down Hugin's Z axis points back (positive values behind the observer) Hugin's Yaw is a positive rotation "on" the Y axis Hugin's Pitch is a positive rotation "on" the X axis Hugin's Roll is a positive rotation "on" the Z axis I am using the right hand rule for "positive" agreeing with every online site I have read on this topic: On your right hand, point your thumb in the direction an axis points (direction of higher values of that coordinate); curve your fingers so they indicate a direction circularly around the direction your thumb points; that is the positive rotation direction. There is no similar agreement on whether that is clockwise or counter-clockwise: Most sites think positive is counter-clockwise as most assume (and few state) that the axis is pointed *at* the viewer who sees counter-clockwise (as your thumb would if you point that right-hand-rule axis at yourself and see your fingers curved counter-clockwise). Fewer, but still quite a large number see that as clockwise because they have the viewer looking in the same direction that the axis points. Most online sites defining Yaw, Pitch and Roll, say those are on the Z, Y and X axes respectively, making hugin's choice of Y, X and Z important to document (unless I somehow got this wrong). Hugin's choice of rightward, downward and backward for X,Y,Z is also unusual, but there doesn't see to be any "usual". I expect we all learned rightward, forward and upward in basic math classes, but serious online discussions don't typically follow any standard other than right hand. All the sites (and apparently hugin as well) agree that the sequence is Yaw then Pitch then Roll for "intrinsic" rotation which is mathematically the same as "extrinsic" rotation in the sequence Roll, then Pitch, then Yaw. Intrinsic rotation is what I think of for camera motion: 1) Rotate on Y 2) Rotate on X' (where X' is the camera's X axis after its rotation on Z) 3) Rotate on Z'' (where Z'' is the camera's Z axis after both its earlier rotations) Extrinsic rotation is what I think of as the motion of a pixel from input to output: 1) Rotate on the global Z axis 2) Rotate on the global X axis 3) Rotate on the global Y axis I would appreciate: A: Pointer to where this was already all documented and I wasted your time re-documenting it (but the exercise helped me cement it in my mind to help my future use and enhancement of hugin++) B: Corrections. What did I get backwards or seriously wrong? C: Comments. Such as are there simpler ways to be precise about these things. D: Similar info on parameters other than these six. -- 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/44ba8ca3-d1f0-4d49-81d1-549b95938da6n%40googlegroups.com.
Re: [hugin-ptx] Re: setting the output to high dynamic range
On Monday, August 1, 2022 at 5:44:47 PM UTC-4 GnomeNomad wrote: > > > I have panoramas that were about 2GB as 16-bit TIFFs that became about > 600-700MB as 100% quality JPGs. So what quality setting are your JPGs at > to give you a 15x difference? > My results are somewhere between those. I guess 100% quality JPGs cost a lot of space. I don't know what the Sony alpha 7 III's "extra fine" quality for JPG means (in more portable terminology). My 4Kx6K photos are 17.5 to 18.8 Mb as JPGs produced by the camera and are always 145,449,341 bytes as tif files produced by conversion programs from the arw. So that is about an 8 to 1 difference. The tif file holds a 144,000,000 byte image plus various metadata. The jpg represents half that much data, apparently getting 4 to 1 compression without any visible loss of quality. I rarely have blown highlights. I avoid shooting that way because I assume it would be harder to fix. So the problems are at the opposite end. Some sections are too dark and I typically hope to mask and selectively brighten after stitching. The jpg version is always slightly lacking in content in the dark areas, so I would need a separate shot with intentionally blown highlights if I were working just with jpg (and then my expertise as a hugin user is lacking for the problem). Working from raw, the dark areas areas are sometimes far better than in the jpg copy and no second shot would be needed. But when I'm not using a tripod (so getting a decent second shot is harder) tends to be when the raw is too noisy in dark areas and thus worse than the 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/bad73536-f32e-461a-94ca-8c00b3c9c890n%40googlegroups.com.
[hugin-ptx] Re: setting the output to high dynamic range
On Monday, July 4, 2022 at 2:51:54 PM UTC-4 mpgve...@gmail.com wrote: > i do not understand where i can enter those command, i did not see a teminal field in the gui and windows command prompt says it does not know nona. You use some form of windows command prompt and you do something to fix the PATH to include the directory where nona.exe etc. are installed. There are various ways to create an icon and/or a right click menu choice that will open all that easily from then on (vs typing the command to change the PATH each time you start a cmd prompt to work on this). You could also use control panel to permanently change PATH so Hugin related exe's are always on your path. I use my computer for too many different things and hate PATH pollution, so I wouldn't do that myself. But if using Hugin is a significant fraction of the purpose of the whole computer, then including it in the permanent PATH is the simpler choice. There are multiple (better) alternatives to the basic cmd prompt and multiple ways to set up each to have a customized launch for specific purpose. So too many choices: which usually means just do it some simple obvious way while knowing that if it is worth trouble to make it better, you can. On Monday, August 1, 2022 at 1:06:37 PM UTC-4 mpgve...@gmail.com wrote: > > and i must say, the tiff has more contrast and looks a bit sharper, but > That is a sub-topic I'd really like to understand, since I'm fighting many situations in which the tiff is very fuzzy compared to jpg. I have seen about as many situations in which the colors look better when viewing a tiff vs. jpg as the opposite. Each viewer has its own rules for the non linear translation from 16 bit intensities to 8 bit intensity for display on your monitor. They don't seem to be just throwing away the low bits. Depending on the photo and the viewer, that mapping can make the picture look much better, including increasing the contrast between two colors that are adjacent and look better with more contrast. A big advantage of working in 16 bits is the ability to adjust the final mapping to 8 bit AFTER stitching. Maybe that is all you mean by "more contrast" and "sharper". It might also be possible that the jpg compression is actually blurring edges etc compared to raw. But that is opposite to my own experience (thus a subject I'd like to be told more about). it is 15x the file size and since i want to use it for batches it is a > bit too much. > Disk space is cheap. So while I have some similar objections myself to keeping around lots of tiff files, I think my own use pattern is odd and most other people should not care about that waste of disk space. Am I missing something? Maybe that is another subtopic I'd appreciate having explained. so then i thought maybe i can get a bit more out of the jpg by using > high dynamic range. > > but unfortunately all but > exposure corrected, low dynamic range > is alvailable. > I hope one of the experts explains some of that here. I have never had any decent mental model (despite rereading Hugin documentation many times) of what high vs. low dynamic range actually means as a concept in Hugin's processing. Of course, I understand what it in photography, but that doesn't tell me what selecting it in Hugin actually causes Hugin to do differently. -- 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/73c1cdd9-da58-4815-ba81-3aed04a96d77n%40googlegroups.com.
Re: [hugin-ptx] Re: Hugin++ direct reading of ARW (raw) files
On Monday, August 1, 2022 at 6:54:46 AM UTC-4 davi...@gmail.com wrote: > > > Where the camera has an advantage is that it knows precisely how the > sensor behaves, when and where it will create the most noise and what kind > of noise, maybe even detect different kinds of surfaces and apply different > noise reduction settings on different parts of a photo in order to preserve > more details when possible. But of course this all relies on the camera's > "AI" (I am not sure the word "AI" really applies here), the AI could guess > incorrectly, and the user could achieve a better result with enough > experience and time. > > I wish I understood this stuff better. What (if any) part of the jpg looking better is due to the lossy compression of jpg actually improving quality? Areas that should be smooth in color are smooth in jpg, but grainy looking when converting arw to tiff. Edges that are sharp in jpg are fuzzy when converting arw to tiff. The arw format as produced by my alpha 7 III camera is a fairly stupid lossy compression, using 8 bits per pixel. It carries much better information than a simple 8 bits per pixel, but much less information than uncompressed would have. Clearly, it had at least 11 bits per pixel (maybe more) before the lame compression. I'd far rather have pictures take twice the space and not lose that. But I'm pretty sure the alpha 7 has no such option. Likely the interpolation and noise reduction creating the image that feeds the jpg compression has the original (at least 11 bit per pixel) data, rather than the reconstruction of that data after lossy compression. Maybe there is nothing one can do to the arw file that gets the interpolation and noise elimination as good as in the jpg, because you don't have the original data. So you have a tradeoff of which information to lose when choosing jpg vs. arw, not an option to keep the maximum. Sony's website tells you to use the ImagingEdge software they distribute to convert arw to tiff. That does a slightly worse job than RawTherapee. If knowledge of the characteristics of the sensor were the major difference, then ImagingEdge ought to do a better job. For a tripod shot of a stationary target, the extra detail in dark areas in the arw format is such an advantage over jpg that arw is is clearly better. For faster exposure, especially with a narrow aperture to increase depth of focus (forcing higher ISO), the garbage in the darker areas of the tiff outweigh the extra detail and the jpg is much better. The exposure bracketing feature of this camera is garbage, so it is generally not the answer. If I was just doing the images from tripod with decent lighting, even my own calls to libraw, that do a generally worse job than ImagingEdge, would be usable and better than just using the jpg. I also don't know what is lost (or gained) by delaying some of that processing until after stitching. Since I don't know the concepts behind either better interpolation or noise reduction, I really have no clue what info is lost by delaying. The gains might be more obvious: Where stitching is making automatic decisions based on which image has an area of overlap "better", the noise reduction etc. is more likely to misguide it, vs choose the better before correcting. Where the user must intervene to guide the process (such as in applying a different tone mapping by mask to different parts of the image) it may be much less work and avoid wasted effort if done after stitching. -- 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/f988ccae-9846-416a-8356-488db5d32561n%40googlegroups.com.
Re: [hugin-ptx] Re: Hugin++ direct reading of ARW (raw) files
On Sunday, July 31, 2022 at 2:49:59 PM UTC-4 irthoma...@gmail.com wrote: > I see, thank you for the detailed reply. Does that mean that you are > working with jpg files? I haven't dug into the code. Why not just use some > temporary folder for the tiffs, and erase them when finished? > > I never think I'm "finished". I haven't yet gotten a single panorama as correct as it looks like it could have been. So they are all sitting around waiting for me to try some improvement either to Hugin itself or to my skill at using hugin. I do work mainly with the jpg files. The fact that RawTherapee (at least on default settings) doesn't do the noise reduction and interpolation as well as the camera does itself, combines with the inconvenience of keeping the temp files around. In other cases, the jpg has lost too much detail in the darker sections (because 8 bits just isn't enough) so pre-converting to tiff is necessary. -- 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/f7880a4b-cce4-4398-98f0-adc585c9b682n%40googlegroups.com.
Re: [hugin-ptx] Hugin stitching aerial images
On Monday, July 25, 2022 at 2:29:46 AM UTC-4 koga...@gmail.com wrote: > I have been wanting to stitch aerial images for a long time but never > succeeded. But I guess it's not possible to stitch them because of parallax > mistakes in the pictures. I would expect aerial images of mountains would be impossible to stitch correctly because of parallax problems. But if the surface photographed is relatively flat (vs. the altitude from which it is photographed) there should be a correct way to stitch. Someone who understands Hugin's stitching better than I do my correct me on this, but so far as I understand: When the camera position is moved between images, you need some model of the target surface in order to remap the images. Hugin can model the target as a flat surface at an arbitrary angle relative to its viewing angle from the camera position. Given a decent collection of control points, optimization can find the position of the camera and the viewing angle of the camera (yaw, pitch and roll) AND also compute the angle of the target surface. If the altitude of the camera is great enough relative to the surface texture, that computation should remove parallax issues. -- 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/20ab8481-13cf-4c65-b089-6f5d77923dcan%40googlegroups.com.
[hugin-ptx] Re: [BUG] Segfault with unset
In case this wasn't obvious and implied by your post, the error in the code is exactly where the seg fault occurs: hugin/src/hugin-2021.0.0/src/hugin_base/hugin_utils/utils.cpp:475 475 if (strlen(xdgDataDir) == 0) Seg faults often indicate a bug in a distant place, that may be hard to identify from the location of the seg fault. But not this time. The coding error is right there and obvious. The part I don't know enough about is the hugin build time option: USE_XDG_DIRS I don't know which official builds of hugin have that defined (the Fedora build I'm using doesn't). As you discovered, if hugin is built with that build time option, but the environment variable that depends on is not present, then it crashes. The line of code you identified is clearly intended to check for lack of that environment variable (to fall back on alternate behavior) but checks incorrectly. -- 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/819f98dc-1003-4d47-82fa-0b60c2d3d724n%40googlegroups.com.
[hugin-ptx] Hugin++ Equalize (to make details more visible for masks and CPs)
I added an experimental Equalize option to a branch of Hugin++ I would appreciate any feedback from those trying it and/or looking at the source code and/or knowing more on the theory side than I do (which wouldn't take much). The idea is to modify the individual brightness levels monotonically (but often not smoothly) to get a flat histogram, which should tend to make image details more visible. This only affects what you see while constructing the panorama. It does not affect the pixels going into the result. In the current experimental version, it only applies to input images with 16 bit integer values (not to 8 bit and not to float). I think it is most useful for 16 bit, but has some value for other input types. Before making it non "experimental" I would extend it to all input types. It currently occurs during the translation from 16 bit to 8 bit (needed to get an image that can be displayed in the GUI). My intent is to affect only that GUI display. But I haven't yet tracked all the possible call paths to find/fix any possible other affects. The setting is per image and currently lasts only during a session. It ought to be saved in the .pto file. But I want to be surer about what I'm doing before messing with the .pto file format. I put the UI for controlling it in the mask tab, because it is significantly more convenient there than elsewhere (try it and that should be clear) even though logically it is a property of the image, not the masks and it affects CP editing at least as much as mask editing. [image: eq.JPG] It has 3 different modes (other than the default choice of Off). Stable has very little impact on hue or saturation and tries to adjust just intensity. It scales each pixel as a single object (scales g,r,b equally within one pixel). It may clip (decrease saturation, shifting hue) for pixels relatively close to white in photos that have very few pixels that are really close to white. Intermediate treats all values independently in one pool. Its affect on saturation and hue depends heavily on the original distribution. It typically distorts hue more than stable does, but that still usually isn't very much. Distorted treats each channel independently. This usually causes big shifts in hue, making the picture look weird. But it also should give the largest improvement in the ability to see 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/e8477762-602b-40c7-9023-9b0096d4e905n%40googlegroups.com.
[hugin-ptx] Hugin++ direct reading of ARW (raw) files
I made a fork of vigra, plus a tiny change to hugin++ so that hugin++ can directly use ARW files rather than first converting them to TIFF. Very little extra would be needed to support other formats supported by libraw. I strongly dislike the directory clutter of the current hugin method of dealing with raw files (convert to tiff and then use the tiff file in the hugin project). I keep hugin projects around a long time while experimenting with ways of doing things a little better. I don't want to keep the tiff files. This hugin++ change is tiny and clean. It just prioritizes vigra over raw conversion for extensions that are in both lists. If you use the standard vigra with hugin++ that change makes zero difference and you don't need libraw. This hugin++ change only makes a difference if you use my fork of vigra, which uses (and requires) libraw. My changes to vigra are quite ugly. Apologies in advance to anyone trying to build it (but I'll provide whatever support I can and answer any questions and *appreciate any suggestions* on doing any of that better). My lack of cmake knowledge made that part of the changes (getting the vigra build to find/use libraw) especially bad. The Windows/Mingw64 build is working for me, as is the Fedora build. I'm happy to zip up and share all the required mingw64 binaries if someone else wants to test this on windows. There is no .dll compatibility for any C++ symbols between visual C++ and mingw64, so you either need 100% visual C++ or 100% mingw64. For visual C++, I could only answer questions, not provide any binaries. At some point I'll learn how the windows hugin binary distribution creation process works and post an installer (for the mingw64 binary version) on the hugin++ site. So far no one has asked for that. For fedora, I think building hugin++ and my fork of vigra from the repositories (and getting libraw and all other dependencies the normal way) would be easier than getting any binaries from me. But ask me for help if you want to test this and have some problem. I'm still working on several aspects of this. I think it is ready for other to try. I don't think it is yet ready for anyone to rely on. I would appreciate any feedback. Relevant repositories are: https://sourceforge.net/projects/vigraraw/ which is my fork of: https://github.com/ukoethe/vigra https://sourceforge.net/projects/huginplusplus/ https://github.com/LibRaw -- 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/78b467d4-52a1-4bb9-872f-8822179e9108n%40googlegroups.com.
[hugin-ptx] Re: Screenshots: "No or only partial information about field of view"
On Wednesday, May 25, 2022 at 9:17:01 AM UTC-4 raywood wrote: > > Please enter the horizontal field of view (HFOV) or the focal length and > crop factor. > > I'm not sure what those values would be. > > What's the best way to use Hugin with screenshots? > A Panorama in the real world represents a curved surface. The HFOV is important in managing that. You want a panorama of a flat surface. I don't know if there is a better way, but specifying a very small HFOV should eliminate almost all of the curvature from the computed surface. Additionally, you want to stitch a "mosaic" (the position of the point of view changes, rather than the angles), so when you "optimize" (compute image relative positions to fit control points) you want to work primarily (or maybe entirely) with "translation" X and Y, rather than the yaw and pitch that are used for ordinary panoramas. I never use the Simple interface, so I don't recall how you select optimize on just translation X and Y in that interface. It is quite obvious in the expert interface. -- 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/62b11025-a4a3-4af2-ba36-b9882bdd0ca8n%40googlegroups.com.
[hugin-ptx] Precise meaning of control point coordinates?
Control points coordinates allow fractions of a pixel (1/3 pixel at a time when moving via arrow keys. Even finer detail for "fine tuning" results). What is the precise meaning of the coordinate relative to the pixel? Imagine each pixel as a square in a very magnified image. I would expect best behavior if that pixel's integer coordinates represented the center of that pixel. But maybe some code would be simpler if the pixel's exact coordinates represented the top left corner of that pixel (its coordinates plus 0.5,0.5 would be its center). I'm pretty sure various parts of of the hugin code are inconsistent with each other regarding that decision (following neither of the above rules and differently from other sections of the hugin code). I'm working on some enhancements to hugin++, that I can only code correctly if I know the precise answer to this question. So I looked for it in the current code and experimentally in the current behavior and found contradictions. I'd like to know which parts are following the intended behavior, vs which are subtle bugs. -- 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/6678b982-33fe-427d-b720-a5c29bb7c546n%40googlegroups.com.
[hugin-ptx] Re: libpano13 patch for missing ExtraSamples TIFF metadata
On Friday, May 13, 2022 at 2:37:51 AM UTC-4 kevin@gmail.com wrote: > I couldn't figure out where libpano13's authoritative source repository > is, or how to submit a pull request or equivalent, so I've attached the > patch against libpano13 v2.9.21 here. > The project is here: https://sourceforge.net/projects/panotools/ Under the "mercurial" tab that page links to https://sourceforge.net/p/panotools/libpano13/ci/default/tree/ That page lets you browse the code and it gives the command for cloning the repository: hg clone http://hg.code.sf.net/p/panotools/libpano13 panotools-libpano13 I don't know how to submit a pull request. But you asked in the right place and I expect the maintainers will either accept the patch you posted or give instructions. If someone silently applies your patch (without replying here) the above links will let you see that. I am one of two maintainers of a fork of libpano13. I'll wait at least a few days for action in the official version and then examine your patch for inclusion in the fork. -- 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/069e39d0-2a92-46ff-a17a-feb31ccc1b33n%40googlegroups.com.
Re: [hugin-ptx] Re: HUGIN install
I received an email with more info on this failure. I thought I had the right tools to translate the addresses for the official hugin build. But it appears I don't. I expect someone with a proper windows build environment for hugin can. The important part of the XML file seems to be: "Windows 10 (build 22000), 64-bit edition" ... ... -- 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/1e767a41-c045-4539-9809-2689ea55e1d2n%40googlegroups.com.
[hugin-ptx] Re: Compile error while building hugin++
When building hugin++ you need to use FastPTOptimizer instead of libpano13. https://sourceforge.net/projects/fastptoptimizer/ Your error message doesn't match the error I got when I used the original libpano13 for hugin++, but your error is the kind of error I would expect for that, so I think that is your problem. If that is not correct, tell me and I will look into it further. -- 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/c0426b90-8307-4ee7-a91e-c63c9d16a36bn%40googlegroups.com.
[hugin-ptx] Re: Several glitches in the display of CP labels and magnifier
On Sunday, April 17, 2022 at 1:03:09 PM UTC-4 Florian Königstein wrote: > > When you will have merged it, I can create new Windows binaries. > In case you (or anyone else) wants to try them, I have Windows binaries. My build method (MINGW64) is different in the layer (not sure what it is properly called) above ABI but below API (of the DLL interface). So the DLLs I build work with the EXEs I build but the DLLs I build don't work with the EXE built the way you build and vice versa. So anyone trying my version needs install location my whole set of DLLs and EXEs with location and path distinct from the ordinary install of Hugin or Hugin++ I never tried building the installer (I just use all the files where they get built). But I'm sure I can figure out how to build it if you want to be able to compare builds or if someone else prefers the MING64 build. -- 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/8340f5ea-69c3-4049-a3ec-5f07641aa652n%40googlegroups.com.
[hugin-ptx] Re: Several glitches in the display of CP labels and magnifier
On Sunday, April 17, 2022 at 10:32:12 AM UTC-4 Florian Königstein wrote: > > At the moment I cannot see when the "jump around" in the old version > occurs. What I see (in both versions) is that when scrolling via scrollbar > so that a CP gets out of view and then scrolling back FAST, sometimes there > are parts of the magnifier left at false positions. It seems that the view > in not updated correctly. > I think that means you are using the default branch of hugin++, not the "ImproveCPDisplay" branch. I got busy with non Hugin activities and did not merge my changes into default. The big merge I did to default of Hugin++ (right before getting too busy) was a bunch of changes Thomas did. I did not merge the April 9 changes Thomas did, because two of those are badly done mitigations of the problems described in this thread (that were fixed well, I think, in my branch). Thomas's changes do make the problems much less likely in normal use, but don't fundamentally fix anything, and with a slow CPU (I used my wife's laptop) still have most of the original problems. I still hope to find time soon to merge "ImproveCPDisplay" to default. But both in the old and in your version the label of a CP sometimes seems > to overlaps the magnifier. > When there is no way to not overlap, it always will. But ... > E.g. move the lower scrollbar left so that the magnifier gets right out of > the visible area and then move right again. Then the CP gets visible again, > now the label overlapping the magnifier. I hope I really have your latest > code version (I'll write you per Mail). > That was fixed in "ImproveCPDisplay". You probably should wait until after I merge, unless you are really curious. > There is also a more serious bug, Windows only, that I fixed earlier in >> the same branch: With the mouse over the image press and hold shift then >> move the mouse (don't press a mouse button). Both images are supposed to >> move with the mouse, and actually do so if very few CPs connect them. If >> many CPs connect them (whether they are in the visible portion or not) then >> the images just jump around a bit with little if any net movement. How >> many CPs that takes depends on CPU speed and details of your display, but >> it is not likely to take any unreasonably large number. >> > > I can confirm that scrolling while pressing SHIFT is now much better (not > jumping around wildly). > I was misremembering when I typed "same branch". I fixed that earlier in default before the branch, so that correction is included whether you get the branch or not. -- 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/c5f9da93-e3d7-4499-ac58-ab08c2f616f7n%40googlegroups.com.
Re: [hugin-ptx] How to delete masks using command line ?
On Thursday, April 14, 2022 at 6:25:53 AM UTC-4 Noveguy wrote: > Thank Bruno for the tip. Unfortunately, I am using Windows now. But I > think I could write some C# code to do that. There are many different sources for linux tools (with or without including and depending on a copy of bash) that you can install on Windows. I'm guessing your "now" meant you have some previous Linux experience, which is even more reason to install some linux tools on Windows. This won't be the last time that you will have a use for grep on windows. -- 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/dc4d42a4-da5e-407a-911d-2b05550b9e93n%40googlegroups.com.
[hugin-ptx] Several glitches in the display of CP labels and magnifier
You might want to jump down to the "TESTING" section below before reading all this concept level content: In a branch of the Hugin++ fork of Hugin, I fixed a bunch of minor bugs that Hugin has display of CP labels and magnifier. After I do some other related enhancements and corrections, all that will be merged into the main branch of Hugin++, but I doubt it will ever get merged into Hugin. I'm writing this because of a few questions I'm curious about, including whether other Hugin users are bothered by these glitches (which bother me enough as a Hugin that I took the time to fix them. But I'm not a typical user). Also some of the glitches are Windows specific for reasons I understand, while many others also occur on my Windows system, but not on my Fedora system, but I can't tell whether the difference is due to Windows vs. Linux or is due to the obsolete WxWidgets I'm forced to use on Linux (due to an obsolete video driver I need for an obsolete display card). So if someone tests any of this on Linux with up-to-date WxWidgets, I'd like to know whether those bugs appear. A big part of the issue is related to a behavior that I decided to eliminate, because it would be very hard to get exactly right and because I didn't like it anyway: In Hugin, the positions of CP labels and magnifier are adjusted based on the edges of the visible portion of the scrolled image. In my version, those positions are set based only on the edges of the whole image. So a CP that is near the edge of the visible portion but not near that edge of the whole image might have its label or even magnifier off screen. I think it is perfectly reasonable and expected for those to be off screen: If the CP's you cared about were that near the visible edge without being near the whole image edge, you would have scrolled to fix that. Any opinions on that? In Hugin, the labels visibly jump around at unexpected moments for non obvious reasons because of the many flaws in the code for adjusting based on visible region. So eliminating that feature eliminates that distracting behavior. That was very frequent in Windows and happened, but less, in Linux. But also (maybe Windows only) those jumps interacted with race conditions in the use of WxWidgets, so you could have half the label stay in one position while the other half jumps to a new position. In Hugin there was code to avoid having the label overlap the magnifier except when you are so close to a corner as to have no choice. But that code was mostly wrong, so the overlap often occurs when the point is close to an edge but not close to a corner, so the overlap is unnecessary. I believe my version fixes that (overlaps only when there isa no choice). Another part of the same Hugin bug loses the label entirely for a CP very near the top left corner of the whole image. Another part incorrectly decides a 3 digit label (more than 100 CPs connecting two images) doesn't fit near the top or bottom edge, when actually it does fit. TESTING: Select a CP, then use the scroll bars to slide that CP out of view then back into view, being careful to keep the mouse on the slidebar and/or outside the image window (not over the image). On Windows, various different glitches occur depending on the speed at which you scroll to bring it back into view (and also varying based on which of the four edges it was temporarily off of). When you then move the mouse onto the image, it redisplays, fixing whatever glitches were visible, but also moving labels, which I find annoying. There is also a more serious bug, Windows only, that I fixed earlier in the same branch: With the mouse over the image press and hold shift then move the mouse (don't press a mouse button). Both images are supposed to move with the mouse, and actually do so if very few CPs connect them. If many CPs connect them (whether they are in the visible portion or not) then the images just jump around a bit with little if any net movement. How many CPs that takes depends on CPU speed and details of your display, but it is not likely to take any unreasonably large number. If you get and build my branch, it may be interesting to compare (hugin vs. my branch) for the behavior of CPs near the edges and corners of the whole image. That shows lots of subtle wrong behaviors in Hugin that fixed (but only bothered to fix because that was related to the more commonly seen glitches). I can provide Windows binaries of Hugin++, but it is enough effort to package those, that I won't do so unless asked. Providing Fedora binaries would be harder and there would be much less point. Building Hugin++ in Fedora from source code should not be difficult (Bruno answered my questions, making that easy. I will "pay that forward" if anyone needs any answers for making that easy. The wiki is obsolete, so you need different -dev packages installed than it says, but if you are just a bit
[hugin-ptx] Re: Building hugin etc. on Windows in MSYS2 mingw64
On Monday, March 14, 2022 at 9:17:34 PM UTC-4 johnfi...@gmail.com wrote: > > Reviewing it, I now understand > > Actually, I was even more wrong that time. I'm gradually understanding more about this problem, but still don't know the basic cause. When wxUSE_TASKBARBUTTON is defined as 0, you can't use those classes. But why that symbol is defined as 0 in msys2/mingw64, I don't understand. For now, I think the right answer is to test that symbol before using those classes. -- 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/f6a7344d-33b3-48a2-b2be-f86e7e1d87c1n%40googlegroups.com.
[hugin-ptx] Re: Building hugin etc. on Windows in MSYS2 mingw64
src/hugin1/hugin/huginApp.cpp:382:5: error: 'wxTaskBarJumpList' was not declared in this scope src/hugin1/ptbatcher/BatchFrame.cpp:1291:9: error: 'wxTaskBarButton' was not declared in this scope I seriously misunderstood the situation when I kludged past the above problem earlier. Reviewing it, I now understand those two hugin files are including the wrong variant of taskbarbutton.h There is one in wx-3.1/wx/ and another in wx-3.1/wx/msw There are other .h files that similarly have those two variants and for those .h files other hugin source files correctly decide to use wx/msw instead of wx/ during this build. I don't yet understand why this isn't a problem for everyone building hugin in Windows. Obviously it is not that common a problem. But I don't yet see a reason that it would be specific to msys2. I'll research it more some other time, unless someone answers this before then. -- 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/b9bd06a5-4d52-4c5a-a8db-069e8a4b32c3n%40googlegroups.com.
[hugin-ptx] Re: libpano13: INLINE problem
On Friday, March 11, 2022 at 3:46:32 PM UTC-5 johnfi...@gmail.com wrote: > > Are the functions float2rgbe and rgbe2float supposed to be exposed to > clients of libpano13? Or are they purely internal? Currently in Linux (at > least the Fedora package and my own builds in Fedora) they are not > exposed. But I don't know if they were meant to be. In fact they are not > even exposed to the rest of libpano13 outside of rgbe.c, despite being > declared in rgbe.h as if they were meant to be exposed. > > I see that Thomas fixed this problem today in a way that clarifies the intent that these two functions are not exposed outside rgbe.c -- 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/d89eeab4-a13f-40bb-9ba0-85e6a8077dben%40googlegroups.com.
[hugin-ptx] libpano13: INLINE problem
Due to the way inline works in c in gcc, I got errors building a debug build of libpano13 in fedora. I know several different ways to fix the problem. But I don't know enough about all the ways libpano13 might be built and/or used to have a safe opinion on which way is best. Despite reading many results of google searches and official gcc descriptions, I still can't understand the general rules for inline in gcc c (which are very different from c++ rules). But I do understand this example of the use of inline and why it is wrong. Some questions: Has anyone else built libpano13 debug in Linux? Did you need to work around the problem described below? If so, how? If not, do you have an idea of why it worked for you and not for me? Are the functions float2rgbe and rgbe2float supposed to be exposed to clients of libpano13? Or are they purely internal? Currently in Linux (at least the Fedora package and my own builds in Fedora) they are not exposed. But I don't know if they were meant to be. In fact they are not even exposed to the rest of libpano13 outside of rgbe.c, despite being declared in rgbe.h as if they were meant to be exposed. As currently declared/defined they are never instantiated as individual functions. They might be inlined wherever used within rgbe.c or they might be undefined. That is entirely a free choice of the optimizer, except at lowest optimization level, where they are necessarily undefined. My current work around: I added __attribute__((always_inline)) to the end of line 41 of pt_stdint.h (which is already inside a conditional excluding MSC). That further entrenches the current behavior that c functions using the INLINE macro are not ever usable outside translation units that define them, while it fixes the undefines for unoptimized builds. It forces functions defined that way to be inlined even in the debug build. -- 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/c51701bf-b0a0-4f89-ac91-6374b5c3afdcn%40googlegroups.com.
Re: [hugin-ptx] Nokia 6.1
On Wednesday, March 9, 2022 at 11:17:29 AM UTC-5 comp...@gmail.com wrote: > > Here is my guess as to, “What does calibration offer?” > I think calibration identifies the corrective factors needed to remove or > minimize pincushion/barrel and perspective distortion. > I’m guessing that Hugin can produce a better panorama when it can correct > each image for these distortions before assembly. > I think the relevant comparison is between correcting those via inclusion in optimization vs. correcting them via lens data in the database. Comparing against not correcting at all for the lens doesn't answer the right question. I expect optimization is faster if the lens correction is given in advance, rather than computed by optimization. If CP's nearer the corners were automatically generated (rather than manually selected) I would expect the lens db method could give better results, because the optimization will be finding slightly wrong values for lens correction that fit the CPs themselves better than the areas around them. I expect that (for the same reason) using precomputed lens data could be worse when the user has selected CPs to improve important features of the image. All that assumes the lens db values are computed with more/and better examples than are used for ordinary panoramas. Again, I am not an expert. These are my best guesses. I hope an expert will > answer. > I'm not either. I haven't actually ever tried setting up a lens db. I always include the lens correction (at least b) in optimization(usually a later round of optimization after getting yaw, pitch, roll decently approximated). So my real point here is on what should be compared to answer the question. My guesses at the impact you would see are based on logic, not experience. -- 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/0459de48-b01c-4d2b-8c15-06af8c486a20n%40googlegroups.com.
Re: [hugin-ptx] Stop enblend from removing result
On Wednesday, March 9, 2022 at 7:02:07 AM UTC-5 gunter.ko...@gmail.com wrote: > You can remove exzessive overlap by adding a mask that removes part of an > image. > But I wonder if too much overlap should be a warning, not a "error out and > delete all the evidence" case... > I'm pretty sure (from use, rather than from understanding the code) that excessive overlap is not the actual problem. That part of the message is misleading. Reducing overlap by adding masks is one of the things I did, and it did not fix the problem. I'm pretty sure the problem is somehow caused by the jagged edge of the panorama from the many corners of original images when you have not cropped to remove that. But sometimes I don't want to crop out that content. -- 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/67b71a93-baac-44ea-86e4-bab1e6335454n%40googlegroups.com.
Re: [hugin-ptx] Re: Common base class for CPImageCtrl and MaskImageCtrl
On Monday, March 7, 2022 at 1:13:45 PM UTC-5 gunter.ko...@gmail.com wrote: > If two classes have nothing in common from the implementation side > deriving them from the same base class still might have a big advantage: > You can make a pointer to an object of that base class and access all the > common members without casting them > In my opinion, that is the opposite of this situation: I believe the two classes have quite a lot in common functionality, some of which has the same implementation now (with duplicated code) and other parts should have the same implementation. But (for these two classes) I can't think of any use for a pointer to base class. The owner/client of either object knows which one it is using and has no interest in the other, nor in any abstraction covering both. So on the general topic of inserting common base classes, you have a valid point. But regarding this specific question of adding a common base class, common implementation of matching functionality is the only factor. -- 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/8c96ca5e-cdc6-4bc4-8c2a-fa2762533b41n%40googlegroups.com.
[hugin-ptx] Re: Adding zenith shot
I don't understand your question and/or your intent. You have a panorama that has been formed into a reasonable single image by some projection. You want to add an image to fill the hole on top, which I expect means that same projection would no longer be reasonable. I think no projection would give desirable results. That is the reason panorama viewing programs exist, rather than always projecting the whole panorama onto a single flat image. If your intent is to use some panorama viewing program and to use hugin to prepare your panorama for use in that program, I'm sure someone here (not me) can give you some pointers to existing instructions for doing so. But they probably won't unless you make it clear that is the question you are really asking. If you instead are asking for the magic projection that makes more than half of a sphere into a not-terribly-distorted flat image, I don't think it exists, especially since you don't want the focus to be on the pole, but the pole would be the center of the flattened half+ sphere. -- 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/9b6fca1a-f641-4a1e-8b60-84a456d27bc2n%40googlegroups.com.
[hugin-ptx] Create control points button in Photos tab
As a user, I'm bothered by a few behaviors of the Create control points button in the Photos tab. Before fixing those in my own copy and/or in the fork of hugin that I am working on, I'd like to get some opinions on: Why it does what it currently does. Why that might be the way other users prefer it to work. Have I misunderstood what it currently is doing. All this relates to the (maybe nonstandard) work flow of adding more images after you have already put effort into fixing CPs connecting existing images. *1)* If you have only one image selected and the Settings is Vertical lines, then you get the expected behavior (lines within just that image). But if the Settings is not Vertical lines, you get the surprising behavior that your selection of one image is ignored and you get more CPs connecting everything to everything. It would be great to have a way to make it try to connect one new image to every old image, without trying to further connect any old images to each other. That is the behavior one would expect for this point in the UI. If there is some other good way to accomplish that, please correct my misunderstanding. But I still think that is what would be expected here. The lower level code called from that point in the UI is structured to make the behavior I want harder to invoke than you might expect. But not so hard that this should be the reason not to do it. *2)* I've tested behavior, not code, so maybe I misunderstood, but the setting limiting CPs connecting two images seem to apply per run of the code to add CPs, so multiple runs pile up more and more CPs. That is counter intuitive. I think more should not be added (by the automatic CP finder) when there are already the desired number. *3)* It is happy to add exact duplicate CPs. I think it should not do that. -- 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/a43a789b-c8e9-4860-b110-59d7d924523en%40googlegroups.com.
[hugin-ptx] Re: FillSky February update
On Friday, February 11, 2022 at 8:07:30 PM UTC-5 eljef...@gmail.com wrote: > > > I would greatly appreciate reports on compilation problems. I have NOT > worked with the CMake files, I've only updated my local Makefile. > It compiled fine for me (using the CMake changes Thomas gave you) on Windows MSYS / mingw64 , which is a very different environment from the tools Thomas uses for Windows. -- 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/b17ec716-76f2-4a7f-945e-9288e6e72df0n%40googlegroups.com.
[hugin-ptx] Building hugin etc. on Windows in MSYS2 mingw64
I just finished building a fork of hugin and a fork of libpano13 and unmodified enblend on Windows using MSYS2 / mingw64 I tested barely more than opening an existing project, so there is a good chance some operations won't work because of errors I made in building. I ran into a massive string of problems. The non trivial ones and how I kludged around each are described below. I'd really appreciate some information on how I might have solved or avoided any or all of these problems more cleanly (other than telling me not to use mingw64). If some or all of these don't have great answers, I hope my description will help anyone else who wants to build hugin this way. I was working with a fork of hugin and libpano1, but I'm nearly certain that nothing that went wrong nor any of my kludges would be different if this was not a fork. First I got MSYS2 https://www.msys2.org/ Then I used lots of pacman commands to install lots of packages I expected to need. I didn't make a good list. But it is pretty obvious what is missing when you try CMake and pretty easy to find the name and install the package with pacman. You can't get hugin itself or panotool13 or enblend that way. But I wanted to build those myself anyway. I think building libpano13 is necessary. No pre-built binaries are compatible. But I'm pretty sure you could use pre-built binaries instead of building enblend. I followed online advice to use ninja instead of make. I don't think that caused any of these problems. *Lots of problems were in wxWidgets. * Online discussion of the first wxWidgets problem (described below) gave the opinion that the MSYS mingw64 package for wxWidgets puts things in the wrong place. I'm not an expert, but that seems wrong to me and I think instead CMake looks in the wrong place. The online suggestion for that was rebuild wxWidgets correctly. For most of the other wxWidgets problems, I think the MSYS package for wxWidgets *is *at fault and rebuilding it would be best. I never found online info of those problems. I kludged things to live with the bad wxWidgets rather than sidetrack into building a good one. cmake can't find wxWidgets I followed the instructions here. The line numbers there are obsolete. But correct places are easy to find by searching for MSYS https://forums.wxwidgets.org/viewtopic.php?f=19=47555#p202984 even after it find wxWidgets CMake Error at src/hugin1/CMakeLists.txt:27 (MESSAGE): It is looking for a manifest that I think it should not need and which certainly is not provided by the wxWidgets package. I gave it a different version of the manifest. Like almost all my kludges, I edited a line in CMakeCache.txt and then reran CMake: WINDOWS_DPI_MANIFEST:FILEPATH=C:/msys64/mingw64/include/wx-3.1/wx/msw/amd64.manifest It still can't find other parts of wxWidgets -- wxWidgets DLL path: WXWIDGETS_DLL_PATH-NOTFOUND A large fraction of the things it can't find are in the correct place for MSYS mingw64 which is /msys64/mingw64/bin CMake find functions seem to have lots of built in knowledge of MSYS mingw64, but it doesn't seem to work. If there was a good way to tell it that things are generally in /msys64/mingw64/binI'd like to know that. I had to individually tell it each thing WXWIDGETS_DLL_PATH:PATH=C:/msys64/mingw64/bin /include/vigra/separableconvolution.hxx:1413:13: error: ISO C++17 does not allow dynamic exception specifications 1413 | throw(PreconditionViolation) My understanding of this error is that the vigra package in MSYS is too old and a newer copy would be better. So adding that to the set of things I build myself would be cleaner. BUT instead, I noticed that is fixed in two .hxx files stdconvolution.hxx separableconvolution.hxx In the newer vigra *and *I noticed that the change to those two files would not impact the binaries. It would be wrong to copy all the .hxx files from the newer version without rebuilding the binaries. But copying those two without rebuilding is safe. -- Could not find OPTIONAL package OPENEXR -- Found OPENEXR: C:/msys64/mingw64/lib/libImath.dll.a;C:/msys64/mingw64/lib/libIlmImf.dll.a;C:/msys64/mingw64/lib/libIex.dll.a;C:/msys64/mingw64/lib/libHalf.dll.a;C:/msys64/mingw64/lib/libIlmThread.dll.a;C:/msys64/mingw64/lib/libz.dll.a I never understood that one and I never fixed it, even when I fixed the later OPENEXR problem. I have never understood any of the common cases in trying to use CMake on windows where the message that it found something is right next to the message that it could not. Can anyone tell me what part of hugin won't work as a result of this optional item missing? Also what is the actual thing that is missing? CMake Error at CMakeModules/win_bundle.cmake:107 (MESSAGE): OpenEXR dlls not found in search path That was hard to diagnose and I'm not sure I diagnosed/fixed it correctly. If I diagnosed it correctly, that cmake file thinks things are part of
[hugin-ptx] Performance testing Hugin
I would appreciate some suggestions on what operations in Hugin are slow *and *likely to be significantly affected by the quality of code generated by the compiler. Most slow operations in image processing are dominated by cache misses, so the compilation quality makes no actual difference. So I'm asking about the likely exceptions to that. I think I have nearly succeeded in building (a fork of) Hugin (and libpano13 and enblend) in MSYS2 in Windows. I will start another thread on that subject soon, since I have lots of questions about the problems encountered, but (unless someone tells me what basic mistake I made to make it all difficult) I also have a bunch of work arounds for problems that others would want when attempting the same. IIUC, the official windows version of Hugin uses the free version of VC19 (correct me if I'm wrong). My past experience with other projects was that the VC19 free version produced much worse code than the paid version, while mingw64 (which is free) produces about the same quality code as the paid version of VC19, and when key inner loops can be identified, optimizer hints are effective at improving mingw64 vs VC19 which rarely make meaningful use of optimizer hints. Assuming I succeed in that build, I'd like to find out whether it actually makes performance better or worse or no difference. But I don't want to focus on the common case of "no difference" due to operations being dominated by cache misses. I understand for most users the "no difference" cases will be what matters, because they don't care about why it is no difference. But I am still curious to know what the difference is for operations in which there should be a difference. -- 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/502aeb8c-f357-4f76-b444-6ca2a12b6ed4n%40googlegroups.com.
Re: [hugin-ptx] Re: Is FillSky an appropriate tool for fixing ...
Thankyou. On Saturday, March 5, 2022 at 11:01:24 AM UTC-5 eljef...@gmail.com wrote: > > https://drive.google.com/drive/folders/1ds5QHI4qNYqXOLNexS0Ov6Ll14HnhkSV?usp=sharing > > Hopefully you can see those files. > Not yet. I clicked on the "request access" button. >I retract my advice to use darktable's retouch tool -- there is a lot > of sensor dust. > You are right. I thought I had used masks and the overlap between images to get rid of most of that. But I did something wrong and lots ended up in the panorama. > I used the full sky replacement option (-fsr), which basically examines > every pixel in the detected sky and assigns a probability that the pixel > should be considered true sky. If the probability is large enough it will > be overwritten -- so magically all the sensor dust disappears. That one > spot near the horizon on the right where there is a black mask leaves some > artifacts, because of some feathering at the edge of the mask where pixels > were not completely black. > I still haven't found time to figure out where the black came from or where the feathering of the black came from. None of that was in the original images. That should have been just another gap in the final image. > > I will better document the -fsr option in the next tutorial for skyfill. > Does it replace all of the sky that was already good? Or does it detect what should be sky but isn't? > > -- 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/6df89281-1d75-4ec3-a7ec-addb5db8bd0dn%40googlegroups.com.
[hugin-ptx] Is FillSky an appropriate tool for fixing ...
I have many small isolated gaps in the sky of my photos from my recent vacation. That is a bit different from the example use of FillSky. Given how many different things I'm trying to learn to use at once now, I'd appreciate knowing whether FillSky is the right tool before I take time to figure out how to use it. (At a quick first look, it was not obvious to me how to use it). I got dirt on the sensor of my camera at the start of my vacation (I'm not used to this type of camera) and the air bulb I had could not blow the dirt off and I didn't have a cleaning kit. So all my photos have dirt spots. I can mask out the dirt spots where the matter and in non-sky areas of panoramas there is typically overlap with the photo above that can replace the masked out bit. But for sky sections (where the dirt is most visible) there is no photo above. So the mask leaves a gap in the final panorama. Does FillSky automatically find and fill gaps in the sky? Or can it easily be told to? Or is it just for sky gaps created by a ragged top to the whole panorama? -- 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/465483e7-796b-4224-b4e8-9fedbb848932n%40googlegroups.com.
Re: [hugin-ptx] where make install puts things
On Thursday, March 3, 2022 at 3:11:34 PM UTC-5 bruno...@gmail.com wrote: > > The libpano13-devel rpm package only exists for you to compile and link to > the libpano13 rpm package in /usr. Just uninstall it and your Hugin build > will pick up your forked libpano13 headers in /usr/local/include > Thanks. I asked for the "right" way to do this. Your answer sounds like that. I haven't tested your answer and it doesn't really fit what I'm trying to do. But it does help me understand how things fit together. I want to build both the fork and non fork version of hugin, so I should be using both versions of libpano13. The kludge that worked was: I repaired the install of the non fork version: *sudo dnf reinstall libpano13-devel* I edited *CMakeCache.txt* in my build directory for the fork of libpano13 so that it would install entirely disjoint from the *-devel *package (rather than partially overlapped). I changed *CMAKE_INSTALL_PREFIX:PATH=/usr* to *CMAKE_INSTALL_PREFIX:PATH=/ELSEWHERE* I reran: *cmake /media/windows/repository_for_pano_fork* *make -j32* *sudo make install* Then I switched to the build directory for the hugin fork and edited its *CMakeCache.txt*, finding all (5) places that referenced *pano13* (case insensitive) and in each changed */usr* to */ELSEWHERE* Then reran *cmake /media/windows/repository_for_hugin_fork* *make -j32* (I did not install it) That is clearly a kludge. But it works and it is what I understand enough to do. > You may also need to set LD_LIBRARY_PATH for your forked Hugin to use this > library at runtime. > > I have forgotten what I long ago understood about when an executable keeps the reference to the .so file it was linked against vs. when it searches again for that .so at load time. If I ever make a package for the fork of hugin, I'll need to understand that stuff. But I do remember how to use* ldd*. The hugin executable works without LD_LIBRARY_PATH, because it is tied to the location of the .so file that it was linked against * /ELSEWHERE/lib64/libpano.so.3* I also needed the usual adjustment to the XRC location in order to be able to run this hugin without installing it. More testing required. But so far, that seems like all I needed to do to connect the fork of libpano13 to the fork of hugin without overwriting anything needed by the non fork version of hugin. Red parts are not literally the names I used, but communicate the idea better than the actual names. The rest (including the fact that my source code is in repositories on a windows system) is literal. -- 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/ce40febe-c773-4388-966d-700e01dee5d3n%40googlegroups.com.
[hugin-ptx] Re: where make install puts things
On Thursday, March 3, 2022 at 1:42:25 PM UTC-5 Florian Königstein wrote: > I have limited knowledge in Linux, so I cannot say much about that. > > Did you take fastPTOptimizer from > > https://sourceforge.net/projects/fastptoptimizer/files/libpano13-2021-06-07.zip/download > No. > or from the Mercurial repository that I have just generated by forking the > current version of libpano13 and merging my changes into it ? > https://sourceforge.net/p/fastptoptimizer/code/ci/default/tree/ > Yes. In SourceTree on Windows, I cloned that repository into a directory on a share exported by that Windows system. On Fedora, I created a build directory (outside that windows share) and in the build directory ran CMake giving it only the path to the source code in the Windows share (no other options). Then: make -j32 sudo make install When taking a snapshot from the Mercurial repo, it should install in the > same directory as libpano13 since I didn't change the directories in the > CMakeLists.txt file. > Right. I asked here, rather than just asking you, because I am confident the issue is not specific to anything you did. It is something I failed to do, which would be equally required if I had built libpano13 from source code rather than installing the official Fedora package. > Maybe there's a way in the Linux build system to build it only in the > directory where the source code has been unzipped (no install in /usr/... ). > Then you could have separate places for the build files for > fastPTOptimizer and libpano13. > I get that if I simply make without make install. The hard part is whether/how the build of hugin can find/use the build of (the fork of) libpano13 if it is not installed. > > If you run the GUI for CMake, you can manually enter the paths where the > libraries are if CMake doesn't find it automatically or finds it in a wrong > place. > I haven't figured out how to run that GUI on Linux (or even if it is possible). Using that GUI on Windows, I specified where to find things when trying to build Hugin and its dependencies and never figured out how to accomplish anything that way. Editing the CMakeCache.txt file was the only way I ever was able to influence where CMake found things on Windows when building dependencies of hugin. For hugin itself, that method did not work, and I never got CMake to find things. Editing that file on Fedora is on my TODO list for kludging past this problem. But I'm working on many projects at once and did not get to trying that yet. I'd rather know the "right" 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/dedccd1c-1949-4976-b55c-d0564979e54fn%40googlegroups.com.
[hugin-ptx] where make install puts things
I am building a fork of hugin https://sourceforge.net/projects/huginplusplus/ That requires a fork of libpano13 https://sourceforge.net/projects/fastptoptimizer/ I don't think my issues are specific to those forks. Likely this is just my ignorance regarding CMake. Are there options I should have used with CMake to get things to go to the right place? Or is the place they went "right" and I should have done something different with the other CMake to find things in that place. When I did a *make install* on the fork of libpano13, it put files in /usr/local/lib64 But the Fedora package for libpano13-devel puts those files in /usr/lib64 The build for the fork of hugin finds the files where libpano13-devel put them. I would like to know the generally correct way to have make install put things in the right place. But I would also like to know how to keep such things more separated: Can the build for hugin be made to find the fork of libpano13 where that was built (so I don't install that at all)? If not, can I install it elsewhere so it is entirely non overlapping with the fedora libpano13-devel, and get the build of the fork of hugin to use that? (currently most files of the make install go to the same places as libpano13-develputs them, but some go to different places). -- 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/0cee3986-3900-4ca6-84dc-3d09b1391ea5n%40googlegroups.com.
[hugin-ptx] Common base class for CPImageCtrl and MaskImageCtrl
Thomas, is there any way that I could code/commit creation of a common base class for CPImageCtrl and MaskImageCtrl that you would consider acceptable to be merged to the default branch? I think it would improve the maintainability of that code. I think it would also give me a clearer way to do or redo some other changes that I hope can be merged in. For me, it would also make it easier to maintain my private enhancements with less effort for me to merge your future changes into my version. I assume creation of this base class should be started on a new branch (not on the branch with my previous code that you don't like). I expect you want a first commit that just makes a common base class with no more than the minimum contents (meaning with less contents than provides any justification for having the class). Then individual commits per function to replace common functionality that exists in the two classes with a single version the new base class. -- 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/3c63a27f-7714-4c42-9523-bd2b543daccan%40googlegroups.com.
[hugin-ptx] File format for mixed resolution?
Is there a file format that is better than ordinary formats for the result of combining photos with different resolutions? I want to combine two photos, where one is a higher resolution image of the most interesting feature in another. When viewing on a computer, I want to be able to zoom in to the interesting feature and see full detail or zoom out and see full context. The obvious general approach would over sample the wide photo up to the resolution of the narrow photo, then combine them with a mask to force all but the edges of the inner photo to be used unblended. That result would have far more pixels than it actually has content, but should be compressible to eliminate most of that waste. Then a fairly fast computer with large ram could decompress it for viewing. But is there a better way? A format that more directly supports multiple resolutions? Or a container file for multiple photos and a viewer that combines them on the fly. I assume they would be pre-warped for better alignment and have an alpha channel for on the fly blending, but the resolution difference would be dealt with on the fly, up or (most often) down sampling each separately to the display resolution. -- 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/51767015-673d-4575-8ad5-0a46edc4cc9fn%40googlegroups.com.
[hugin-ptx] Stop enblend from removing result
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+unsubscr...@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.
Re: [hugin-ptx] Memory saving and performance issues in control point editor
On Tuesday, February 22, 2022 at 11:13:34 AM UTC-5 T. Modes wrote: > > For the synchronized scrolling the images need some overlap. If the > overlap is too small it does not work so good, but for a normal overlap it > works here. > > I tested with about 30% full image overlap on Windows and about 50% on Linux. In both cases, I brought the same control point to the center of each subwindow, with significant room for either to be scrolled in any direction. So there were no special boundary cases involved, and 100% overlap of the displayed portions of the images. When I get back from vacation I'll look at that bit of code and that may help guide my further testing to understand why it hasn't worked for 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/d8d0f95f-decf-4f8f-bfb1-59e64b7e9cbfn%40googlegroups.com.
[hugin-ptx] Re: Stitcher parameters affect Optimizer result?
On Monday, February 21, 2022 at 7:50:20 PM UTC-5 eljef...@gmail.com wrote: > Okay, I just did that test. I have a different explanation -- the output > results from the optimization report errors relative to the output > horizontal field of view. I took a pto file, ran the optimization (but > did not save the results). The max error was 3.023, then I made a copy of > the pto file, and multiplied the output horz fov by 3, and the optimization > max error becomes 9.069 -- exactly different by the factor of 3. So the > optimization itself got to the same result, it's just the scale of reported > result changed because of the value of the output horz fov. > > Thanks for doing that test. That seems to be most of my answer: The initial report of the error in my example was so unrealistically low because in the normal work flow you compute the alignment before knowing the correct output field of view, so it gets reported based on a default field of view. But, in my comparison, the optimization result also changed, not just the scaling of the report of the result. So I expect the other Stitcher parameters also impact the Optimizer. -- 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/5b7a45c5-3e0f-47ce-bc0b-f8f0ee7fc3a0n%40googlegroups.com.
[hugin-ptx] Re: Stitcher parameters affect Optimizer result?
On Monday, February 21, 2022 at 6:26:54 PM UTC-5 eljef...@gmail.com wrote: > In addition to the output size being different, the horizontal field of > view is different -- for a.pto it is 360. For b.pto, it is 71. That is > probably making a big difference in the final optimized minimum. > > I know that you mean the Stitcher parameter, output horizontal field of view, rather than the optimizer parameter lens Hfov (Horizontal field of view), but I thought that needed to be explicitly said to avoid confusing others reading this. -- 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/99559b29-34c4-4209-a16c-0d6cbf4b10cbn%40googlegroups.com.
Re: [hugin-ptx] Memory saving and performance issues in control point editor
I should have repeated my earlier statement that my committed code should only be tested with non-float images. It has a serious performance flaw for float images. That should be easy to correct, but I expected you to have a strong opinion on where/how that should be corrected, and I thought resolving any issues with non-float images should happen first. But if you were testing with a float image, that would explain part of why your results were so different from my results. I haven't seen the synchonized scrolling ever work, which makes it hard for me to diagnose why my code might have broken it. My Windows system has an unmodified (downloaded from the web page) binary for Hugin and has great hardware. Attempts at synchronized scrolling make both images jump around, but neither gets very far in the direction the mouse moves. My Linux system has an old display card with a flawed display driver, so initially I thought that might be the reason synchronized scrolling doesn't work. It fails the same between my version and the build from default, though not the same as on my Windows system. -- 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/2e399d0f-b4bb-4481-a53a-1f4a639d271an%40googlegroups.com.
[hugin-ptx] Stitcher parameters affect Optimizer result?
If I missed something in the documentation related to this, I'd appreciate being told where that is. How do the Stitcher parameter values modify the action of the Optimizer? In experimenting with how well certain actions made a project fit, I was confused over what seemed to be wildly inconsistent results when I thought I had repeated the same test. By comparing .pto files I found out which step was different. But that leaves me not understanding why that step has this effect. So far as I understand, the difference between a.pto and b.pto (both attached) is just values set on the Stitcher tab. But the optimize results are slightly different and the report from optimize very different. [image: a-result.png] vs. [image: b-result.png] The first is quite misleading because stitching shows the fit is pretty good, but not nearly as good as reported. The actual fit seems to be a bit better in the second where the optimize result is reported as terrible. -- 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/d9be3fd1-e9d6-4c1c-81b2-bfc0decb3d79n%40googlegroups.com. a.pto Description: application/ptoptimizer-script b.pto Description: application/ptoptimizer-script
Re: [hugin-ptx] Re: Vertical Hugin Panorama of Building has Discontinuity on sides
On Monday, February 21, 2022 at 5:52:13 AM UTC-5 bruno...@gmail.com wrote: > > The XYZ Translation parameters are initially hidden as they are not needed > for normal usage, they are made available by selecting Menu -> Interface -> > Expert. > > That is one of the reasons I think only the "Expert" interface is usable. I understand the concept that the alignment doesn't need to be great: The blending tools can cover up for poor alignment. But I've never seen that work for any of my panoramas. I have sometimes used detailed masks to cover up for poor alignment. But otherwise, poor alignment gives a terrible result. I understand that correct use of a tripod with a nodal slide can give you a collection of photos in which there is zero Translation. But I haven't managed that yet, even with careful adjustment of my nodal slide. I also understand that this issue is much less significant for panoramas in which the subject is very far away from the camera (500 meters or more). But I think the more common case for ordinary photographers has enough translation to require those in the optimization. As for the lens, I noticed the slight barrel shape of the parallel vertical lines in the original two photos of this thread. I don't know whether to consider that a lens characteristic different from the default "rectilinear": The part of such parallel lines that are perpendicular to the point of view are wider apart in viewing angle, and the viewing angle between the lines goes down with the distance from that perpendicular. But those two photos both had the camera pointing up relative to the face of the building. The perpendicular point is at the bottom of the lower picture. So the visible slight bulge in parallel vertical lines looks to me like it is closer to the vertical center of the image, which would definitely be a lens characteristic, as opposed to representing the actual point of widest viewing angle between the lines (which I don't know whether that would also be a lens characteristic different from "rectilinear"). -- 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/6a5e887c-17e3-4b1d-8d3e-8c13db954189n%40googlegroups.com.
[hugin-ptx] Re: Vertical Hugin Panorama of Building has Discontinuity on sides
On Sunday, February 20, 2022 at 4:52:32 PM UTC-5 scott092707 wrote: > > New problem: > > I have a two-photo vertical panorama of a building (with a neat bunch of > sculptures at the top), and despite indicating the entire sides of the > buildings in each photo of the same lines - bottom to top - the building > suddenly becomes wider on each side. > The answer you seem to need is the same as last time: You need to optimize with additional parameters. The discontinuities go away with a better fit. The pop up after each optimize attempt tells you a lot about how well it did. I only tried a few combinations and found the two extra parameters that make the most difference. I didn't test whether adding just those two to the basic yaw, pitch and roll would be enough. These and a few others were definitely enough and the following two were most of the improvement. The lens b parameter: I think I understand why, but I'm not sure enough to post that where others here understand that better. The translation y parameter: When you changed the pitch (upward angle) between photos, you did not rotate on exactly the perfect axis for your lens, so in effect you changed the vertical position of the camera in addition to the vertical angle. As long as the important parts of the subjects where they cross the boundary are all the same distance away, that deviation from perfect picture taking is fixed by optimizing the translation y. -- 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/0c6b60e7-7224-4e85-9416-4dda55a8500an%40googlegroups.com.
Re: [hugin-ptx] Memory saving and performance issues in control point editor
On Sunday, February 20, 2022 at 10:55:26 AM UTC-5 T. Modes wrote: > > I asked you several times not to mix up several things in one commit. You > still mixed up several unrelated code changes in one changeset. (Yes, they > have both the same target. But the code changes are totally unrelated. And > the commit message say nothing if somebody looks later in the history.) > I don't see how it is "several" unrelated changes. There is the minor change (that in hindsight I should not have done, because it was separable and because you made the same change between when I tested and when I committed and I failed to notice that when committing). But all the rest is one unit and I can't see how it could be split. I also can't think of what a better commit message might be. > > Yes, it builds and the memory consumptions is reduced. But at the same > time the CPU usage increased significant. When scrolling a single image the > CPU usage increases on my system to nearly 100 %! > And the synchronized scrolling of both images is broken - in the default > branch it takes 3-4 % CPU for a single image scrolling and 6-7 % for the > synchronized scrolling. > My system was always cpu bound when scrolling that window (not reported as 100% because it isn't multi-threaded enough to report as 100%) and my version is faster on my system. I have tried to guess how it might behave on other systems, but apparently something is happening on your system that I didn't predict. How many cores does your CPU have and what tool did you use to measure that 100%? I will investigate the issue with synchronized scrolling. There are a number of different ways to compromise the change for potentially better CPU performance and worse (but still better than original) memory use. But I would need better feedback. It is also possible to get another large performance increase by mixing the scaling into the subimage extraction, rather than using the slower more general version in wxImage. -- 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/a0d2dece-ebc0-4b1f-9e58-2c17f8c0b4f1n%40googlegroups.com.
Re: [hugin-ptx] Memory saving and performance issues in control point editor
I pushed the change discussed here to my branch. Hopefully someone else will try building and testing it. With this change, higher zoom level no longer affects memory use: All levels other than 100% and "fit" have the same memory use as each other, and that memory use is lower than any of them had before. (100% and "fit" are no worse than before and might be better). I hope this can eliminate the objection to providing 400% and 800% zoom choices (which were already in this branch). With a large high res display, I depend on the higher zoom. I didn't find time for most of the pre-commit testing I hoped to do. I did do the simple version of reducing cpu time used by creating the magnifier subimage. I did test enough that I think it is appropriate for others to build/test. With a reasonable test sequence, I compared my branch against a build of the Feb-17 default branch. I compared at 150% so both would have a magnifier displayed. Mine was a tiny bit more responsive and used 15% less total CPU time (to open an existing project, switch to 150%, and review every CP without changing any). There should be a common base class for CPImageCtrl and MaskImageCtrl. The areas I changed would fit better there than they do in CPImageCtrl itself. Some might fit better in some util file. I wouldn't ask permission to merge any of this to default without first resolving that decision. But that only needs discussion if there is a possibility of such permission. -- 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/1770ca26-a40e-4643-be61-f60025a6700an%40googlegroups.com.
[hugin-ptx] Re: idea: limit the amplitude of variation of a free value
Other than field of view, what parameters are able to produce wrong results that have lower total error than any correct result? If I understand correctly, that is the major reason for wanting limits. But in case I've misunderstood: In many other optimization problems hard limits are used to speed up optimization and/or keep it out of non convergence areas (where derivative based optimization sees a wrong direction and/or the error function might be NaN) even though those bad areas hold no false solutions. Is that also a significant issue in hugin? I still think a more stable objective function is a better idea than limits for solving the basic problem. But for discussing the value limits might have, I'd like to understand what aspect (if any) is general across many parameters, vs. what is specific to field of view. -- 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/5859837c-4aba-4633-bc47-02cdcdf69e5cn%40googlegroups.com.
Re: [hugin-ptx] Memory saving and performance issues in control point editor
On Thursday, February 17, 2022 at 1:23:54 PM UTC-5 gunter.ko...@gmail.com wrote: > I don't know if that is the case here. But if the GUI feels sluggish one > typical reason is that you try to update the display for every single mouse > event you get sent (which means that if you draw slightly slower than your > 19200dpi-7ms-latency-mouse sends data you start to fall behind with work > and soon start lagging by a noticable amount). The way to counteract it is > to update the display only when you get sent an "idle" event: > At least on my system, we aren't talking about anywhere near the speed implied by your speculation. This isn't a video game. I assume wxWidgets is dealing with the issue of getting behind by not even calling the onDraw method while previous onDraw calls haven't finished. The results are lagging because a single update takes much too long, not because of any accumulation of failure to keep up. I haven't looked at the lower levels (gtk and x11) where most of the performance problem is, because from above wxWidgets I don't have any meaningful control over the way wxWidgets calls lower levels. I certainly don't want to expand this effort into modifying wxWidgets. It is also likely (and a big part of my reason for this thread) that the giant problem in lower levels doesn't act that way for most hugin users. By contrast, the performance problem in the use of vigra to create the magnifier almost certainly does exist for anyone using the magnifier. It might not make overall performance bad enough to be perceived as a problem, but I'm confident fixing it would have a noticeable effect for most users. For my own use, the sluggish scrolling doesn't bother me much (as compared to the other things I fixed or enhanced). But for some of my other changes to have a chance of being accepted, I expect the memory savings is needed and then that needs to be done in a way that across almost all use makes hugin more responsive, not less. In the current rough version, there are probably more use cases in which the basic memory savings change makes it less responsive, even though there are also use cases in which this change already makes it more responsive. -- 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/19623acb-f37b-4c8c-8e9d-abb4b40b18c1n%40googlegroups.com.
[hugin-ptx] Memory saving and performance issues in control point editor
I recently rewrote my local change for saving memory in the CP editor, to make it more suitable for committing on the branch with my other changes. I ran into a bunch of performance side issues (yes, it saves memory, but the savings vs. cost in cpu time are a much trickier topic). I have only one test environment and it is unusual, so I'm hoping for some feedback after I commit the changes on how this affects performance for others. But while I'm still doing some final cleanups pre-commit, it would be great to get some opinions on which simple extra tweaks sound like they would be effective for other environments. The basic change is: I wrote an efficient method for extracting and rotating a subimage from a wxImage, which allowed me to replace work on the whole image when zooming with work on just the visible portion when it is drawn. That results in a big memory saving and a complicated performance change. If you scroll around enough, then eventually the added cpu time would exceed the saved cpu time. But for an interactive application, that typically doesn't matter, because the extra cpu time is distributed across user actions. But a user expects scrolling to be much less sluggish than zooming, which demands more attention on the draw speed. In my own environment (a giant high res display and an ancient graphics card) scrolling the image was painfully slow in my default-branch build and a bit slower in my version. As I relearned linux performance tools (which I had not used since over a decade ago), it took me a while to realize two things: 1) Almost all the sluggishness is CPU time spent in the XORG process that is independent of my change. 2) Of the CPU time within the Hugin process, almost all is creation of the magnifier image. That ought to be such a small thing, that I initially paid no attention to the fact that it wasn't happening at all in the 200% zoom in default branch that I was comparing to my branch. Recomparing at 150%, just so both had a magnifier, the performance difference in scrolling is too tiny to feel (but that could change in another environment). I don't understand the intent of the magnifier current code. I haven't yet learned vigra well enough to really follow the code. For my own use, it would be easier to just call the same extract and rotate function I use for the whole visible portion. But that would conflict with ever merging my code with Thomas's change to warp the magnifier. Simply saving the magnifier result and only computing it when it changes would eliminate most of its contribution to sluggish scrolling. Maybe I should do that before committing the change. Scaling of the visible portion each time that changes is the biggest performance wild card in my change. My faster, but messier, original version mixed that into the efficient extract and rotate code I wrote. Since we support just a few scaling values and each is a rational number made from small integers, it is practical to have that execute far faster than the more general function in wxImage. I never bothered to support .75 and 1.5 in my private copy because I never use them. That and other needed cleanups prevent my committing that speedup for at least weeks. On my AMD 5800X, the wxImage version is good enough for use even within the draw method. But on other CPUs, especially those with less cache, I'm less sure. There is also a giant performance flaw for float images, which would be easy and clean to fix in the image cache code vs. easy and ugly to fix in the control point code. So I haven't yet done either. On my system, all these performance changes are just tiny changes in a basically bad situation, because none of them affect the massive CPU time in the XORG process. So I'm barely better than guessing at what will matter to others with better graphics cards. In some environments, the whole rotate problem and likely the whole scaling problem can be passed all the way down to the graphics card, making this all really smooth. These changes make those changes easier and I'm trying to keep those future changes in mind as I code. But I can't test anything like that on my linux system and I still can't even build on my Windows system. -- 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/c133c1d4-a03f-4aab-a198-d63ad93794ecn%40googlegroups.com.
[hugin-ptx] Re: idea: limit the amplitude of variation of a free value
I think that problem is important and ought to get some attention and can be solved. But I think your suggested solution would not be effective. Either the user would need to know enough in setting the limits that they might as well just set the value and not optimize the variable, or automatically set limits would do more harm than good in other cases. Based entirely on use, without yet even looking at the relevant part of the code, I'm guessing both sources of a control point are projected into their theoretical positions and compared there. That approach would be inherently unstable and lead to finding wrong solutions that have lower "error" than the right solution. That fits the observed behavior, thus my guess. Projecting one point to its theoretical position and then back to the other image (and computing the error there) would be inherently much more stable. But given varying zoom level across the input, that could inappropriately weight control points. Effective zoom level could vary within an image due to the original lens distortion as well as varying original zoom in the images. But my guess is that the weight problem could be solved more easily than other approaches to fixing the original problem. I might be 100% wrong about all of this. I hope to find time to look at that part of the code and really understand why optimize is so likely to find wrong answers. But in working on many other optimize problems in many other domains, my experience tells me that stricter limits are likely to be a bad cover up for a problem that needs to be fixed elsewhere. -- 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/02062b42-0859-493b-adac-be36963088f7n%40googlegroups.com.
Re: [hugin-ptx] Vertical panorama exposure issue
On Friday, February 11, 2022 at 3:24:32 PM UTC-5 dkloi wrote: > If provide the raw files, maybe we could give it a shot. Are you able to > show what you are getting? Thanks for the offer. But this time I'd rather not share the photos (and they were not raw, they were from my cell phone, which has a much worse camera then most cell phones). I hope on my vacation (which will be later this month) to be using my new camera and mostly with a 105mm lens shooting mostly scenes that ought to be much wider, and so will need hugin when I get home (and those will be raw). I expect some of those will be better examples with which to ask for help. In high contrast situations, I will use exposure blending with enfuse and > this gives quite natural looking results. > > I don't yet have a good understanding of what enfuse and enblend are doing nor how to use their options. I will gradually be learning that. But this panorama has large continuous areas of high contrast detail that need to be split by seams. I think I understand the concept of a program identifying higher contrast areas and forcing the seams to not be there. But I can't see how that could work in this example and I haven't yet gotten it to work in examples where I think it ought to. This one needed avoiding exposure correction, so I chose "Exposure fused from any arrangement" (possibly due to not really understanding the choices). But I don't have stacks and the panorama would be wrecked by any exposure correction that I've seen in action. Many upper parts of the image need to end up darker than many lower parts even though in the real view the darkest thing in the upper third was brighter than the brightest of the lower third. As I understand it, exposure correction starts with undoing the "error" from combining images with very different exposure and then might mitigate the consequences by a nonlinear mapping of a brightness range with extra bits back onto a normal brightness range. But in many of my photos, no such mapping can fix the dynamic range problem. Anyway, that choice on the Stitcher tab selects both enfuse and enblend, then I'm unclear on what each does in this example. Before the masks were improved, fusing or blending (I don't understand which) was happening in areas with great detail and with about a 1.5 pixel misalignment between the images in that area. I couldn't get better results than that from optimize (even before I starting forcing Hfov to be wrong). That was enough misalignment to turn sharp sections of both originals into a blurred section of the result. -- 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/733c7024-dcde-4d62-99d2-0fdbfa7f9346n%40googlegroups.com.
Re: [hugin-ptx] Mask dialog, can't select just one when close together
In case someone chooses to test this (push several points of a mask close to each other, then try to select one to move or delete, etc.), I should point out that I did not yet post the related correction to the code used when you CTRL click on a line to create a new point. That is the same basic issue, but in a different function. In practical use that bad behavior is less likely to matter than the bad behavior fixed by my code above. So I thought posting both corrections together would be confusing. So in testing be aware that the similar malfunction with CTRL down is actually different. -- 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/024a800e-39cd-42bc-91f5-82ea4f377615n%40googlegroups.com.
Re: [hugin-ptx] Vertical panorama exposure issue
I finally went back to that set of 3 photos and got a good result. I'm not happy with the methods required. There is probably a better way. I'm open to advice on what to try next time. There should be a better way, so in any case I'll look through the relevant parts of the source code to see what could be made to work better. There are three basic issues here, two of which were solved with masks. But editing those masks required fixing a flaw in the mask editing code (see my recent new thread). 1) Exposure. Each photo has the correct average exposure for its part of the scene and I didn't want to change that much. But the top photo had shorter exposure than the middle which is shorter than the bottom. So sections from any one photo have good exposure unchanged. But narrow seams would highlight the exposure difference, while broad seams would be garbage due to issue (2). I still think the better general solution would be to first apply an exposure vertical gradient to each photo (in a separate program if necessary). But I didn't find time to try that. A mask worked a lot better than I expected, to force narrow seams in places that don't highlight the exposure jumps. 2) Alignment. I never got good enough alignment for real blending of any sections. My solution to (3) made the misalignment 1.5 times as bad. The masks intended to fix (1) fixed (2) with no extra effort. 3) Distortion. The resulting image was very distorted. I tried most of the projections and some were worse and none were significantly better than the default. After much experimentation, I started without the lens a,b,c,d,e,g,t parameters, then rotated the anchor image -90 and reoptimized (which didn't hurt alignment much), then cut the Hfov in half, and reoptimized which destroyed alignment (I assume because the original Hfov was correct) then added a,b,c,d,e,g,t parameters to get back to decent alignment (I'd really like to know what those are doing and how they compensate for an intentionally wrong Hfov. But I'm already investigating in too many different subtopics at once). Finally, I stitched with Cylindrical and used an external program to rotate +90. Given the distortion this had when simply done sideways with Cylindrical, I expected that cutting the Hfov would do what it did. But I have no clue why it had that distortion. It seems like there should be a less distorting projection without needing to mess with the alignment. -- 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/42d0ad7a-1726-441a-9362-ac71505e6728n%40googlegroups.com.
Re: [hugin-ptx] Mask dialog, can't select just one when close together
On Thursday, February 10, 2022 at 7:00:05 PM UTC-5 johnfi...@gmail.com
wrote:
> A slight rearrangement of conditions inside my code would directly fix
> the problem you described.
>
> Since you have seen symptoms of the basic issue I described, does that
> mean you would like it corrected in hugin, and if so, is the basic approach
> I selected (corrected for the case you mentioned) acceptable?
>
> I made that change, new version below. I only tested a tiny amount, but
including the case you mentioned that I hadn't tested before, which now
works the way I assume most people would consider correct.
// Inserts qualifying points int UIntSet , returns true if any found
// 1) Any number of points inside the rectangle m_dragStartPos to
m_currentPos might qualify
// 2) If no points are in the rectangle, the single point nearest the
rectangle, if near enough, might qualify
// (unspecified which one in case of ties, but only one)
// 3) If considerSelectedOnly, only selected points actually qualify.
// Even if considerSelectedOnly is true, an unselected point may disqualify
some selected point that is further
bool MaskImageCtrl::SelectPointsInsideMouseRect(HuginBase::UIntSet
,const bool considerSelectedOnly)
{
// compute one dimension distance outside range (zero if inside range)
auto distanceHelper = [](double vmin, double vmax, double v)->double
{
return (vhttp://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/1246738c-1415-4ed2-b2ab-468428b3423an%40googlegroups.com.
Re: [hugin-ptx] Mask dialog, can't select just one when close together
On Thursday, February 10, 2022 at 6:41:27 PM UTC-5 bruno...@gmail.com wrote: > > I experience this as trying to drag one node, but Hugin insists on > dragging the previous (highlighted) nodes instead, which would make > sense, but somehow the highlighted nodes seem to be more likely to get > moved than the unselected node that is exactly where I clicked. > > If I understand you correctly: You are indicating you had mask points so close together that this behavior occurred. I assume the way you use hugin (as opposed to the way I do) is within the bounds of what hugin ought to support well. I don't think you are saying that was a DESIRABLE behavior. The code (usage of the function I changed) does (under certain conditions) look first for selected points near enough to the click and only if that fails looks for unselected points. So the behavior you described is exactly as expected from the code. I hadn't tried that case yet, and had not thought it through. My code change only makes the problem you described a little easier to work around. It does not directly fix that problem. A slight rearrangement of conditions inside my code would directly fix the problem you described. Since you have seen symptoms of the basic issue I described, does that mean you would like it corrected in hugin, and if so, is the basic approach I selected (corrected for the case you mentioned) acceptable? -- 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/cfc31f3f-5be1-4c60-ba80-7f2e66e6cb40n%40googlegroups.com.
[hugin-ptx] Re: Mask dialog, can't select just one when close together
After playing with it a bit, I understand how it might have been the way it
was due to not caring about the behavior of points close together (rather
than explicitly wanting them to act that way) while wanting an interface
that supported the explicit method of supporting multiple points (dragging).
I expect the project admins won't want this change (won't see any value in
better support of points very near each other within a mask). So
committing this to sourceforge would just confuse the other things I want
to commit later.
But, if anyone cares, the code below is what I'm using myself replacing
that function. So far, I'm much happier about the way it behaves vs.
struggling with the original.
I hope the code below formats OK in google groups. The online instructions
for doing that "correctly" tell me to click on something that isn't there.
Unlike other forums, I can't preview and I can't edit after posting. So
apologies if the following comes out unreadable (and if so, can someone
tell me how to do it right):
// Inserts into UIntSet either all (selected) points inside
rectangle m_dragStartPos
// to m_currentPos, or (if there were none) the single nearest and near
enough point outside
bool MaskImageCtrl::SelectPointsInsideMouseRect(HuginBase::UIntSet
,const bool considerSelectedOnly)
{
// compute one dimension distance outside range (zero if inside range)
auto distanceHelper = [](double vmin, double vmax, double v)->double
{
return (vhttp://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/c29e6427-2a1e-4842-8d50-a8b1f9ebeebfn%40googlegroups.com.
[hugin-ptx] Mask dialog, can't select just one when close together
When points are very close together in a mask, you can't select just one to move. I understand having the points so close is not typical. But the code seems to have been written anticipating points being that close together and intending that a single click should select all the nearby points. Separately, there is a different way to select a group of points, so it seems like a strange feature. Can someone tell me why the current behavior would be desired? I'm removing it in my private copy anyway. I find it annoying when it happens and never useful. But I would like to know the intent. The code I'm talking about is in MaskImageCtrl::OnLeftMouseDown in case NO_SELECTION: SelectPointsInsideMouseRect -- 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/b2ea84a1-1e98-44dc-b311-4216066ee9acn%40googlegroups.com.
Re: [hugin-ptx] Where is the choice to disable the fast preview window documented?
On Sunday, February 6, 2022 at 6:55:26 PM UTC-5 bruno...@gmail.com wrote: > > > I thought this startup crash had been resolved by automatically > disabling the Fast Preview window in this situation (it has been a > long time since it was last reported). If the Ctrl trick is definitely > still required, the FAQ is a wiki page and can be edited. > > I saw that code for automatically disabling the Fast Preview window and saw it didn't. But I didn't fully debug why. I'm not sure about any of this. Best estimate, someone with my same hardware could not get far enough for this ctrl thing to even help. They could only use hugin linked with an older wxWidgets. But maybe I did something else wrong (could have installed the driver differently or installed something more). Maybe there is even a way to get EGL to work, or maybe I did something wrong that makes hugin fail to detect that EGL won't work. About the next architecture up among obsolete Nvidia architectures, I'm barely more than guessing. I had lots of trouble getting other things to work with this obsolete hardware (even more so before switching from Ubuntu to Fedora) and googled all those problems and mostly found discussions of the same problems but for the 390 driver rather than the 340. So I build up an estimate of what is worse in the 340 (including the reason I couldn't build hugin normally with wxWidgets 3.1.5) vs. what is the same, which I think includes why it crashes on construction of wxCanvas. But all that might be my misinterpretation of those problem / solution reports on related but non-hugin issues. Maybe the whole reason I needed a way to disable construction of that widget is because of the way I kludged things to be able to use wxWidgets 3.1.5 instead of 3.0. Then I looked in the code to try to find a place to put a disable to make my code usable, and I saw that disable was already in the code and I could use it without further private code changes. Alternately, maybe this problem WAS gone but driver updates changing the partial level of EGL in those drivers broke the logic that disables that widget without fixing the need to disable it, bringing the problem back. -- 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/5ba196e1-095a-41b5-b61f-6401805d1586n%40googlegroups.com.
[hugin-ptx] Where is the choice to disable the fast preview window documented?
I eventually found out the method (hold ctrl while starting hugin) and then found the place that is documented for re enabling fast preview window (it brings up a dialog that lets you choose). But I didn't find any documentation of using that to avoid the crash on hugin statup that might require it. IIUC, some graphics chipsets don't have correct enough EGL support for that fast preview window to work with newer (after 3.1.? I forget which exact version of wxWidgets) and will cause hugin to crash during startup if you are using that newer wxWidgets. My own very old graphics chipset (one that needs the 340 version of the closed source Nvidia driver) doesn't even allow building hugin from source when using wxWidgets 3.1.5 I kludged past that build problem, which I think gets me to the place the next version better (of still obsolete) Nvidia driver would be (but I can't be certain). Hugin then builds, but crashes on startup due to defective EGL support in the driver. That is unless you have set the right hidden setting to disable creation of the problem window. The easiest way to set that hidden setting is to hold ctrl down while starting hugin. (Simply never opening that window isn't enough. It crashes on creation during hugin startup). Maybe few other users are stuck (short of buying new hardware) with a driver with broken EGL support. Maybe some of those are able to stick with wxWidgets 3.0 (I likely could have, except for testing a feature I added). So maybe this was all just a problem for me. But in case it isn't, I think some description of the problem and solution (maybe more accurate than I just gave) should be somewhere more obvious. -- 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/becf12e5-ec6f-4d76-9276-928fe3f18255n%40googlegroups.com.
Re: [hugin-ptx] CP Editor tab 400% and 800% zoom choices
On Saturday, February 5, 2022 at 8:35:00 AM UTC-5 gunter.ko...@gmail.com wrote: > Could wxImage::GetSubImage and then scaling the resulting portion of the > original image in CpImgCtl::OnDraw do the trick? > Yes. That does work. I was intending to do something that works much better than that. I wanted the feature committed before I start on the performance increase. At 3 bytes per pixel, and applying to just two of the input images, not the whole panorama, I didn't think memory was the issue I should be worrying about. But I was expecting to fix the memory issue anyway as a result of fixing the speed. -- 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/d9755322-debd-4c7f-ae9a-2769d2acf3c2n%40googlegroups.com.
[hugin-ptx] CP Editor tab 400% and 800% zoom choices
On the branch with my previous CP Editor change, I pushed code to provide 400% and 800% zoom choices. *slow and ugly:* Currently, 400% and 800% are slow and ugly. I have plans for changing both those things. But I have been using them this way for a while, and for my use having those choices has been much better than not having them. For my own current use, I later switched from wxIMAGE_QUALITY_NORMAL to wxIMAGE_QUALITY_BILINEAR, which makes it even slower and no longer ugly. That change did not seem appropriate to include in this commit. *scale and rotate on demand:* Currently, the entire image gets scaled. If the image is portrait mode, it gets rotated. Then since my display on Fedora is also portrait mode, the lower level code needs to rotate it back. The scaling code in wxImage is not terrible efficient for what it does and is not multi-threaded (which would help a lot for big images). It does not take performance advantages from scale factors being easy rational numbers (N/2**M for tiny N and M). It shouldn't take such advantage (doesn't apply to enough of its uses) but conceivably hugin should, since our scale comes from a small list of choices. I don't actually think any of this is the right answer to scaling being slow, but felt the possibilities worth mentioning. Getting rid of the hugin rotation of an image intended mostly for handing off to a wxDC seems to be practical, so the rotation might not actually be needed and if needed will be done by faster code. I need to learn a bit more about wxDC to nail down the details. Usefully delaying the scaling until CPImageCtrl::OnDraw and then not scaling large undisplayed areas, is certainly practical. But the tools inside wxImage aren't properly exposed to enable that. So it would involve some reinventing of existing wheels, so I'd rather look for alternatives first. But ultimately it isn't very much code and could be done better than wxImage did it. On a related subject, wxImage uses *unsigned long *for things where *uint64_t *would be the more obvious choice (a much better choice than *unsigned long* on Windows and an equal choice on Linux). wxImage runs on platforms where *uint64_t* would be a very bad choice (for an efficient data type), but I expect hugin never will. Does anyone reading this know of a platform hugin gets built for on which *uint64_t* is not a good data type? At the moment, it seems to be used only in hugin/src/foreign/flann -- 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/39f8664e-2f4f-48b8-af06-ae2e7ae84a9an%40googlegroups.com.
[hugin-ptx] Re: My first push to sourceforge
On Friday, February 4, 2022 at 10:55:04 AM UTC-5 T. Modes wrote: > > Hugin is bad in upscaling. When doing high upscales you will often see > interpolation artefacts, which is not what the user wants and what is > helpful. So I don't see the point of make this configurable. > It already was configurable. I just changed that from a hidden preference item (changed via regedit in Windows) to a visible preference item. I was using that and setting it higher since long before I decided to try to get the build of hugin to work for me. It certainly is something I wanted as a user. Maybe it depends on your display resolution whether it is helpful. Interpolation artifacts don't necessarily prevent the feature from providing better information as you decide whether a manually adjusted CP is in exactly the right place. A larger width for the magnifier is likely a prerequisite for a larger scale to be useful and a high resolution on your physical display is likely a prerequisite for the larger width to be useful. I doubt I'm the only user who wants to work that way. But I suspect I'm in a much smaller minority both in taking the trouble to find out what hugin registry setting would do it and in being comfortable with regedit. > Sorry, but an casual user does not understand this logic. This is more > confusing than helpful. > That version of the description was for those who might try to build from my branch, not for casual users. The tooltip inside the preferences dialog explains the main use. The two notes on the side explained only the exceptions. I would also edit the help text. It may be hard for you to see as a long time user, but most settings in hugin preferences are much harder for inexperienced users to understand. I'm happy to try to improve it. But I think I started at better than average. -- 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/3d4a5414-0e58-45e8-a2f7-68a540261228n%40googlegroups.com.
[hugin-ptx] Re: I think there is a problem in one of the recent commits by tsmodes
On Friday, February 4, 2022 at 10:40:38 AM UTC-5 T. Modes wrote: > do a clean rebuild. > > Thanks. It was fixed by *make clean* I should have tried that earlier. I was trusting the build system to know what needed to be rebuilt. -- 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/1af25853-bb5c-4abc-ba72-08221165ec81n%40googlegroups.com.
[hugin-ptx] Re: I think there is a problem in one of the recent commits by tsmodes
So far as I can tell, two members of the PanoramaOptions object share the same address. I don't yet understand the relationship between Hugin and panotools. This kind of error usually implies using a .h file connected with a .so file when the two are out of sync with each other. So does this mean I rebuilt too little within hugin? Or do I need to get the other repository and keep them in better sync or what? -- 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/a68624d5-f963-4a36-9c04-c11f7cd71935n%40googlegroups.com.
[hugin-ptx] Re: I think there is a problem in one of the recent commits by tsmodes
I got the backtrace from gdb (easier than I expected):
--
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/7d8691ff-c4e5-4e78-bc79-bcb5843276acn%40googlegroups.com.
#0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
tid =
ret = 0
pd =
old_mask = {__val = {9984268, 9983568, 9984268, 0, 0, 0, 0, 0, 2105376,
505438295860421376, 0, 505438295860421376, 140737306625216, 140737488333024,
140737322691480, 140737306625216}}
ret =
#1 0x751448b3 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#2 0x750f76a6 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
ret =
#3 0x750e17d3 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x76202b98, sa_sigaction
= 0x76202b98}, sa_mask = {__val = {360, 9983248, 43, 9983568,
140737306342624, 140737306370192, 0, 30064771072, 505438295860421376,
140737488333104, 18446744073709551328, 7, 140737322691480, 360,
140737322691760, 8813624}}, sa_flags = -183161899, sa_restorer = 0x752b13a0
<__GI__IO_file_jumps>}
sigs = {__val = {32, 8813624, 140737180629824, 140737305044949, 360,
140737322691760, 8813624, 140737304931242, 206158430256, 140737322691592,
140737306389536, 140737305045242, 206158430232, 14073748828,
140737488333136, 505438295860421376}}
#4 0x750e16fb in __assert_fail_base (fmt=,
assertion=, file=, line=,
function=) at assert.c:92
str = 0x985510 "\205\t"
total = 4096
#5 0x750f0396 in __GI___assert_fail (assertion=0x76202cb0
"image.formatParamCount == (int) projParams.size()", file=0x76202b98
"/src/hugin/src/hugin_base/panotools/PanoToolsInterface.cpp", line=360,
function=0x76202c08 "void HuginBase::PTools::setDestImage(Image&,
vigra::Diff2D, unsigned char*, const
HuginBase::PanoramaOptions::ProjectionFormat&, const std::vector&,
double)") at assert.c:101
#6 0x761b7069 in HuginBase::PTools::setDestImage(Image&,
vigra::Diff2D, unsigned char*, HuginBase::PanoramaOptions::ProjectionFormat
const&, std::vector > const&, double)
(image=..., size=..., imageData=0x0, format=@0x7fffacb0:
HuginBase::PanoramaOptions::EQUIRECTANGULAR, projParams=std::vector of length
0, capacity 0 = {...}, destHFOV=360) at
/src/hugin/src/hugin_base/panotools/PanoToolsInterface.cpp:360
projd = {projection = 2, internalFormat = 4, maxVFOV = 180, maxHFOV =
360, name = 0x77f9d471 "Equirectangular", numberOfParameters = 0, parm =
{{minValue = 0, maxValue = 0, defValue = 0, name = 0x0}, {minValue = 0,
maxValue = 0, defValue = 0, name = 0x0}, {minValue = 0, maxValue = 0, defValue
= 0, name = 0x0}, {minValue = 0, maxValue = 0, defValue = 0, name = 0x0},
{minValue = 0, maxValue = 0, defValue = 0, name = 0x0}, {minValue = 0, maxValue
= 0, defValue = 0, name = 0x0}}}
__func__ = "setDestImage"
__PRETTY_FUNCTION__ = "void HuginBase::PTools::setDestImage(Image&,
vigra::Diff2D, unsigned char*, const
HuginBase::PanoramaOptions::ProjectionFormat&, const std::vector&,
double)"
#7 0x761b0ef8 in
HuginBase::PTools::Transform::updatePTData(vigra::Diff2D const&,
std::map,
std::allocator >, HuginBase::Variable,
std::less,
std::allocator > >,
std::allocator, std::allocator > const, HuginBase::Variable> > >
const&, HuginBase::BaseSrcPanoImage::Projection&, vigra::Diff2D const&,
HuginBase::PanoramaOptions::ProjectionFormat&, std::vector > const&, double) (this=0x7fffbfa0, srcSize=...,
srcVars=Python Exception : 'NoneType' object has no
attribute 'pointer'
std::map with 16 elements, srcProj=@0x7fffacb4:
HuginBase::BaseSrcPanoImage::EQUIRECTANGULAR, destSize=...,
destProj=@0x7fffacb0: HuginBase::PanoramaOptions::EQUIRECTANGULAR,
destProjParam=std::vector of length 0, capacity 0 = {...}, destHFOV=360) at
/src/hugin/src/hugin_base/panotools/PanoToolsInterface.cpp:66
#8 0x761b4ae4 in
HuginBase::PTools::Transform::createTransform(vigra::Diff2D const&,
std::map,
std::allocator >, HuginBase::Variable,
std::less,
std::allocator > >,
std::allocator, std::allocator > const, HuginBase::Variable> > >,
HuginBase::BaseSrcPanoImage::Projection, vigra::Diff2D const&,
HuginBase::PanoramaOptions::ProjectionFormat, std::vector > const&, double, vigra::Diff2D const&)
(this=0x7fffbfa0, srcSize=..., srcVars=Python Exception : 'NoneType' object has no attribute 'pointer'
std::map with 16 elements,
srcProj=HuginBase::BaseSrcPanoImage::EQUIRECTANGULAR,
[hugin-ptx] Re: I think there is a problem in one of the recent commits by tsmodes
Sorry, I didn't realize before posting, that even my screenshot failed. I really hate how aggressively kdbg stops you from copying information out. But it is the only debugger I managed to get working with hugin in Fedora. I'll try again with gdb and provide a better traceback. -- 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/00f7a3c2-2972-47d7-9aba-7b9f961d5b4bn%40googlegroups.com.
[hugin-ptx] My first push to sourceforge
If I did this right: I created a branch JohnsWork I pushed one commit containing phase 1 of changes to add preferences for the behavior of the magnifier in the CP dialog. In the preferences for the CP dialog, there are three new entries, all in a section named magnifier. The first two were already hidden preferences (edit in ~/.hugin for linux or in registry for windows). The third is new. Half width: Default 30: This controls the width in pixels of of the magnifier. The actual width (and the value stored in ~/.hugin) is 2N+1 of the value given in the preferences GUI. Scale: Default 3.0: This is the zoom level inside the magnifier square. So 3.0 means 3 pixels of screen for each pixel of image. Relative Scale: Default 0: This controls the behavior of the magnifier for higher levels of zoom of the image itself. Most of its meaning doesn't become useful until the 400% and 800% zoom levels of the image are available (which I'm using but did not push to sourceforge). Values: < 1.0 means keep the old behavior (from before I added this preference item) primarily not displaying the magnifier for zoom level 200% or greater. 1.0 means disable the magnifier when it would not be more zoom than the image zoom. > 1.0 sets the min magnification of the magnifier as a multiple of the image zoom: example, if the scale is 3.0 and the Relative Scale is 2.0, the actual magnification would be 3.0 for zoom 100% or less and would be double the zoom for zoom of 200% or more. I'm still planning to make the changes I described earlier including a preference to change the hiding rules for the magnifier. But I decided an even smaller first commit was appropriate, in case I'm doing something fundamentally wrong. Please provide some feedback: Did I do the push correctly? Does my branch build for you? Does this new feature work for you? Whatever else you might consider wrong? How do I get the visible text I added into whatever queue exists for text that hasn't been translated yet? -- 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/583e6c1f-9e5b-48a5-bd2e-de64f1ddff00n%40googlegroups.com.
Re: [hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp
On Wednesday, February 2, 2022 at 2:36:28 PM UTC-5 Luís Henrique Camargo Quiroz wrote: > >John just told us about another annoyance that I, while adding manually > my control points, see all the time. I put the text in bold, in his first > paragraph below. >I even tried, in vain, to immobilize the mouse -- with both hands! -- > before releasing the button to create a CP, however the carefully chosen > position moves and then I have to use the arrow keys to reposition it where > intended. I think the movement is always to the right, maybe a little up, > and it seems to be by a fixed amount. > I'm pretty sure you are talking about a different problem than the ones I was talking about (in what you highlighted). 1) I was talking about the fact that the displayed numeric change on release includes movement that occurred earlier and was not numerically displayed earlier, so if you perfectly freeze before releasing, the displayed numbers do not represent where the point actually is (the displayed point does represent where it is). 2) I was talking about my own inability to release a mouse button without moving the mouse. Maybe others have the same problem. Maybe some mice force that problem. But it is far from a universal problem. One of my sons can use and release (without extra movement) the same mouse in the same program (though he hasn't tried hugin) that I fail with. Consistent up and to the right?? A fixed amount?? We aren't talking about the same thing. If there is some hugin problem there, I don't even have the manual dexterity to try to test for it. Need to adjust with arrows after releasing the mouse: I just assume that as fact of life, not as something that could be corrected. But I also assume that is just me, not most users. -- 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/e0637411-1776-46b9-91f6-a476bf18746dn%40googlegroups.com.
Re: [hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp
On Wednesday, February 2, 2022 at 11:38:37 AM UTC-5 T. Modes wrote: > bruno...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 23:20:14 UTC+1: > >> On investigation, it looks like the magnifier doesn't appear when you >> click down on a control point, it only appears once you have dragged it >> away from the original location, then when you let go it vanishes after a >> couple of seconds. >> > This is not reproducible here. The magnifier appears when only clicking on > the cp. (and also when dragging) > Yesterday, I was seeing the behavior Bruno described. I don't have a steady enough hand, so usually when I clicked, I accidentally dragged, but sometimes I just clicked and got no magnifier. But I can't reproduce it today (as I tried to prepare to comment on what you just wrote) and I can't think of anything that could have changed. I think a few of these times I clicked carefully enough to not drag. But I can't be sure. I almost never can release the mouse carefully enough to not drag. The displayed x,y coordinates change on release and so far as I understand, there isn't a way to know after just clicking whether the point has moved slightly. > > > Just some more remarks: > The logic implemented in the cp tab is already very complex to handle all > use case - there are many possible user interactions, many have been > improved in the last years. So doing changes based on a feeling can be very > dangerous and has the possibility to break other interactions with the tab. > I'm pretty sure I can retain the exact current behavior for the default value of new pref items. I will need to make changes very slowly and carefully with a lot of research into current behavior. But I can do that. I don't believe the current behavior is very close to the intended behavior when coded. In most cases I see, the magnifiers stay indefinitely. From what you said as well as from what I would guess by looking at the code, that is not intended behavior. For my own use, that probably unintended behavior is necessary for me to be able to use the tool at all and the apparently (to me) random situations in which the intended behavior occurs are a massive inconvenience. Still in changing the code, this would be one of the uncommon (as compared to other work I've done) cases in which maintaining the default of behavior I'll never understand would be easier than fixing that behavior. > > Also in the last years with the improvements of the automatic cp detectors > I'm using the cp tab to less and less amount. So the necessarity for bigger > improvments is very low for me. > > Maybe there is more I need to learn about using the automatic detectors. But so far, I've never been able to construct a decent panorama without removing many automatically created cp's and adding several new ones. -- 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/a5c5fbe4-10ef-4ef9-bc70-c22be5a462e2n%40googlegroups.com.
Re: [hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp
I wasn't giving proper attention to where the mouse was hovering when I was trying to understand the magnifier behavior. I was instead thinking about where the last mouse click had been, which doesn't seem to matter as much. In testing now, it seems that the magnifier appears when the hovering mouse leaves the image (subject to there being a cp selected). So you get the other when when you hover to the other image and both when you hover to the lower section of the cp dialog outside both images. Then sometimes the arrow keys work to move some side of the selected cp with both magnifiers in view, and sometimes not (I still don't have a great mental model). That is more control (without making a code change) than I thought I had. But the lack of mental model means I still don't know what to expect when I do things. > -- 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/47cd9cf0-a5ae-4e4d-a969-4a0c9abb2616n%40googlegroups.com.
[hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp
On Tuesday, February 1, 2022 at 12:34:49 PM UTC-5 T. Modes wrote: > > Just to recapitulate how the magnifier work: > a) When a cp is selected (via the list or by clicking on it) the magnifier > is shown. As soon as the mouse moves over one image it is hidden. -> So no > need for an additional shortcut IMO. Just move the mouse. > b) The magnifier is then showing again when dragging the selected cp with > the mouse. When the dragging is finished the magnifier is hidden after 2 s. > During dragging I think the magnifier is helpful for better selection of > the position. > > So which behaviour is disturbing you? > That description doesn't fit the behavior that I think I've experienced. But I never had a good mental model of what that behavior was and the surprises in behavior were part of the problem. Later I may try to test a bit and see where the behavior doesn't fit your description. I hope Bruno and others will answer your question, because I'm pretty sure Bruno disliked the current magnifier hiding and would be more competent to explain why and/or have more mainstream reasons. For myself, I am slow at parsing visual information, such as comparing what I see in one magnifier to what I see in the other, so as I'm deciding whether to move it more, the magnifier is gone and I can't finish deciding. I also find it very odd that there is so often a magnifier on one image but not on the other. Is there a point to that, which I'm missing? The basic activity is comparing the location of the cp in one image to its location in the other. When is that helped by seeing the cp in a different way in one image vs. the other? When the context (from hiding the magnifier) is helpful, isn't it needed on both; When the magnifier itself is helpful, isn't it the comparison between the two, which is actually helpful? > > -- 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/3cb0a810-04c4-414c-a91a-44c50ffb6425n%40googlegroups.com.
[hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp
On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote: > > The disabling of the magnifier for the 200 % view was added as a feature > request. So there are uses which prefer this. > I really hate that feature and I don't even get why someone else might like it (unlike the timer feature, where I understand the purpose and just don't like it). BUT, that option is not too ugly to include within the choices for relative zoom of the magnifier. > Please, one change - one changeset. Do not mix things in one changeset. > I'm now intending one change for managing and implementing settings for the behavior of the magnifier. I hope that is self contained enough. The relative zoom part of that would be immediately testable and even have some narrow use case before I commit the change (that I'm already using myself) for overall zoom of 400% or 800%. But most of the reason for relative zoom won't exist until 400% and 800% are available for overall zoom. -- 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/13c6c9b0-0aa7-452c-902c-954a2a2f8187n%40googlegroups.com.
[hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp
On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote: > It is difficult to comment because you are often mixing things. Or as an > example you contradict yourself > > johnfi...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 15:41:14 > UTC+1: > >> Hiding would only be temporary: other actions make the magnifier appear >> and "hiding" would not suppress that. > > and later > >> I want the new 'm' key operation to be the only thing that hides the >> magnifier. >> > Not a contradiction at all. I* was* saying 'm' would be the only thing that hides the magnifier, but would not be the only thing that brings the magnifier back once hidden. But since that suggestion does not seem to fit the needs of others, I will drop the idea that 'm' should be the only thing that hides the magnifier. I'll need more thought on how the things that hide the magnifier should interact with each other. I disagree: I like the feature that the magnifier disappear so I have a > better view on the whole neighbourhood of the cp. This makes it easier for > me the judge the cp. > Thanks for telling me in time that I can refine my plans (rather than do work I would later undo). That feature you like, is so inconvenient for others (I'm not alone on this one) that a setting is required and I will now sidetrack into creating that. I'm even fine with the default being the way you like it (though I suspect more users would prefer it my way). > > Please, one change - one changeset. Do not mix things in one changeset. > You can also send patches (diff files) for other people for testing. > It would be hard to split the changes for creating that setting (that I now understand I need, after previously hoping I wouldn't) from the changes I expected to make first, that now include applying that setting. It probably would be ugly to split that from the related magnifier settings that I would have done next if this change didn't need a setting. So I'm seem to be forced into the high side of the meaning of "one change", relative to what you maybe happy with for a first commit from someone you don't have experience with. I'll do my best to make it clean and to pull in as little as practical of the related planned changes. I'll use diff files if those are strongly preferred in this group. But all my professional experience in group software development tells me using public branches in a source code control system works a lot better than emailing diff files. I assume that anyone who could use a diff file could more easily get the full files from the branch and in rare cases that they couldn't use files from a branch, they could get the diff from the 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/d7d9aa82-96ca-41ad-9acf-defc4a906531n%40googlegroups.com.
Re: [hugin-ptx] Removing magnifier hiding timer etc. from CPImageCtrl.cpp
On Tuesday, February 1, 2022 at 11:31:43 AM UTC-5 Luís Henrique Camargo Quiroz wrote: > > What about keeping the views at 200% and just the magnifier (or a > bigger one) at the intended 400 and 800%? So the left and right views would > show a bigger field of view. > I think what I plan to do will fit your needs. I still want 400% and 800% as choices in the menu for overall zoom. You won't need to use them. Currently (without any of my changes), the size and zoom level of the magnifier itself are set by registry settings in Windows and by ?? in Linux. I forget what the default was for that zoom, but it was at least 400%. I want to make the size of the magnifier user settable without regedit and I want to change the setting logic for the magnifier's own zoom level in addition to making that setting user settable without regedit. I think the magnifier's own zoom should be set as both a minimum and a minimum relative to overall zoom (so it gets the larger of the two). So you might select a magnifier zoom with its minimum at 400% and its relative minimum at 800%, in which case at overall zoom 50% or lower, the magnifier would be 400%, while at 100% or higher, the magnifier would be at 8 times the main zoom. Alternately, you could set the X% as the minimum (meaning only) zoom for the magnifier and the special lowest (labeled "none" rather than 100%) relative value. So for overall zoom below X% the magnifier would be X% and for overall zoom at or above X%, the magnifier would go away (similar to the go away at 200% existing feature, but more sensible). > If you find the right part of a scene on my 1280x800 screen a 8xmagnifier might instead be a way to get completely lost I recently switched the two portrait mode displays on my Fedora system from 1440x2560 each to 1620x2880 each. So I have an overall 3240x2880 display. So my needs are different from ordinary and I want Hugin to span the range between my needs and others. I want the overall zoom to be higher and I need the magnifier itself to occupy more pixels of the physical screen. -- 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/fbde42b6-2427-4f76-ab5e-874cf58ae400n%40googlegroups.com.
[hugin-ptx] Removing magnifier hiding timer etc. from CPImageCtrl.cpp
If there are no objections (in time before I actually do it) I will make a branch and make the small change described here as my first (of I expect many) commits on that branch. If there is any disagreement on details (rather than overall objection to the change), please tell me that as well. There are conditions under which the magnifier for the selected point in the control points dialog gets hidden without the point being deselected. As a user, I find that very inconvenient. Bruno seemed to agree in earlier discussion. On occasion, I really want to hide the magnifier. But there is no correlation between when it gets hidden by current code and when I want it hidden. I want to add a key (my choice would be 'm') that will temporarily hide the magnifier if it wasn't hidden and will bring it back if it was. Hiding would only be temporary: other actions make the magnifier appear and "hiding" would not suppress that. I would entirely remove the timer. It's only purpose is to hide the magnifier. I see no logic to when that timer is used vs. not used. Maybe the original intent was to always have that timer (never let the magnifier stay in view for over 2 seconds). As a user I see* zero* value in timer based hiding of the magnifier. But if others strongly disagree, (with significantly more work) I could invent a setting to allow that feature to be disabled (rather than take the feature away from everyone). With my limited understanding of mercurial, I was able to see the timer feature was added by ippei in commit 91503d5bebff I don't know this environment well enough to know how to find out who ippei is nor to find out when/why that commit was made. I also want to remove all other existing logic for hiding the magnifier, such as hiding it when the image itself is zoomed 200%. Subject to having a control point selected to be magnified, I want the new 'm' key operation to be the only thing that hides the magnifier. Separately, I want to commit my changes adding 400% and 800% zoom and my changes adjusting the magnifier for higher zoom. I expect the purpose of removing the magnifier at 200% zoom is that it isn't much extra magnification. But I both still would want it even if it was only a little extra and want to increase how much extra it is. Separately, I think the controls over the magnifier that are only in the registry on Windows (and I haven't looked for where they are on Fedora) ought to be in the GUI settings so they can be changed without regedit (I'm very comfortable with regedit but I expect most Windows Hugin users aren't). At the same time a bit more control should be included. I would tend to want to pretest and commit all those and related features all together. But I have been warned that doing so would make things too hard for whoever reviews/merges my changes. So I think the right size first chunk is just the changes related to hiding the magnifier. -- 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/22486fd0-4c32-43c2-ad90-49c45c4a7cfbn%40googlegroups.com.
Re: [hugin-ptx] Control Point dialog features
On Sunday, January 23, 2022 at 8:36:58 AM UTC-5 gunter.ko...@gmail.com wrote: > Do we really have to magnify all of the image if afterwards only a small > portion of the magnified image fits on the screen? For me that feels like > an use of something similar to wxScrolled: wxScrolled tells you what part > of the image to render, you render that part and the rest happens by some > magic the operating system offers. > > Unfortunately wxScroleld itself chokes on too big virtual areas to scroll > in as GTK3 does do so when volunteering the magic that on scrolling moves > all parts of the displayed area that can be re-used after scrolling, then > requests the areas that aren't cached, currently (only the pixels that are > visible on the screen are cached). Afterwards that magic copies the > resulting bitmap to the screen; if the wxScrolled is only updated when > wxWidgets issues an idle event that feels both speedy and allows real work > to be done in the background. > > If I were working on wxWidgets, rather than working on Hugin, I would certainly focus on the things you suggested. Inside wxWidgets, there are lots of places where it would be easy to only record what needs to be done for magnifying and clipping, rather than actually do it, then the next time data from the magnified and subsequently clipped image gets copied (such as by GTK) produce that data on demand. I tried to figure out ways to derive from wxImage (rather than simply use it) in order to add those features (that I think it should have had). But so far as I understand, the interactions with GTK etc. aren't coded in a way that would permit that. For the moment, I'm setting that whole issue aside and working on some easier things, (the things I originally intended to talk about in this thread). -- 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/026748df-bc37-421b-95be-d8f936fd0a33n%40googlegroups.com.
Re: [hugin-ptx] Opinions on warping to fine tune the results of control point optimization?
On Tuesday, February 1, 2022 at 6:56:17 AM UTC-5 bruno...@gmail.com wrote: > > The remapping and stitching is performed as usual by the Hugin toolchain, > ptomorph just manipulates the input images a bit to make them stitch better. > By "input" do you mean original? I can't imagine how that data flow would work. Maybe I'm also confused by the terminology, but I think I understand what the "remapping" and "stitching" steps are. In that context, I saw "fine tuning" as an adjustment* logically* after remapping and before stitching. I would not want that *actually* after remapping, because I think the interpolation of moving pixels non-integer distance is best done all at once. So I would want the morphing to occur during the remapping (digging into that code is the biggest obstacle to my actually doing this whole thing). > > The question was always: should this morphing be added as an overall > polynomial distortion in the panotools lens model so that it became another > part of the optimisation step, > That is another thing for which I can't even imagine the workflow (or the point) so I must be misunderstanding what you mean. I am assuming a morphing that goes all the way to perfect alignment of every control point, so it would overwhelm the point of optimization if it were in optimization. So I would think it must be after optimization. I am only guessing at the data flow inside remapping, but based on that guess my idea is: First do optimization additionally computing something that I think isn't currently output but easily could be: the "correct" yaw and pitch of each control point. A control point exists in two images (could be more than two if other ideas I have were mixed in). The "correct" yaw and pitch of a control point would be necessarily the same across all images that contain that control point. For each image the control point is in, you would also compute the "incorrect" yaw/pitch of that control point by applying the optimization results for that image to that control point. In remapping, I assume you work on an integer row/column position of the output and need to compute the corresponding (non integer) row/column position in the input. I assume you have the parameters to convert the output row/column to yaw/pitch, then you would identify the triangle of control points (in correct yaw/pitch coordinates of control points). Then you need to adjust the point you are working on by a small amount based on where it is in the triangle and the difference between the "correct" and "incorrect" positions of each corner of the triangle. Finally, you apply the optimization results of the input image to convert that yaw/pitch back to row/column. When the triangles are very large in yaw/pitch, because either masking or other factors left no details needing to be fixed by extra control points, it is important that the adjustment by the error of the triangle is tiny compared to the adjustment by image's optimization results. So shape within that triangle is preserved as well as possible by the chosen projection method. or is it just a stitch-time fix (as in the ptomorph examples). The problem > for me is that doing it in the lens model is more elegant, and the problem > of three or more images doesn't exist because you wouldn't be forcing an > exact alignment; but on the other hand I was getting *really good* results > using the ptomorph approach with the 'Shepards' stretch to fit distortion > between two 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/a04e49a6-7b7c-4a40-8387-9da5690c9a04n%40googlegroups.com.
Re: [hugin-ptx] malfunction in CPImageCtrl when the magnified image has over 2**27 pixels
On Monday, January 31, 2022 at 5:35:33 PM UTC-5 bruno...@gmail.com wrote: > > If not, then send me your sourceforge username. Note that sourceforge > supports a fork/pull-request workflow (similar to github), so you can > work on a separate personal repository just as easily as the main > repository. If you do choose to work on the main repository, then > typically features get developed in temporary branches > I sent the username via a direct email. I think I should provide my first few enhancements, including the 400% and 800% zoom choices, initially without the work around for the problem with over 2**27 pixels in a zoomed image. If my changes then get tested, it should confirm or contradict my current guess that the 2**27 pixel limit is inside the obsolete and poorly supported closed-source Nvidia driver I'm using (Nvidia variant 340). I'm still a bit far from understanding the performance tradeoffs of combining that work around for me with a more general performance improvement for large zoomed images. So for a while, I'll use my crude work around, and share other changes for testing. -- 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/8c429aab-26e5-4622-abc1-b4f19c8fca7dn%40googlegroups.com.
Re: [hugin-ptx] Opinions on warping to fine tune the results of control point optimization?
On Monday, January 31, 2022 at 5:06:20 PM UTC-5 bruno...@gmail.com wrote: > See the ptomorph proof of concept from ten(!) years ago here: > https://groups.google.com/g/hugin-ptx/c/UripOuuYXCQ?pli=1 > > This works incredibly well, with no need for low-priority control > points, but I never pursued it, and it needs some thought regarding > getting it to work with more than two photos. > > I guess I need to learn more about the pano scripting etc. At this point, a few gaps in my knowledge stop me from even following the discussion there. Looking at the full stitched version vs. the full morphed version, the stitching error in the full morphed version (where the silver pole crosses the boundary between the top and second to top window of the glass windowed cabinet) is surprising for the described method, though I expect a few control points could fix it. The overall shape differences are more concerning. That specific scene is one in which broad shape differences are hard to visually parse. So I can't validate my guess that in other examples the shape change of that method would be too big. Both the big shape change and the issues of chaining the methodt across more photos are reasons that I was thinking of the morph as a fine tune on top of existing methods, rather than as a replacement. For many examples, just the morph would be a lot better than the existing methods, so it is sad that you didn't have time to pursue that as another choice within the Hugin GUI. >From that discussion: > Panotools also uses a not-very-nice distortion where it splits the image up into triangles and performs an affine transformation on each triangle separately That is certainly what I had in mind (possible just because I don't know better ways). I expect that using this as a fine tune, rather than as the primary method, would eliminate the problems with that method. Anyway, thanks for providing a lot more information on this topic than I expected to get (even though I have significant learning to do before I can try using any of that). -- 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/330b7749-6e18-45fa-b091-e88829ff0197n%40googlegroups.com.
