Re: [hugin-ptx] Re: smarter undo/redo
Am Freitag, 24. September 2010 schrieb Yuval Levy: ... I have also thought of listing history steps (like in a browser's back button), but for this the descriptions in PanoCommand need to be cleaned up (I already cleand a bit), and some more detail about the specific action need to be extracted (maybe from PanoMemento? I'm still studying that part of the code) to be listed. I like this idea. Something numbered, so one could remember the history number. another feature I am looking into is saving the whole history with the project file. Because the outcome of the optimization process is very much dependent from the initial positioning of the images, access to the whole history of the project can be helpful when fine tuning the individual images. This too, but it looks like a difficult thing over sessions. The accessible history would be this session only. Yuv Kornel signature.asc Description: This is a digitally signed message part.
[hugin-ptx] Re: hugin blues
I'd like to add my thoughts here on why I liked Hugin, but decided to use PTgui. I've just started with Panorama software, and am looking to integrate Panos and VR tours into my photography business. I'm a great advocate of Open source software, and was pleased to find Hugin, and it's associated programs. I've also a long track recored in computing before moving to photography as a career, so I was happy to tackle the challenges of getting Hugin to work However, after a number of trials, and some success with Hugin, I bought PTgui. I could get good (perhaps not perfect) results quickly with PTgui that I couldn't do with Hugin. And my criteria for choosing the software was getting my knowledge up and the ability to get a product to market as soon as possible - so the use of commercial software and consequent timesaving was, for me, the correct decision. These days I do most of my work on a Mac, having migrated from windows. I had some difficulty in installing and getting everything to work on this platform. It wasn't practical for me to use my Windows desktop to stitch panos but travel with a Macbook when taking the images. I guess the final thing was actually gathering up to date information on both program installation and operation - a common problem with open source. However, I still gather lots of useful information from this community, and perhaps will revisit Hugin as a tool when I can easily install and configure on my Macbook. -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: Hugin and focal length multiplier struggle.
Hello Yuv This is no issue of Hugin itself, but it is a lack of Standard in handling and using EXIF info by camera manufacturers and software developers. It seems there is no standard in the EXIF info of various camera manufacturers, and handling and saving of the EXIF info after the development and processing by the developers of the programs. a couple of years ago I fixed the FOV reading for Olympus cameras. Out of camera images are pretty OK now, but there is no way Hugin can support the panoply of software used to convert RAW / edit the images before they are fed into Hugin. Focal length in generaly is handled well (except canon zoom browser that works only well for EXIF info for canon camera files). I am not sure I understand this statement. Is there an issue with files saved from canon zoom browser when they are loaded into Hugin? Yes there is an issue with olympus jpegs processed in the Canon zoom browser. When checking the EXIF after processing the focal length isn't in it. Apart of the save lens, wish there was a camera database in Hugin where you can put the camera and multiplier for that camera and save it. When needed Hugin can read that info and fill in the multiplier value.The multiplier is only dependent of the camera and not the lens. The multiplier depends on what is in the file. As much as converting software can garble EXIF, it is possible that a converting software garbles the multipler as well, e.g. converts the focal length information to full frame equivalent or whatever multiplier it wants to write in. I don't think that recalling a multiplier value based on the camera's identification tag can be helpful. Building in a camera database with the multiplier in Hugin with all camera's is too painfull and always not up to date. Too many camera's coming out each year for it. I've a license and use PTAssembler too. In the beginning Max Lyons started a database for camera model and multiplying value, but abandoned that, because it is too time consumingto keep it up to date. That is a simple text file according a certain syntax with manufacturer and model and multiplier. Manufacturer and model according the EXIF info. I can edit my camera's in it according the EXIF info and put the multiplier in it. The multiplying value is then hardcoded in the program and has not to be calculated from the EXIF info. Luckily it is a text file, so PTAssembler can read now my camera and multiplier from the text file. Manufacturer and model stays intact in the EXIF by postprocessed jpegs and developed raw files. When the camera is not in the multiplier list then PTAssembler tries to calculate it from the EXIF info. Out of curiosity I found this by studying the multiplier file and the exif info, so I could feed my camera's in the multiplier file. Perhaps in the future a possibility that the user feeds his own camera and multiplying value for them in Hugin? Also, most users work with a single camera and a single conversion software. Sometimes two. The effort of saving the lens (which is anyway strongly recommended, including calibration) is minimal. Getting to grip with the hundreds of camera models, EXIF-mangling software, and all combinations thereof is not practical. I just did this test out of curiosity, because I didn't get the multiplying factor of my in Elements processed E-500 files. I'm as most users, but curiosity strikes me some time. The camera's I use are only the E-500 and powershot A590. Software I use for viewing and processing is Photoshop elements 7 and Faststone image viewer. Kind regards, Henk -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: Selecting and moving multiple images in Hugin's Image Tab.
Thomas. Apologies for the re-posting.. I did not see the orignal appear in the group? Since I'd used another emailer to send it I assumed it had been block. Yes I'd completely over-looked the fact that non-adjacent images could be selected.. The 'shuffling' of image does generate alot of 'history'. I'd been thinking about Yuv's recent post on undo history. For some reason I never use undo, not that I don't make mistakes, just Hugin provides other ways to get around mistakes... So again I never thought to test this patch for it's undo behavoiur. Looks like I do want to write methods to delete and insert images into the list. Thank-you for taking the time to review the patch.. Regards Stephen On Sep 10, 12:01 pm, T. Modes thomas.mo...@gmx.de wrote: Hi Steeve, Seems too easy, can anybody see anything I've missed? The patch needs more work: 1.) First, it creates for every image an own command in the command history, what makes is complicated to use the undo function. 2.) Your patch goes mad, if you select several non-adjacent images. In this case it moves n images following the first selected image (with n the number of selected images), but not the selected images. This is the main reason why moving several images is not so easy. You can not assume that all selected images are adjacent. If you force this, you break exisiting functionality. Thomas -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: hugin blues
On Mac OS X you just need to download an image (dmg) or a zip file from Harry's site [1], open that and drag the contents do the desired folder. hugin installation done... (hugin-mac-2010.2.0-rc1-p2 from 18 Sept 2010 works fine on my oldish G5 PowerMac) Next step is to once download the needed CP generators as described in the folder Control Point Generators that comes with hugin. Just follow what's written in Read me first (Mac).rtfd. What other hurdles do you see? Cheers, Carl Gareth schrieb am 24.09.10 10:23: However, I still gather lots of useful information from this community, and perhaps will revisit Hugin as a tool when I can easily install and configure on my Macbook. [1] http://panorama.dyndns.org/index.php?lang=ensubject=Hugintexttag=Hugin -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: hugin blues
Thank you all for your echo to my hugin blues rant! And special thanks to Yuval Levy, you have really made an effort to work things out for me so I can take heart, get over my frustration and maybe end up doing something productive. I could go on now about to finer points of my criticism and be less vague about why I moaned about this or that, but I feel that would be besides the point and I should rather direct specific criticism to specific places/threads/recipients. Let me add that I am using very recent Windows builds to good success - I really don't mind the odd bug or crash, as long as I can make my way. I really appreciate some newer features - like the fast preview, mosaic mode or the masking tool, and I'm well willing to struggle up the learning curve to get things working. And I'll look into what I can do to make the problems that bug me go away. with regards KFJ -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: Hugin and focal length multiplier struggle.
Trying to extract the crop factor (or other lens- or camera-specific information) from the EXIF data can be straightforward, but it may as well be difficult or impossible, depending on the work flow. I have had my issue with the lens data, where I couldn't get enough EXIF information into the images to make hugin detect that I was using a stereographic lens. My proposition was to use the information in the EXIF tag 'LensModel' to pick a specific lens .ini file. Since properties like the crop factor are gleaned from the lens .ini file, this would solve the issue. It seems my proposal hasn't elicited any interest whatsover, though :( - have a look at http://groups.google.com/group/hugin-ptx/browse_thread/thread/cf6bba0d7babb4a5# (I hope that's the right way to refer to another thread - In case it's not, the heading is 'feature proposal: let hugin use the LensModel EXIF tag') with regards KFJ -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: smarter undo/redo
On September 24, 2010 01:48:55 am T. Modes wrote: I thinks, that no good idea. The first approach should work better. OK, will do the first approach. Is it OK if I commit it? Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Re: Selecting and moving multiple images in Hugin's Image Tab.
On September 24, 2010 01:50:22 am T. Modes wrote: That's the same patch as in http://groups.google.com/group/hugin-ptx/browse_thread/thread/dfd4cc8affbfd c39 I answered there. oh, I thought it was an improvement based on your thorough and helpful feedback. sorry Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Film
Thanks, Carl. On September 24, 2010 01:46:08 am Carl von Einem wrote: Eric is right, it's about the dynamic range of negatives vs. positive You taught me sonething. I always thought they had the same characteristics... To put it the other way round: is there a reason why you would prefer slide film over negs if we put away all digital cameras for a moment? ... and that the difference was made by the output medium (paper vs. light). My reason to prefer slides over negatives for my silver-based photography back in the time was the size and vibrance of a projection compared with the small size, environmental impact, and relatively less vibrant sight of a printed negative. Nothing to do with stitching. A lot to do with available wall space. And with money too - I'd be bankrupt had I printed my selected slide show on Ilfochrome. I first came to slides when I got introduced to underwater photography. Then I used one roll of slides on land and was immediately sold. Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Re: smarter undo/redo
On September 24, 2010 02:28:15 am Kornel Benko wrote: I like this idea. Something numbered, so one could remember the history number. I doubt most users are as diligent as you, Kornel. I for instance would not be able to remember the history number, but I like to read something descriptive like in the browser history. It's on my todo list for after the initial committ. another feature I am looking into is saving the whole history with the project file. Because the outcome of the optimization process is very much dependent from the initial positioning of the images, access to the whole history of the project can be helpful when fine tuning the individual images. This too, but it looks like a difficult thing over sessions. The accessible history would be this session only. I think already now the whole session history is accessible. What I need is the whole history across sessions (think: working on 100+ images over sessions. I may be overlooking something, but I have an idea that may work: serializing the whole PanoMemento and saving it. Reloading it and replaying it. Probably in a separate file (.pto.mem?). Have to check how it will interact with loading the .pto file, although if every step of the way is in PanoMemento, maybe it will even make the .pto file redundant for this kind of load operation. We'll see, hopefully around Christmas time. Yuv Yuv Kornel signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Re: Hugin and focal length multiplier struggle.
Hi Henk, On September 24, 2010 04:55:22 am Henk Tijdink wrote: I am not sure I understand this statement. Is there an issue with files saved from canon zoom browser when they are loaded into Hugin? Yes there is an issue with olympus jpegs processed in the Canon zoom browser. When checking the EXIF after processing the focal length isn't in it. oh - I suspect that Canon Zoom Broser is completely oblivious to EXIF variations other than Canon's own (which in this area happens to be more standard conforming than Olympus). Hugin was oblivious this way too until I took it up as an exercise and fixed it (easy). Although I am not sure about asking Canon to apply the same easy fix. They will probably prefer you replace your Olympus camera with a Canon camera... Perhaps in the future a possibility that the user feeds his own camera and multiplying value for them in Hugin? that's what the lens' INI files are for. If I understand your well detailed account of how you used PTAssembler and would like to use Hugin, you would like an option to skip the manuall loading of the lens file. There might different ways to save you the time of loading a lens file, but all I can think of will be based on assumptions that you, the user, have to validate (which is what you did when you modified the hard-coded values in PTAssembler's text file. It would be relatively easy to produce a hack that *blindly* overrides the multiplier (which is the only value you want to change if I understand correctly) from the preferences. A slightly more difficult one would be to provide multiple multipliers for a few manually entered cameras based on the EXIF model tag. Is this what you originally asked for? As long as it is not expected for the database to be provided with Hugin, but manually and deliberately entered by an *advanced* user, I think this is feasible. The best solution would be, of course, for camera manufacturers to comply with the same standard. Try talking with Olympus... Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Re: Hugin and focal length multiplier struggle.
Hi KFJ, On September 24, 2010 06:04:38 am kfj wrote: My proposition was to use the information in the EXIF tag 'LensModel' to pick a specific lens .ini file. Sorry, I completely had overseen that thread :( Yes, could make sense. Do you feel comfortable enough with Hugin's codebase to start giving it a try? You'll find plenty of mentorship here. http://groups.google.com/group/hugin-ptx/browse_thread/thread/cf6bba0d7babb 4a5# (I hope that's the right way to refer to another thread yes it. in the meantime, I don't know why I have not thought of it first. A workaround for Henk would be to do exiftool -TagsFromFile original.raw converted.jpg works on Linux/Mac/Windows and restores the originally working EXIF tags. A finer grained selection of tags is possible too. Yuv signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Film
Projection is still best with slides, true. Have to visit Rollei at the Photokina on Saturday :-) Cheers, Carl Yuval Levy schrieb am 24.09.10 13:35: Thanks, Carl. On September 24, 2010 01:46:08 am Carl von Einem wrote: Eric is right, it's about the dynamic range of negatives vs. positive You taught me sonething. I always thought they had the same characteristics... To put it the other way round: is there a reason why you would prefer slide film over negs if we put away all digital cameras for a moment? ... and that the difference was made by the output medium (paper vs. light). My reason to prefer slides over negatives for my silver-based photography back in the time was the size and vibrance of a projection compared with the small size, environmental impact, and relatively less vibrant sight of a printed negative. Nothing to do with stitching. A lot to do with available wall space. And with money too - I'd be bankrupt had I printed my selected slide show on Ilfochrome. I first came to slides when I got introduced to underwater photography. Then I used one roll of slides on land and was immediately sold. Yuv -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: hugin blues
On September 24, 2010 05:34:05 am kfj wrote: special thanks to Yuval Levy, you have really made an effort to work things out for me so I can take heart, get over my frustration and maybe end up doing something productive. happy to read my words were helpful to you. I am sure you will do something productive, whether with PTgui, Hugin, or whatever other software you will apply your brains to. I'm well willing to struggle up the learning curve to get things working. And I'll look into what I can do to make the problems that bug me go away. You're already on the right path. Fire up questions to this list, you'll often get help and advice from people who have been there done that. Even if you're going to unchartered territories, you'll get help and support along the way, as you can witness in your recent thread about building libpano on MinGW. Yuv signature.asc Description: This is a digitally signed message part.
[hugin-ptx] Re: hugin blues
Carl, I've just checked the last Hugin image I installed, which was hugin- mac-2010-1.0.0 from early June. I know from the list that things have changed since then so perhaps I should give Hugin another try, when I have some spare moments. On Sep 24, 1:05 pm, Yuval Levy goo...@levy.ch wrote: On September 24, 2010 05:34:05 am kfj wrote: special thanks to Yuval Levy, you have really made an effort to work things out for me so I can take heart, get over my frustration and maybe end up doing something productive. happy to read my words were helpful to you. I am sure you will do something productive, whether with PTgui, Hugin, or whatever other software you will apply your brains to. I'm well willing to struggle up the learning curve to get things working. And I'll look into what I can do to make the problems that bug me go away. You're already on the right path. Fire up questions to this list, you'll often get help and advice from people who have been there done that. Even if you're going to unchartered territories, you'll get help and support along the way, as you can witness in your recent thread about building libpano on MinGW. Yuv signature.asc 1KViewDownload -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: building hugin 2010.2.0 with minGW
On 24 sep, 04:17, Yuval Levy goo...@levy.ch wrote: On September 23, 2010 10:03:32 am kfj wrote: Having finally managed to build libpano and collateral software using minGW and msys, [...] AFAIK yours is the only recent success at building anything related to Hugin with MinGW. More power to you. Does building libpano13 using the mingw-cross-env cross building environment [0] count? I've successfully built APSC for Windows from a Ubuntu virtual machine last week. This required only very little manual intervention: libpano13: - enable PPM support for MINGW target, to prevent linker errors later on. This should probably go into Makefile.am, but I edited the already generated Makefile.in instead, which was faster. Is there a reason why PPM support was disabled in the first place? - sys_win.h includes WINDOWSX.H (all uppercase), but the file is called windowsx.h (all lowercase) when using mingw-cross-env. Not sure if this is specific to mingw-cross-env. - some tweaks specific to mingw-cross-env for file naming and usage of tools, handled by mingw-cross-env. APSC: - manually edited the order of inclusion of libraries, since I couldn't get (the cross build) GCC to work with the automatically generated, but improper order. I don't know of any way to correct the order using CMake? Of is there a GCC option I missed to instruct the linker to search for symbols in all libs provided on the command line? The PPM tweak for libpano13 is on its way into the mingw-cross-env sources and will work with the current libpano13 release, the other tweaks were already included. Probably it should be fixed in libpano13 itself though, and maybe also the uppercase/lowercase fix, is it's not mingw-cross-env specific. [0] http://mingw-cross-env.nongnu.org/#packages -- Bart -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: building hugin 2010.2.0 with minGW
I have started trying to get everything together I need for my hugin/ minGW attempt. This worked fine until I came to try and compile the OpenEXR code [typically this was the last biggish packet on the list]. This code seems to depend on another library, ilmbase. Now ilmbase won't compile until it has POSIX threads. I downloaded pthreads-w32 and tried to coax the libilm configure into accepting pthread-w32's output, but to no avail. I keeps telling me that checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... no checking whether pthreads work with -mthreads... no checking for the pthreads library -lpthread... no checking whether pthreads work with --thread-safe... no checking whether pthreads work with -mt... no checking for pthread-config... no configure: error: POSIX thread support required and fails. My coaxing went so that I made some links from pthread- w32's output to where I think libilm should expect to find them: ln pthreadGC2.dll /usr/local/lib/pthread.dll ln libpthreadGC2.a /usr/local/lib/libpthread.a for good measure, I also put links into the other /lib and /bin directories, but to no avail... Alternatively, I tried to compile the libilm code without threading, by configuring it like: ./configure --enable-threading=no --disable-posix-sem which at least makes the configure run through, but then subsequently the make fails. Has anyone been there? and then done what? momentarily stalled KFJ -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: Hugin and focal length multiplier struggle.
On Sep 24, 1:58 pm, Yuval Levy goo...@levy.ch wrote: Yes, could make sense. Do you feel comfortable enough with Hugin's codebase to start giving it a try? You'll find plenty of mentorship here. Definitely not [yet ;) ]. Currently I am struggling to compile hugin on my system with what compiler I have (minGW, I've started a thread about this effort). I might consider downloading and installing and even registering MSVC since everyone tells me it's the standard thing to compile hugin with - just so I can actually work on the code rather than struggling with third party libraries (currently wrestling with OpenEXR), but I am reluctant. I'll think about it. I just worry! What if they change their license to something like 'all software you compile with our product is now our possession which you may only use until we forbid you to do so; if you link with our libs, you must pay license fees, etc. etc.' - or if the next version of it suddenly isn't free anymore? minGW is open source free software, so I feel safe using it. My exif:LensModel - lens.ini proposal (which went unnoticed) was the reason I wanted to look into the code after all, because I thought this could be implemented with little effort... in the meantime, I don't know why I have not thought of it first. A workaround for Henk would be to do exiftool -TagsFromFile original.raw converted.jpg There are pitfalls in just plain transferring all tags from a raw file to the target JPEG, since some things actually change in the 'development' process. Safer to only copy carefully selected tags to the JPEG file, like the hugin workflow does. A finer grained selection of tags is possible too. ... so I think it's not only possible but necessary with regards KFJ -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: Windows hugin-2010.2.0_rc1 Build
I've made the effort to actually uninstall and delete whatever bit of hugin I could track down, including installation directories and start menu entries, on my Windows system, to try and make a fresh install with no relics from previous installations. Then I installed into a new path. Again I asked for all CPGs to be installed, and the installation dialog said it was downloading them. But the same CPG omissions I noticed earlier still apply. If the new stuff is just installed over a current installation, all the old CPGs will still be there, so the problem might not manifest. Of course it might be that the missing CPGs are actually downloaded to somewhere where I can't find them, but I couln't find them anywhere :( I also noticed that I could not get rid od my old CPG settings, and I have no idea where they are actually stored. In the registry perhaps? I would have liked to get rid of them before doing my install-to-a- clean-state attempt. The newly installed CPGs and the CPG settings (also for the missing ones) produce problems on my system. match-n-shift won't run - now this may be because I don't have ImageMagick installed, but the version that the installer installs does not know the -m (nomagick) flag. If I replace it with m-n-s from my previous install, it runs, if I give it the right autopano to work with. And what about the -a and - b flags? What are they for? As far as autopano is concerned, there is a name conflict here with autopano by A. Jenny and autopano by S. Nowozin, which is a different thing altogether. A. Jenny's is used as standalone CPG, whereas Nowozin's is used with existing .key files (like in conjunction with generatekeys), if my understanding is correct. And the settings for autopano-sift-c include '--projection %f,%v', which does not work with the autopano-sift-c.exe I took from my previous installation [version 2.5.2] (since the installer didn't actually install it). Now that I have all the (old) CPGs together again, the new hugin runs well and only occasionally crashes (sometimes after using panomatic, but I can't figure out when and when not) - so far I haven't found anything crucially wrong with it. But I think the CPG deployment needs some finetuning ;) with regards KFJ -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: smarter undo/redo
Hi Yuv, I thinks, that no good idea. The first approach should work better. OK, will do the first approach. Is it OK if I commit it? It's ok. Thomas -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Film
On Friday, September 24, 2010 04:35:43 am Yuval Levy wrote: Thanks, Carl. On September 24, 2010 01:46:08 am Carl von Einem wrote: Eric is right, it's about the dynamic range of negatives vs. positive You taught me sonething. I always thought they had the same characteristics... Slide film has about an 8 stop dynamic range depending on the particular film. This is very similar to what we see with digital cameras although some may have a wider dynamic range. With color negative film this can be as much as 20 stops and most are at least 15 stops. This is a distinct advantage when shooting panos that have things like the sun and deep shadows in the same scene. In other words by default negative film is an HDR medium if it is used correctly (IE. expose for the shadows). On the other hand slide film generally has a better (IE. finer) grain structure and as a result tends to have better detail if the cameras glass is good enough. But for me the real bummer with slide film is that Kodachrome is no longer available and the last place that processed it just closed down a few months ago. To put it the other way round: is there a reason why you would prefer slide film over negs if we put away all digital cameras for a moment? ... and that the difference was made by the output medium (paper vs. light). My reason to prefer slides over negatives for my silver-based photography back in the time was the size and vibrance of a projection compared with the small size, environmental impact, and relatively less vibrant sight of a printed negative. Nothing to do with stitching. A lot to do with available wall space. And with money too - I'd be bankrupt had I printed my selected slide show on Ilfochrome. I first came to slides when I got introduced to underwater photography. Then I used one roll of slides on land and was immediately sold. Yuv -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: Hugin and focal length multiplier struggle.
On Fri 24-Sep-2010 at 03:04 -0700, kfj wrote: Trying to extract the crop factor (or other lens- or camera-specific information) from the EXIF data can be straightforward, but it may as well be difficult or impossible, depending on the work flow. I have had my issue with the lens data, where I couldn't get enough EXIF information into the images to make hugin detect that I was using a stereographic lens. My proposition was to use the information in the EXIF tag 'LensModel' to pick a specific lens .ini file. Since properties like the crop factor are gleaned from the lens .ini file, this would solve the issue. It seems my proposal hasn't elicited any interest whatsover, though :( - have a look at http://groups.google.com/group/hugin-ptx/browse_thread/thread/cf6bba0d7babb4a5# I intended to follow this up, but have been all over the place. Yes, Hugin ought to be able to match EXIF data with saved lens profiles, this was the reason why the .INI files actually contain some data scraped from the EXIF - Though we never got around to doing anything with it. There is also lensfun, which is a lens database and library: http://lensfun.berlios.de/ One of the reasons lensfun was started was so Hugin could use it exactly as you described and we would lose the .INI files altogether. Unfortunately nobody has had the time to do the Hugin integration yet, but it is used by some RAW conversion software already. There is also a 'proof of concept' tool called lens-submit that can extract calibration and EXIF data directly from .pto projects and submit them to a central server: http://search.cpan.org/dist/Panotools-Script/bin/lens-submit http://comments.gmane.org/gmane.comp.misc.ptx/21536 -- Bruno -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] External panorama file format - Adobe pmg
Hi, Does anyone heare have a clue about the adobe photomerge file format for panoramas? The suffix is pmg for these files. I would be interested to look at a conversion... Cheers O -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: External panorama file format - Adobe pmg
Hullo Oskar, On Sep 25, 5:03 am, Oskar Sander oskar.san...@gmail.com wrote: Hi, Does anyone heare have a clue about the adobe photomerge file format for panoramas? The suffix is pmg for these files. I would be interested to look at a conversion... A quick snoop about reveals... PMG file is an Adobe Pagemaker Group. Adobe Pagemaker is a decent desktop publishing software program if you want to create a simple desktop publishing publication like a newsletter or a catalog. A PMG file is an EPS graphic that contains bot a low resolution, bitmap version of the image for display on screen and the PostScript information needed to print at highresolution to a PostScript printer. If this is indeed the same file format you refer to, then it should be able to be read by GhostScript and the like. I also found a reference to .pmg as paint image magic file format, which I think goes back to the days of the Commodore 64! Cheers, Terry -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] New mosaic mode tutorial
Hullo All, I have uploaded a new tutorial [0] to the website which explains the basics of mosiac mode in stitching a mural. It also shows how parallax can be used to remove unwanted objects in front of the subject mural which may be blocking a clear view. A link has been provided to Yuval's mosiac mode tutorial. [0] http://hugin.sourceforge.net/tutorials/Mosaic-mode/en.shtml Cheers, Terry -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: Windows hugin-2010.2.0_rc1 Build
Here is a new installer based on the latest script: http://www.box.net/shared/hnf7vgtjp2 All of the control point generators should install properly now. All of them work properly for me on a clean install except match-n- shift. When selected, hugin runs PTmender instead, but I can't figure out why. On Sep 24, 11:24 am, kfj _...@yahoo.com wrote: I also noticed that I could not get rid od my old CPG settings, and I have no idea where they are actually stored. In the registry perhaps? Control point generator settings are stored in the registry. To remove them you had to check Clean Registry Settings when you ran the uninstaller. I also made changes to Panomatic.nsh in order to take advantage of SourceForge mirrors. A random mirror from a list of ten is chosen for the download of Panomatic, and if it fails the other mirrors are tried until one works. In addition, I changed HuginSetup_common.nsh to set the default control point generator to one of the ones the installer downloads, if it does so. These changes are available here: http://www.box.net/shared/b8gg663s0g Matthew On Sep 24, 11:24 am, kfj _...@yahoo.com wrote: I've made the effort to actually uninstall and delete whatever bit of hugin I could track down, including installation directories and start menu entries, on my Windows system, to try and make a fresh install with no relics from previous installations. Then I installed into a new path. Again I asked for all CPGs to be installed, and the installation dialog said it was downloading them. But the same CPG omissions I noticed earlier still apply. If the new stuff is just installed over a current installation, all the old CPGs will still be there, so the problem might not manifest. Of course it might be that the missing CPGs are actually downloaded to somewhere where I can't find them, but I couln't find them anywhere :( I also noticed that I could not get rid od my old CPG settings, and I have no idea where they are actually stored. In the registry perhaps? I would have liked to get rid of them before doing my install-to-a- clean-state attempt. The newly installed CPGs and the CPG settings (also for the missing ones) produce problems on my system. match-n-shift won't run - now this may be because I don't have ImageMagick installed, but the version that the installer installs does not know the -m (nomagick) flag. If I replace it with m-n-s from my previous install, it runs, if I give it the right autopano to work with. And what about the -a and - b flags? What are they for? As far as autopano is concerned, there is a name conflict here with autopano by A. Jenny and autopano by S. Nowozin, which is a different thing altogether. A. Jenny's is used as standalone CPG, whereas Nowozin's is used with existing .key files (like in conjunction with generatekeys), if my understanding is correct. And the settings for autopano-sift-c include '--projection %f,%v', which does not work with the autopano-sift-c.exe I took from my previous installation [version 2.5.2] (since the installer didn't actually install it). Now that I have all the (old) CPGs together again, the new hugin runs well and only occasionally crashes (sometimes after using panomatic, but I can't figure out when and when not) - so far I haven't found anything crucially wrong with it. But I think the CPG deployment needs some finetuning ;) with regards KFJ -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: hugin blues
Hi, I am using Hugin for almost 2 years time now. I stick with hugin because its free. Its open source but I think this feature is for developers. i am just a normal end user. Over the period of time I have used Autopano and PTGUI. Hugin is free but you have to pay the price of working hard in learning it :) Major difference between hugin and other softwares is for normal users. Normal user will not want to go and add %p %o %s in autopano-sift parameters for multirow pano. He will want to just load pics and get pano :) I have experienced hugin growing and adding lots of features in these two years. I have learnt hugin by posting my issues on this group and there are lots of people to help you out. Hugin is Opensoure hope in panoramic photography. I am with hugin and I hope in one year time it will at par with commercial softwares. I am a windows user and I feel there is lack of technical resource person for windows users. Most of hugin team is not using windows. Thats why it creates issues. Is there anyone looking after windows builds that they are accurate and uptodate? or we have to shift to Ubuntu lolzzz On Fri, Sep 24, 2010 at 5:37 PM, Gareth p...@jonestheweb.com wrote: Carl, I've just checked the last Hugin image I installed, which was hugin- mac-2010-1.0.0 from early June. I know from the list that things have changed since then so perhaps I should give Hugin another try, when I have some spare moments. On Sep 24, 1:05 pm, Yuval Levy goo...@levy.ch wrote: On September 24, 2010 05:34:05 am kfj wrote: special thanks to Yuval Levy, you have really made an effort to work things out for me so I can take heart, get over my frustration and maybe end up doing something productive. happy to read my words were helpful to you. I am sure you will do something productive, whether with PTgui, Hugin, or whatever other software you will apply your brains to. I'm well willing to struggle up the learning curve to get things working. And I'll look into what I can do to make the problems that bug me go away. You're already on the right path. Fire up questions to this list, you'll often get help and advice from people who have been there done that. Even if you're going to unchartered territories, you'll get help and support along the way, as you can witness in your recent thread about building libpano on MinGW. Yuv signature.asc 1KViewDownload -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.comhugin-ptx%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- *Emaad* www.flickr.com/emaad -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
