Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
Am Samstag, 19. Januar 2013 um 09:37:52, schrieb T. Modes
> @Kornel
> >
> > Good point. We could make it depend on
> > find_program(PYTHON_EXE python3 python)
> >
>
> Then you prefer Python3 before 2.x. And selecting a 2.x serie with
> installed 3.x will not be possible.
Yes.
> FindPythonLib and FindPythonInterpr handle both series. This is not
> the case with your approach.
I don't know FindPythonInterpr. Ähm, now I see FindPythonInterp.cmake. This is
nice.
So
find_package(PythonInterp REQUIRED) #gives
PYTHON_EXECUTABLE + PYTHON_VERSION_STRING
find_package(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED)
would do?
> Also your approach will fail, if python is not in the path environment
> variable. FindPythonIntpr handle also this case.
I don't see it. If python is not on system path also FindPythonIntp fails.
But it handles more cases, so I prefer it too.
> So I think the
> approach with the switch at the command line is working for the time
> being.
But the opportunity to set it now correctly is good IMHO. And setting
-DPYTHON_EXECUTABLE=... -DPythonLibs_FIND_VERSION=...
were still possible.
> @Harry
> The CMake GUI can also generate project files for different IDE (MSVC,
> KDevelop, CodeBlocks, XCode, ...) and also for makefile. So starting
> the build process from the CMake GUI would be complicated and needed
> to adopt to all different IDE. I don't know if all IDE support this
> approach. So from this point of view I understand that they did not
> add this feature to the GUI.
>
> Thomas
>
Kornel
signature.asc
Description: This is a digitally signed message part.
[hugin-ptx] Re: Fisheye lens do not present circular projection on my cellphone
Thank you very much. The labels on these products are circular images. I think they are designed as circular fisheye lens, but since their interface circles are larger than the cellphone camera interface circles, we can only see one part, which presents like a frame fisheye lens. But now how can I tell what fisheye lens on the market can have a right interface circle so that I can see the whole circular image on the camera of the cellphone? They are misleading. Or I add another add-on to make the interfaces match? On Friday, January 18, 2013 4:49:40 PM UTC-6, JohnPW wrote: > > I have no experience with fisheye lenses, but . . . > A) Indeed, they *are* designed this way. Fisheye lenses are either > "circular" (a full 180º circular projection) or "full frame" (where the > image circle is enlarged [and effectively cropped] to fill the full image > area.) This is generally what most people want [except for us Hugin users, > who pursue that very wide angle!]) > > B) I don't know for certain, but I highly doubt there is any way to make a > full frame lens produce a circular effect (although going the other way is > easy—just crop.) > > C) Not familiar with your lenses, but if they are cellphone add ons, you > will probably have to use different de-skewing calculations each time you > use them (I doubt they fit on the phone in a consistently reproducible way.) > > D) If I'm wrong on any of this, I'm sure someone will soon correct me very > soon. ;-) > > John > > On Thursday, January 17, 2013 6:33:34 PM UTC-6, Linda Li wrote: >> >> I have three fisheye lens (two from SKINA digital technology Co., one >> from pixeet). >> >> After anyone of them is attached to my phone (sprint HTC), I am >> disappointed to find that it presents a fullframe projection, rather than >> circular projection. >> >> >> Apparently fullframe projection has a less wide angle view than circular >> projection. >> >> First I thought the lens are for fullframe projections. >> >> But after observation, I find the circle of the fisheeye lens is larger >> than the circle of the camera hole. >> >> >> How can I get a circular projection using these fisheye lens? >> >> Or are they designed this way? >> >> -- 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: Fisheye lens do not present circular projection on my cellphone
You are probably right. But they need to point it out on the label or product descriptions. On Saturday, January 19, 2013 12:22:04 AM UTC-6, GnomeNomad wrote: > > My guess is the lens designer's choice was: "Do we give them a tiny > circular image that fits entirely on their phone's little CCD and use > very little of their resolution?" or "Do we give them a full frame that > uses all of their little CCD's resolution?" > > On 01/18/2013 12:49 PM, JohnPW wrote: > > I have no experience with fisheye lenses, but . . . > > A) Indeed, they *are* designed this way. Fisheye lenses are either > > "circular" (a full 180� circular projection) or "full frame" (where > the > > image circle is enlarged [and effectively cropped] to fill the full > > image area.) This is generally what most people want [except for us > > Hugin users, who pursue that very wide angle!]) > > > > B) I don't know for certain, but I highly doubt there is any way to make > > a full frame lens produce a circular effect (although going the other > > way is easy�just crop.) > > > > C) Not familiar with your lenses, but if they are cellphone add ons, you > > will probably have to use different de-skewing calculations each time > > you use them (I doubt they fit on the phone in a consistently > > reproducible way.) > > > > D) If I'm wrong on any of this, I'm sure someone will soon correct me > > very soon. ;-) > > > > John > > > > On Thursday, January 17, 2013 6:33:34 PM UTC-6, Linda Li wrote: > > > > I have three fisheye lens (two from SKINA digital technology Co., > > one from pixeet). > > > > After anyone of them is attached to my phone (sprint HTC), I am > > disappointed to find that it presents a fullframe projection, rather > > than circular projection. > > > > > > Apparently fullframe projection has a less wide angle view than > > circular projection. > > > > First I thought the lens are for fullframe projections. > > > > But after observation, I find the circle of the fisheeye lens is > > larger than the circle of the camera hole. > > > > > > How can I get a circular projection using these fisheye lens? > > > > Or are they designed this way? > > > -- > Gnome Nomad > gnome...@gmail.com > wandering the landscape of god > http://www.clanjones.org/david/ > http://dancing-treefrog.deviantart.com/ > http://www.cafepress.com/otherend/ > -- 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] Where to find images in examples of Hugin Tutorials?
Thank you so much! I will follow these tutorials and then let you know what are missing. Thanks agian! On Friday, January 18, 2013 2:50:47 PM UTC-6, Tduell wrote: > > Hello Linda, > > On Fri, 18 Jan 2013 11:23:32 +1100, Linda Li > > > > wrote: > > > Some Hugin Tutorials (http://hugin.sourceforge.net/tutorials/index.shtml) > > > have images for download so that you could simply follow the instruction > > > in their tutorials. But some don't. > > > > It's a pity. Where to find images in examples of Hugin Tutorials? > Thanks. > > I have edited the web pages to make the images available for the > "Stitching photos from different lenses" and "Stitching flat scanned > images". > A quick look only turned up these two. Are there others? > > Cheers, > -- > Regards, > Terry Duell > -- 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: Enfuse: Trying to use input masks to increase DR
Try to get those files up so we have something to comment on :-) -- 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 stacks pictures to one stack, not 360 degrees as I want
How do the control points look? Look in the quick preview window and check "show control points." It's hard to know what's happening without more information. You should probably post the PTO file. John On Saturday, January 19, 2013 4:18:42 AM UTC-6, moonki...@hotmail.com wrote: > > So, my problem is kinda weird. It doesn't do it on all panoramas I try to > make.. Only to those, that have large room or space to stitch up. > Getting smaller (more detail-rich) panoramas is kinda child's play but I > cannot stitch big rooms together at all. > > Here is one example: > http://filesmelt.com/dl/panorama4.jpg > This panorama is made out of 6 pictures. Four that circle the room, floor > and ceiling pictures. Room itself is shaped as half-circle. Problems come > with floor and ceiling pictures. > > Here is one that I made with 4 pictures, leaving ceiling and floor > pictures away: > http://filesmelt.com/dl/panorama12.jpg > > It looks nice, but there is huge blank spaces at ceiling and floor when we > try to make it a "ball" for viewing. So the panorama is cylindrical. > > What to do to fix this problem? > > -- 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: python 2.7 vs. python 3.2 and compilation errors
@Kornel > > Good point. We could make it depend on > find_program(PYTHON_EXE python3 python) > Then you prefer Python3 before 2.x. And selecting a 2.x serie with installed 3.x will not be possible. FindPythonLib and FindPythonInterpr handle both series. This is not the case with your approach. Also your approach will fail, if python is not in the path environment variable. FindPythonIntpr handle also this case. So I think the approach with the switch at the command line is working for the time being. @Harry The CMake GUI can also generate project files for different IDE (MSVC, KDevelop, CodeBlocks, XCode, ...) and also for makefile. So starting the build process from the CMake GUI would be complicated and needed to adopt to all different IDE. I don't know if all IDE support this approach. So from this point of view I understand that they did not add this feature to the GUI. 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: Re: Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
Am Samstag, 19. Januar 2013 um 16:51:44, schrieb Harry van der Wolf
> 2013/1/19 Kornel Benko
>
> > **
> >
> > Am Samstag, 19. Januar 2013 um 16:37:32, schrieb Harry van der Wolf <
> > hvdw...@gmail.com>
> >
> > > 2013/1/19 Andreas Metzler
> >
> > >
> >
> > > > -DPythonLibs_FIND_VERSION=2.7
> >
> > >
> >
> >
> >
> > We could here change the search for PythonLibs at CMakeLists.txt:314 to
> >
> > FIND_PACKAGE(PythonLibs 2.7 REQUIRED)
> >
> >
> >
> > I know that Mathew Petroff builds his windows packages against python 3.2,
> so I don't think this would be a good idea to do.
> Ubuntu is also working towards python 3.2 where they can and they want it
> to be the standard on the next release.
Good point. We could make it depend on
find_program(PYTHON_EXE python3 python)
if(PYTHON_EXE_FOUND)
execute_process(COMMAND ${PYTHON_EXE} --version OUTPUT_VARIABLE
P_VERS)
if(${P_VERS} MATCHES "Python \([0-9]+\\.[0-9]+[\\.0-9]*\)")
set(SEARCHP_VERS ${CMAKE_MATCH_1})
else()
set(SEARCHP_VERS)
endif()
find_package(PythonLibs ${SEARCHP_VERS} REQUIRED)
else()
message(FATAL_ERROR "Python required")
endif()
> Harry
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
2013/1/19 Kornel Benko > ** > > Am Samstag, 19. Januar 2013 um 16:37:32, schrieb Harry van der Wolf < > hvdw...@gmail.com> > > > 2013/1/19 Andreas Metzler > > > > > > > -DPythonLibs_FIND_VERSION=2.7 > > > > > > > We could here change the search for PythonLibs at CMakeLists.txt:314 to > > FIND_PACKAGE(PythonLibs 2.7 REQUIRED) > > > > I know that Mathew Petroff builds his windows packages against python 3.2, so I don't think this would be a good idea to do. Ubuntu is also working towards python 3.2 where they can and they want it to be the standard on the next release. Harry -- 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: Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
Am Samstag, 19. Januar 2013 um 16:37:32, schrieb Harry van der Wolf > 2013/1/19 Andreas Metzler > > > -DPythonLibs_FIND_VERSION=2.7 > We could here change the search for PythonLibs at CMakeLists.txt:314 to FIND_PACKAGE(PythonLibs 2.7 REQUIRED) > And that also works and is even simpler. Thanks as well. > > (I lost count of all the compilation runs I've done by now) :) > Harry > Kornel signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
2013/1/19 Andreas Metzler > -DPythonLibs_FIND_VERSION=2.7 And that also works and is even simpler. Thanks as well. (I lost count of all the compilation runs I've done by now) Harry -- 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: Re: Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
Am Samstag, 19. Januar 2013 um 15:51:58, schrieb Harry van der Wolf ... > > You cane even start the gui from the build-directory with: > > > > #make edit_cache > > > > > > > Thanks! I learn every day. > > > I will dive into this cmake gui a little more. It might be THE way to build > hugin on OS X with cmake instead of with XCode (and maybe not, but I will > see). > > Harry Since you are on ubuntu, you could also try #cmake ... -DCPACK_BINARY_DEB:BOOL=ON ... #make package #sudo dpkg -i hugin-2012.1.0.6107-Linux.deb Kornel signature.asc Description: This is a digitally signed message part.
Re: Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
2013/1/19 Kornel Benko > ** > > I now used: > > > cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 > > > -DCMAKE_BUILD_TYPE=RelWithDebInfo > > > -DPYTHON_INCLUDE_DIR="/usr/include/python2.7" > > > -DPYTHON_LIBRARY="/usr/lib/libpython2.7.so.1" > > > -DPYTHON_EXECUTABLE="/usr/bin/python2 > > > > I am curious, why '-DSWIG_EXECUTABLE=/usr/bin/swig2.0' is needed? > > In CMakeLists.txt:341, we already search for swig > > find_program(SWIG_EXECUTABLE NAMES swig2.0 swig) > > It isn't neccessary and neither is the -DBUILD_HSI:BOOL=ON as that's default on linuxes. It's still my old habit from Mac OS X where I had to specify almost every command flag and environment flag (like -DCMAKE_C_FLAGS_RELEASE:STRING="..") in existence when building with cmake. > > > > This compiles fine. > > > > > > The following also compiles and builds fine. > > > cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 > > > -DCMAKE_BUILD_TYPE=RelWithDebInfo > > > -DPYTHON_INCLUDE_DIR="/usr/include/python3.2" > > > -DPYTHON_LIBRARY="/usr/lib/libpython3.2mu.so.1" > > > -DPYTHON_EXECUTABLE="/usr/bin/python3" > > > > > > > > > > > > 2013/1/19 T. Modes > > > > > > > Use the GUI. There is see all parameters/options and can change them > > > > easily (much much easily IMHO than on the command line). > > > > > > > > > > > > > I didn't even know there was a gui. > > > > You cane even start the gui from the build-directory with: > > #make edit_cache > > > Thanks! I learn every day. I will dive into this cmake gui a little more. It might be THE way to build hugin on OS X with cmake instead of with XCode (and maybe not, but I will see). Harry -- 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: Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
Am Samstag, 19. Januar 2013 um 15:20:03, schrieb Harry van der Wolf > 2013/1/19 T. Modes > > > > > Below the variables you will need are mentioned: > > # If you'd like to specify the installation of Python to use, you > > should modify > > # the following cache variables: > > # PYTHON_LIBRARY - path to the python library > > # PYTHON_INCLUDE_DIR - path to where Python.h is found > > > > Maybe you need also specify (FindPythonInterp) > > # PYTHON_EXECUTABLE - path to the Python interpreter > > to select the matching Python interpreter. > > > > Thomas > > > > > Thanks. > I now used: > cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 > -DCMAKE_BUILD_TYPE=RelWithDebInfo > -DPYTHON_INCLUDE_DIR="/usr/include/python2.7" > -DPYTHON_LIBRARY="/usr/lib/libpython2.7.so.1" > -DPYTHON_EXECUTABLE="/usr/bin/python2 I am curious, why '-DSWIG_EXECUTABLE=/usr/bin/swig2.0' is needed? In CMakeLists.txt:341, we already search for swig find_program(SWIG_EXECUTABLE NAMES swig2.0 swig) > This compiles fine. > > The following also compiles and builds fine. > cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 > -DCMAKE_BUILD_TYPE=RelWithDebInfo > -DPYTHON_INCLUDE_DIR="/usr/include/python3.2" > -DPYTHON_LIBRARY="/usr/lib/libpython3.2mu.so.1" > -DPYTHON_EXECUTABLE="/usr/bin/python3" > > > > 2013/1/19 T. Modes > > > Use the GUI. There is see all parameters/options and can change them > > easily (much much easily IMHO than on the command line). > > > > > I didn't even know there was a gui. You cane even start the gui from the build-directory with: #make edit_cache > It doesn't give me options for PYTHON* > unless I set the "advanced" checkbox. So after configure/generate the unix > makefiles are generated. > And then I need to leave to gui to run make: how weird! The gui is only a wrapper for the cmake-call with all the params. > I know you use cmake to configure and then make to make but why not a > complete gui? Coming from Mac OS X, with a no doubt excellent user-friendly > design, such a gui design decision is for me utter nonsence. > Anyway: the gui does the job correctly as well and when running make > (actually make -j 3), the job gets done correctly. > > Now that I've found the correct settings I will update the wiki ( > http://wiki.panotools.org/Hugin_Compiling_Ubuntu) for mixed environments > like I curently have. > ... > Harry Kornel signature.asc Description: This is a digitally signed message part.
Re: [hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
2013/1/19 T. Modes > > Below the variables you will need are mentioned: > # If you'd like to specify the installation of Python to use, you > should modify > # the following cache variables: > # PYTHON_LIBRARY - path to the python library > # PYTHON_INCLUDE_DIR - path to where Python.h is found > > Maybe you need also specify (FindPythonInterp) > # PYTHON_EXECUTABLE - path to the Python interpreter > to select the matching Python interpreter. > > Thomas > Thanks. I now used: cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPYTHON_INCLUDE_DIR="/usr/include/python2.7" -DPYTHON_LIBRARY="/usr/lib/libpython2.7.so.1" -DPYTHON_EXECUTABLE="/usr/bin/python2 This compiles fine. The following also compiles and builds fine. cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPYTHON_INCLUDE_DIR="/usr/include/python3.2" -DPYTHON_LIBRARY="/usr/lib/libpython3.2mu.so.1" -DPYTHON_EXECUTABLE="/usr/bin/python3" 2013/1/19 T. Modes > Use the GUI. There is see all parameters/options and can change them > easily (much much easily IMHO than on the command line). > I didn't even know there was a gui. It doesn't give me options for PYTHON* unless I set the "advanced" checkbox. So after configure/generate the unix makefiles are generated. And then I need to leave to gui to run make: how weird! I know you use cmake to configure and then make to make but why not a complete gui? Coming from Mac OS X, with a no doubt excellent user-friendly design, such a gui design decision is for me utter nonsence. Anyway: the gui does the job correctly as well and when running make (actually make -j 3), the job gets done correctly. Now that I've found the correct settings I will update the wiki ( http://wiki.panotools.org/Hugin_Compiling_Ubuntu) for mixed environments like I curently have. And then on to the stuff I did this for: updating the manual based on the latest gui status. Harry -- 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: python 2.7 vs. python 3.2 and compilation errors
Harry van der Wolf wrote: > On Ubuntu 12.1- Quantal I'm trying to compile the latest tip of hugin > (6102:1f205fefbcd7 tip). I'm on Ubuntu 12.10 having a mix of python 2.7 and > python 3.2. I need both and so does Ubuntu itself currently. > I started to use from my build directory the following command: > cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 > -DCMAKE_BUILD_TYPE=RelWithDebInfo [...] > Again a mix and match and again the same compilation error meaning that > 2.7.3 and 3.2 are still mixed up. [...] For Debian's official packages we are using -DPythonLibs_FIND_VERSION=2.7 cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- 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] Enfuse: Trying to use input masks to increase DR
I've been using enfuse for a while trying to maximise dynamic range from 35mm slide scans. I usually do an exposure weighted fusion of 2 scans from the same slide, one exposed for shadows, and the other for highlights. I'm always trying to improve my results, and have noticed that, no matter what I do, the shadows are always slightly darker than the lighter scan, and the highlights always slightly lighter than the darker scan. I always put this down to having to use the Gaussian distributon to describe the exposure weighting. With the recent introduction of the option to use input masks, I had another go at looking a this. Test 1a: (lighter scan + white mask) fused with (darker scan + black mask) = lighter scan Test 1b: (lighter scan + black mask) fused with (darker scan + white mask) = darker scan Both as expected Test 1c: (lighter scan + half white/half black mask) fused with (darker scan + half black/half white mask) = lighter scan Test 1d: (lighter scan + half black/half white mask) fused with (darker scan + half white/half black mask) = darker scan Expected there to be some combination of the lighter and darker scans here. Confused. Test 2: (lighter scan + mostly black with white box mask) fused with (darker scan + inverse mask) = Mostly darker scan with complete area to the right of the box in the mask from the lighter scan Expected mostly darker scan with lighter scan area confined to mask box. See fused.zip Test 3; (lighter scan + custom mask1) fused with (darker scan + custom mask2) = Attempt to more seriously combine best of both scans. Does produce a reasonable fused result, but the shadows are still darker than the lighter scan. The highlights are still lighter than the darker scan. See fused.zip Can anyone provide any insight into why the simpler tests produce these results? With test 3, even with custom selection of the required parts of the input scans, it still doesn't seem possible to improve on the results produced using the gaussian exposure weighting function. Is there an inherent reason in the algorithm for this. My understanding of what happens after the weight assignment is minimal. Tried to attach zipped files (6MB), but they seem to make post disappear. Maybe there is a size limit? Thanks Ken -- 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] Hugin stacks pictures to one stack, not 360 degrees as I want
So, my problem is kinda weird. It doesn't do it on all panoramas I try to make.. Only to those, that have large room or space to stitch up. Getting smaller (more detail-rich) panoramas is kinda child's play but I cannot stitch big rooms together at all. Here is one example: http://filesmelt.com/dl/panorama4.jpg This panorama is made out of 6 pictures. Four that circle the room, floor and ceiling pictures. Room itself is shaped as half-circle. Problems come with floor and ceiling pictures. Here is one that I made with 4 pictures, leaving ceiling and floor pictures away: http://filesmelt.com/dl/panorama12.jpg It looks nice, but there is huge blank spaces at ceiling and floor when we try to make it a "ball" for viewing. So the panorama is cylindrical. What to do to fix this problem? -- 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: Crop of orthographic images - incompatible change?
No comment on this?? Then I will commit the changes. On 12 Jan., 12:08, "T. Modes" wrote: > Hi all, > > I tested Hugin with orthographic images. I already fixed some issues. > But for orthographic images a circular crop is better suited (because > of the limit of hfov to 180 deg -> circular image). Currently Hugin is > using a rectangular crop. I have already a patch. > But this will introduce an incompatibility with project files created > with older version (this affects only the crop of orthographic input > images). > Are there objection against this change? Is somebody using > orthographic images with rectangular crop? > > 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
[hugin-ptx] Re: python 2.7 vs. python 3.2 and compilation errors
On 19 Jan., 09:05, Harry van der Wolf wrote: > And another question: > In the automake/configure time you just did a "./configure --help" to get > all the command flag options for your binary/library. > > I have been searching far and wide for the same command for cmake, but I > can't find. > Of course I can search the CMakeListst.txt to check all OPTIONs, but a > neat and simple command would be so much easier. > Anyone who knows? Use the GUI. There is see all parameters/options and can change them easily (much much easily IMHO than on the command line). -- 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: python 2.7 vs. python 3.2 and compilation errors
Hi Harry, On 18 Jan., 19:15, Harry van der Wolf wrote: > So according to the CMakeLists.txt I did: > cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 > -DCMAKE_BUILD_TYPE=RelWithDebInfo > -DPYTHON_INCLUDE_PATH="/usr/include/python2.7" > -DPYTHON_INCLUDE_DIRS="/usr/lib/python2.7" > Why do you think, that supplying the path to the lib to the include dirs will help ;-) >From FindPythonLibs # PYTHON_LIBRARIES - path to the python library # PYTHON_INCLUDE_PATH- path to where Python.h is found (deprecated) # PYTHON_INCLUDE_DIRS- path to where Python.h is found But these paths are returned from FindPythonLibs. Below the variables you will need are mentioned: # If you'd like to specify the installation of Python to use, you should modify # the following cache variables: # PYTHON_LIBRARY - path to the python library # PYTHON_INCLUDE_DIR - path to where Python.h is found Maybe you need also specify (FindPythonInterp) # PYTHON_EXECUTABLE - path to the Python interpreter to select the matching Python interpreter. 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] python 2.7 vs. python 3.2 and compilation errors
And another question: In the automake/configure time you just did a "./configure --help" to get all the command flag options for your binary/library. I have been searching far and wide for the same command for cmake, but I can't find. Of course I can search the CMakeListst.txt to check all OPTIONs, but a neat and simple command would be so much easier. Anyone who knows? -- 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] python 2.7 vs. python 3.2 and compilation errors
2013/1/19 Bruno Postle > On Fri 18-Jan-2013 at 19:15 +0100, Harry van der Wolf wrote: > >> >> Being such an extemely flexible guy I just switched to: >> cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/**swig2.0 >> -DCMAKE_BUILD_TYPE=**RelWithDebInfo >> -DPYTHON_INCLUDE_PATH="/usr/**include/python3.2" >> -DPYTHON_INCLUDE_DIRS="/usr/**lib/python3.2" >> > > Again a mix and match and again the same compilation error meaning that >> 2.7.3 and 3.2 are still mixed up. >> >> Is this a hugin bug or a cmake (FIND_PACKAGE(PythonLibs REQUIRED)) bug? >> Or even worse: What am I doing wrong? >> > > Have you tried deleting your CMakeCache.txt file and/or starting a fresh > build from clean sources? > Hi, I always remove my CMakeCache.txt and in this case I completely emptied my build directory upon every new build (even though that takes more time). But what do you mean with clean sources: A new download of the hg repository from sourceforge? Like: hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin hugin.hg Would that help? I thought that that's the reason you use a build directory with cmake so that your source is never "touched"? If it was as simple as removing either 2.7.3 or 3.2 I would already have done that, but as Ubuntu is migrating to 3.2 as it's new standard but is not fully there Ubuntu needs them both (and so do I by the way for a lot of programs). Last night I built it without python (-DHSI=OFF) and that works fine of course, but that's not what I want. Harry -- 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
