Re: [hugin-ptx] 2nd Panini Video demo
Tom Sharpless twisted the bytes to say: Tom> http://www.youtube.com/watch?v=Oj69gzOF8JA . Did you see this video: Panini Unwrapped :):) http://www.youtube.com/watch?v=pc2PuL--jf0&NR=1 Tom> 720 x 480 DV from a Sony Handicam with an Opteka 0.41x semi-fisheye Tom> adapter, Tom> hfov 125 degrees. It is a poor lens and my correction of it is not Tom> great; but Tom> the Panini perspective looks pretty good. Tom> I hope soon to post some decent looking clips from EOS 7D with Tokina Tom> 10-17mm zoom fisheye, using lens calibrations made with PTGui. Tom> -- Tom Tom> -- Tom> You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. Tom> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ Tom> To post to this group, send email to hugin-ptx@googlegroups.com Tom> To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com Tom> For more options, visit this group at http://groups.google.com/group/hugin-ptx -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] Panini-Video
I did something similar with the Wii, to record that data and send it to the computer as I was taking the photos. The problem is, the wii is an accelerometer and it works when the camera is stationary, but would not work for a moving camera. It would be interesting to rig something using an arduino and a digital inclinometer, using a wireless medium to send the data to a computer. Thomas> Yes, it would. The Panini projection needs to be aligned to the world Thomas> vertical. The best way to do that would be to have the camera report its tilt Thomas> and roll sensor readings frame-by-frame. The EOS 7D has such sensors but does Thomas> not report them -- I've written Canon to request a firmware fix, but am not Thomas> holding my breath. I suppose some pro video cameras may have such an output Thomas> already. It would also be good if the camera reported lens zoom, since the Thomas> projection is sensitive to fov. Thomas> Pending the correct solution, I have given Panini-Video a mouse-controlled roll Thomas> /pitch/zoom tracking tool that shows a kind of 'artificial horizon', with a Thomas> dilating box to track zoom, overlayed on the image. When I made this clip it Thomas> was not working yet. Thomas> Cheers, Tom -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: Fwd: Google Summer of Code 2011 Announced
>> Whether by reverse engineering (is that what you mean with cleanroom?) or >> by >> following the specs to the letter, one important ingredient is lacking: >> motivation. Roger> I'm not even sure it would require reverse engineering, as that work has already been done in ImageMagick, for instance. Are all of you aware of PTtiff2psd? It is not perfect, but does the job for 8-bit images. It is in desperate need of a facelift. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: parser for hugin PTO format
kfj> That's how I did it. In a beginning-of-line context accept all kfj> conventional line-headers plus the 'meaningful comment' type as legal kfj> line-type tokens. This seems to be the least painful route. Luckily kfj> line beginnings like '# hugin' don't seem to contain meaning but only kfj> serve as comments. The only slightly annoying part is that these kfj> additional line types have a slightly different syntax, insofar as kfj> some use = syntax, like kfj> #-hugin cropFactor=1 kfj> and others merely give a field value without a field header like kfj> #hugin_optimizeReferenceImage 0 in PToptimizer the rules can be: var or var= Each has a different meaning (first is assignment, the second is a reference to another image). --dmg kfj> so there are different parsing rules needed for the additional types. -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: parser for hugin PTO format
>> >> No. :) we need to document them. At this point my goal has been to >> create a mapping from PTO to txt formats (txt is the libpano format). kfj> It's been pointed out that those 'cousins' of hugin which also use pto kfj> dialects seem to give a damn about compatibility (I think some are kfj> commercial and may become incompatible deliberately) - and the best kfj> idea everyone had was putting their data into what is, by orthodox kfj> standards, a comment. I would advocate putting an end to this mess and kfj> starting with a new format. Something clean and well-thought out kfj> rather than an ugly old-timer with patches and quirks. I like the simple text file format that libpano started with (with some minor problems, such as dependence between lines, making it impossible to cut-and-paste lines). I think the real problem is lack of central parser development, lack of code that people can reuse to do the parsing. Everybody has to create their own, and everybody is afraid of breaking the parser of the others. So here is my pledge: to deliver a parser that can be used with any product that parsers the PTO format (and its variants) and can be embedded under any license (commercial and proprietary). The current code is a big step in this direction, but its license will have to change for this to happen (I am ok with that). This library could be useful for the current state, or the future (if a new format and parser is developed). New variables can be added to it (or if somebody can just maintain a light-fork from it if they don't want to send the new spec to us. -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] mask lines in PTO files
I am curious, are the mask lines (k-lines) in PTO files order dependent? I am wondering if they should be assigned to data structures of the image, or they should be a separate data structure. In other words, if the order of the lines changes in the file (the k-lines), will their meaning change? --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] PTO parser
Ok, thanks to Yuv for pointing me to the libpanorama repo. I have moved my code there, where I'll maintain it: http://hugin.hg.sourceforge.net/hgroot/hugin/libpanorama/ it is located in the PTOparser directory. I have updated the CMakeList files so it should be compilable by anybody (it is not "windows" portable yet, waiting for some patches in that direction). I have also renamed the program testparser to pto2txt --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: parser for hugin PTO format
>> THe idea of this parser is old: if we have a single parser (as a >> library) we can then have multiple tools reading (and perhaps >> generating) these files. kfj> Precisely. I wish I'd known of your work when I wrote my Python parser kfj> for pto files some months ago. I might even have made a Python module kfj> from it rather than writing it from scratch... ;) maybe we can use each others as cleanroom for quality testing. >> One of the goals is to replace (or at least create an alternative >> execution path) the parser in libpano, so we can more easily upgrade it >> when we need new options/variables. This will probably help in the >> creation of more portable lens parameters. kfj> This is very laudable. All the time I was messing with the pto format, kfj> I thought to maybe eventually write a proper grammar for it myself. kfj> I'm glad, though, I don't have to do it because the format is so kfj> 'ugly' (forgive me) - and I was hoping to maybe find support for kfj> creating a new format altogether - but I achnowledge it would be kfj> painful to make the move... I know it is ugly. That is why I needed to write a parser that was independent from the libpano code. kfj> I had a brief look at the code and the data structures it generates. I kfj> have some comments: kfj> - I could not find code handling masks. These are in lines like kfj> # masks kfj> k i0 t1 p"74 4350 2619 4365 2611 232 82 240" these are "new". I'll implement them. Ugly, it means that the p parameter has to be parsed once more... kfj> So the line type is 'k', i0 means image 0, the t-field is, I think, kfj> the type of mask (include/exclude) and the string after the p contains kfj> x/y coordinates of the points making up the mask polygon. If I've kfj> overlooked mask handling in your code, please disregard my comment kfj> - it seems to me as if you were reading the data into data types kfj> specified in the header file. This would imply that a next step would kfj> be needed to move all the values from the parse tree into hugin's data kfj> structures. Is this deliberate, to make the parser independent of kfj> hugins data structures? Or do the hugin data structures inherit from kfj> the parse structures? yes. I didn't want to mess with hugin. Hugin is already too big, and it depends on C++, while libpano is plain C. So I decided to take a simple approach and create new data structures that facilitate parsing. Then one can write a simple function that maps one to the other (and can be done by the people who know the hugin data structures). kfj> - I didn't see a reflection of the bottom end of hugin scripts with kfj> the hugin options, like kfj> #hugin_optimizeReferenceImage 0 kfj> #hugin_blender enblend kfj> #hugin_remapper nona kfj> #hugin_enblendOptions kfj> #hugin_enfuseOptions kfj> #hugin_hdrmergeOptions -m avg -c No. These ones surprised me. There are already 3 types of "hugin" variables. if libpano was a mess, hugin is helping: #-hugin #hugin and # hugin Can anybody shed some light on why 3 variants, and what does each mean? kfj> which would fit nicely into the pt_script_pano structure - unless, kfj> since they are 'technically' comments, you treat them as such, and kfj> hugin gets hold of them in some other way. doable. I just need a spec with their meaning. kfj> - Do you also parse what I've termed the 'ugly ducklings' - deviations kfj> from 'orthodox' pto which some of hugin's relatives use and which also kfj> come in the guise of comments? Like, there is a dialect which (I quote kfj> myself:) No. :) we need to document them. At this point my goal has been to create a mapping from PTO to txt formats (txt is the libpano format). kfj> "# now some CPGs produce files with yet another complication. kfj> # They put image data in o-lines and precede these o-lines with kfj> # more data in a line starting with '#-imgfile'. this line contains, kfj> as far as kfj> # I can tell, the image's width, height, and name, untagged. Having kfj> thusly output kfj> # these data, they are promptly omitted from the o-line. kfj> # I found Panomatic and A. Jenny's autopano to do this." kfj> If you're interested in my work, have a look at my pto parser at kfj> http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/parse_pto.py I am not a python programmer :) but I see what you mean by syntactic parser. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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.googl
[hugin-ptx] parser for hugin PTO format
Hi everybody, I undusted the code I started few years ago and finally completed a working prototype: https://bitbucket.org/dmgerman/panoparser (it is here temporarily until sourceforge gives us shell access again). If you download it and compile it, you will find that it creates a program called "testparser". It uses one command line option, the name of a PTO file. It will convert this PTO file to an equivalent .TXT panotools script. THe idea of this parser is old: if we have a single parser (as a library) we can then have multiple tools reading (and perhaps generating) these files. One of the goals is to replace (or at least create an alternative execution path) the parser in libpano, so we can more easily upgrade it when we need new options/variables. This will probably help in the creation of more portable lens parameters. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] documentation for PTO file?
Hi Everybody, I am trying to revamp the parser of libpano to make it compatible with PTO files. Is there a document that describes it? For example, what is the meaning of the variable 'j' in the image lines? -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] libpanorama
in the move from SVN to Mercurial, what happened with libpanorama? I have finally completed the bison parser for PTO files (I think) and I was trying to commit to subversion, and the module is no longer for write access. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] how does Hugin do CP optimization?
Hi everybody, how does Hugin do CP optimization? My understanding is that it uses libpano, but does it execute it as a command line program, or does it call it via a function? --dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] how good is the thoby for the Nikkor 10.5?
hi everybody, Now that the thoby Projection is available in Hugin/panotools I was able to run some tests using my 10.5 on a Full frame camera (5dII) I can say that the thoby is a better match than what we call "circular fisheye". How much better? It is hard to tell, as we don't have a good that measures the goodness of registration between 2 photos (I guess we could use Imagemagick's 'compare', but we need to indicate it to use only the intersection of the mask between the two images). In reality, when one uses a "b" parameter, the differences are small. One thing I am surprised is that I am getting an effective field of view of 141.8 degrees, which translates to a lens of 9.69 focal length, which sounds wider than it should be. But it is consistent with Pierre Toscani's findings (In his excellent document describing the 10.5 at http://www.pierretoscani.com/echo_fisheyes_english.html#fisheye2) who gives it a horizontal field of view of 142 degrees (in vertical mode). But I still need a b correction parameter of 0.04411 (which is not too bad). I would say that proper rotation around the nodal point is far more important than using one projection over the other. The thoby improves slightly the match of photos towards the periphery of the lens, which means more of the original photo can be used. I suspect that most users will not see a major improvement of one over the other. Pierre Toscani mentions that this lens has a slight curve beyond 180 degrees, and I can observe that in my tests. So I recommend to crop the far outside of the image. It might be possible to create a 360x140 pano with 2 photos, thought, but there might be deformations in the area where they meet. Speaking of cropping. Hugin should be programmed to crop images for Thobys in the same way it does it for Circular Fisheye. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] unable to find boost
This morning I was able to build hugin, then I pull the change by T. Modes and cmake complaints that it can't find boost: I have checked my installed libraries, and boost is there (as I said, it was there this morning before I pull this change). Unfortunately I am clueless on how to see what the diff is before and after this change in subversion to see if there was any other change to the CMakeFile. Any idea if this is a bug in the CMakeList.txt, or is it my installation? d...@iodine:/tmp/hugin$ cmake CMakeLists.txt -- Current HG revision is 8b3ff381a026 -- Found wxWidgets: TRUE -- Found TIFF: /usr/include -- Found JPEG: /usr/include -- Found PNG: /usr/include -- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig -- Found OPENEXR: /usr/lib/libImath.so;/usr/lib/libIlmImf.so;/usr/lib/libIex.so;/usr/lib/libHalf.so;/usr/lib/libIlmThread.so -- GLUT Found -- Found Glew: -- libpano13 version: 2.9.18 major 2 minor 9 patch 18 -- Could NOT find Boost CMake Error at CMakeLists.txt:253 (MESSAGE): Boost not found. Maybe wrong version. Hugin requires at least version 1.34 -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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 version of libpano
I have just bumped the version of libpano to 2.9.18. This should avoid any problems with people who try to use the new projections without the proper library. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] So, how good is the Thoby projection in a APS-C?
Hi everybody, I just committed a change that will enable PToptimizer to handle the Thoby projection. I undusted a spherical 360/180 project I had lying around. Unfortunately it was shot with a 20d, but i took good care of setting control points. This was my "calibration" shot for the Nikkor on my 20d. The Thoby is not perfect, but it very close. I needed to compute the b parameter to get almost perfect alignment (b0.020879). The first is the result of running PTroller on the remapped images. As you can see, the seams are visible (8 horizontal photos, + 1 nadir and 1 zenith). http://turingmachine.org/~dmg/temp/thoby-APSC-noMask.jpg To highlight the seams, I only show half of the images here: http://turingmachine.org/~dmg/temp/thoby-APSC-partial.jpg The vignetting of the lens gives the seams away. Be careful not to confuse a shadow with a lack of alignment. As you can see, the results are spectacular. Now I need to test it with a fullframe photo. Any of you who want to try it, install the library, and edit the optimization script. Any chance hugin could implement a filter to pass the script through rather than having to do manual edits? Script follows; --dmg # PTOptimizer script, written by hugin p f2 w4000 h2000 v360 n"TIFF_m c:NONE" m g1 i0 f0 m2 p0.00784314 # image lines #-hugin cropFactor=1.6 i w2336 h3504 f20 v50 r1.23268 p-0.739786 y0 TrX0 TrY0 TrZ0 a0 b0.001 c0 d-32.4022 e0.379041 g0 t0 u10 n"/tmp/070322.NikonCalib/070322_6440.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r0.0634678 p-0.772426 y48.6043 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6443.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r-0.652717 p-0.067337 y88.5627 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6446.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r-0.632612 p1.15348 y138.084 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6449.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r0.0903612 p1.73747 y179.141 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6452.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r1.24336 p1.76502 y-130.051 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6455.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r1.91459 p1.10837 y-89.3071 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6458.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r1.88377 p-0.0144794 y-42.525 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6461.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r59.0587 p88.4977 y16.4769 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6464.JPG" #-hugin cropFactor=1.6 i w2336 h3504 f20 v=0 r90.5344 p-87.1614 y-132.448 TrX0 TrY0 TrZ0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 u10 n"/tmp/070322.NikonCalib/070322_6467.JPG" # specify variables that should be optimized v d0 v e0 v r8 v p8 v y8 v v0 v b0 v # control points c n0 N1 x2204 y3253 X1297.01 Y3148.65 t0 c n0 N1 x1989 y413 X967.357 Y490.873 t0 c n0 N2 x1989.21 y411.99 X155 Y415 t0 c n0 N2 x2203 y3252 X498.179 Y3194.61 t0 c n1 N2 x1295 y3146 X497.052 Y3192.78 t0 c n1 N2 x974 y490 X155.096 Y418.234 t0 c n2 N3 x1210 y3238 X313.701 Y3328.4 t0 c n1 N3 x2132 y697 X12 Y712 t0 c n1 N3 x1938 y3299 X314 Y3327 t0 c n2 N3 x1184 y771 X12 Y710 t0 c n3 N2 x960 y3351 X1796.66 Y3390.12 t0 c n1 N2 x2131.5 y696.5 X1185 Y772 t0 c n1 N2 x1936.5 y3297.5 X1208.5 Y3237.5 t0 c n2 N4 x1915 y384 X84 Y358 t0 c n2 N4 x1797 y3392 X316 Y3452.5 t0 c n3 N4 x961 y3353 X316.298 Y3453.41 t0 c n3 N4 x896.5 y377.5 X131 Y283 t0 c n3 N2 x895.183 y377.332 X1873 Y313 t0 c n3 N4 x2247.5 y197.5 X1544 Y338.5 t0 c n3 N4 x2176.5 y3188 X1379.84 Y3100.81 t0 c n4 N5 x1378 y3099 X340.008 Y3164.55 t0 c n4 N5 x1542.5 y339 X541.5 Y335 t0 c n4 N5 x2187 y3265 X1242.66 Y3161.58 t0 c n4 N5 x2186.5 y791 X934.5 Y862 t0 c n5 N6 x1246 y3163 X447.037 Y3219.33 t0 c n5 N6 x1291.5 y904 X261.5 Y882.5 t0 c n5 N6 x2157.5 y3097.5 X1311 Y3023 t0 c n5 N6 x2140 y596 X1216.37 Y678.542 t0 c n6 N7 x1310.5 y3023.5 X307.5 Y3086.5 t0 c n6 N7 x1213.5 y679.5 X141 Y625.5 t0 c n6 N7 x1856.5 y199 X1012.5 Y275 t0 c n6 N7 x1933 y3143.5 X972 Y3099 t0 c n7 N0 x1012 y275 X265.5 Y196.5 t0 c n7 N0 x972 y3099 X137.5 Y3200 t0 c n7 N0 x2176.5 y928.5 X1089 Y988 t0 c n7 N0 x2013 y3163.5 X1159.5 Y3106 t0 c n0 N1 x1160.5 y3105.5 X195.5 Y3202 t0 c n0 N1 x1390 y1246.5 X68.5 Y1232 t0 c n0 N1 x1581.84 y2015.84 X208 Y2037 t0 c n0 N1 x2316 y1959 X953 Y1964 t0 c n1 N2 x1297 y1923 X165.872 Y1941.61 t0 c n1 N2 x2242 y2044.5 X1129 Y2041.5 t0 c n2 N3 x1608.51 y1852.44 X199 Y1870.5 t0 c n2 N3 x2218 y1788.5 X815 Y1804 t0 c n3 N4 x1224 y1870.5 X64.0575 Y1886.77 t0 c n3 N4 x2287.05 y1814.06 X1130.5 Y1824.5 t0 c n4 N5 x1572 y1810.5 X127.608 Y1827.31 t0 c n4 N5 x2294.72 y1865.69 X861 Y1877 t0 c n5 N6 x1302.5 y1674 X148.959 Y1681.98 t0 c n5 N6 x2181.78 y1
[hugin-ptx] libpano updated
I have added the Thoby projection for the Nikkor 10.5. It is now in subversion. I have called it after Michel Thoby who was able to empirically find it. If this projection helps with other lenses, I'll add parameters to it. The input projection number is 20. Would the hugin developers add it to it? the libpano optimizer should be capable of dealing with this new projection. My very preliminary tests seem to imply it is working as expected. Once it is available in hugin I'll be able to do more testing. -dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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 coordinate system
Hi Joshua,
Sorry I haven't replied to you earlier. Once my email piles up, it takes
some time for me to go over it.
We basically have two translations. The one implemented by Pablo, and
used by Hugin, and the one implemented by Dev and I, which is not
directly available from Hugin.
I don't think we have this well documented, but let me try to explain
you how it works.
Any photo is mapped to the sphere, from the sphere, it is then remapped
to the corresponding output projection. This imposes a big limitation in
linear panoramas: they are not really linear, they are slices of the
sphere.
In a previous message I listed the order in which the remapping
happens. Remember, it is done backwards (any point of the output
projection is mapped back to each point in the source images.
In the panotools model (also used by Nona and Hugin), the center of a
photo is the center of the world, with X and Y in the usual
direction, and normalized according to their field of view and input
projection with respect to the area it would cover in the sphere.
I really don't know the way the Tr[XYZ] parameters work, but the code is
easy to read, and Pablo can probably answer any questions you have:
plane_transfer_from_camera is the inverse, if I remember correctly.
Some notes:
* mp->distance is a used to normalize the distances in the image (to a
unit sphere).
* the pointer variables are the outputs, and the non-pointers, the
inputs.
/** transfer a point from the master camera through a plane into camera
* at TrX, TrY, TrZ using the plane located at Te0 (yaw), Te1 (pitch)
*/
int plane_transfer_to_camera( double x_dest, double y_dest, double * x_src,
double * y_src, void * params)
{
// params: distance, x1,y1,z1
double plane_coeff[4];
double p1[3];
double p2[3];
double intersection[3];
// compute ray of sight for the current pixel in
// the master panorama camera.
// camera point
p1[0] = p1[1] = p1[2] = 0;
// point on sphere.
cart_erect(x_dest, y_dest, &p2[0], mp->distance);
// compute plane description
cart_erect(DEG_TO_RAD(mp->test[0]), -DEG_TO_RAD(mp->test[1]),
&plane_coeff[0], 1.0);
// plane_coeff[0..2] is both the normal and a point
// on the plane.
plane_coeff[3] = - plane_coeff[0]*plane_coeff[0]
- plane_coeff[1]*plane_coeff[1]
- plane_coeff[2]*plane_coeff[2];
/*
printf("Plane: y:%f p:%f coefficients: %f %f %f %f, ray direction: %f
%f %f\n",
mp->test[0], mp->test[1], plane_coeff[0], plane_coeff[1],
plane_coeff[2], plane_coeff[3],
p2[0],p2[1],p2[2]);
*/
// perform intersection.
if (!line_plane_intersection(plane_coeff, p1, p2, &intersection[0])) {
// printf("No intersection found, %f %f %f\n", p2[0], p2[1],
p2[2]);
return 0;
}
// compute ray leading to the camera.
intersection[0] -= mp->trans[0];
intersection[1] -= mp->trans[1];
intersection[2] -= mp->trans[2];
// transform into erect
erect_cart(&intersection[0], x_src, y_src, mp->distance);
/*
printf("pano->plane->cam(%.1f, %.1f, %.1f, y:%1f,p:%1f): %8.5f %8.5f ->
%8.5f %8.5f %8.5f -> %8.5f %8.5f\n",
mp->trans[0], mp->trans[1], mp->trans[2], mp->test[0],
mp->test[1],
x_dest, y_dest,
intersection[0], intersection[1], intersection[2],
*x_src, *y_src);
*/
return 1;
}
/** transfer a point from a camera centered at x1,y1,z1 into the camera at
x2,y2,z2 */
int plane_transfer_from_camera( double x_dest, double y_dest, double * x_src,
double * y_src, void * params)
{
double phi, theta;
double plane_coeff[4];
double p1[3];
double p2[3];
double intersection[3];
// params: MakeParams
// compute ray of sight for the current pixel in
// the master panorama camera.
// camera point
p1[0] = mp->trans[0];
p1[1] = mp->trans[1];
p1[2] = mp->trans[2];
// point on sphere (direction vector in camera coordinates)
cart_erect(x_dest, y_dest, &p2[0], mp->distance);
// add camera position to get point on ray
p2[0] += p1[0];
p2[1] += p1[1];
p2[2] += p1[2];
// compute plane description
cart_erect(DEG_TO_RAD(mp->test[0]), -DEG_TO_RAD(mp->test[1]),
&plane_coeff[0], 1.0);
// plane_coeff[0..2] is both the normal and a point
// on the plane.
plane_coeff[3] = - plane_coeff[0]*plane_coeff[0]
- plane_coeff[1]*plane_coeff[1]
- plane_coeff[2]*plane_coeff[2];
/*
printf("Plane: y:%f p:%f coefficients: %f %f %f %f,
[hugin-ptx] Michel Thoby projection for the Nikkor 10.5
I have been intrigued by Michel Thoby estimation of the curve that describes the Nikkor 10.5. I finally got the time and implemented it. This is an example of a photo projected using it: The first is a photo with the Canon TS-E 17mm (which has very little distortion, and it is basically for the sake of reference). The second was taken with the Nikkor 10.5 with its hood shaved. Both were taken on a Canon 1dsIII (Novoflex adapter). http://turingmachine.org/~dmg/temp/110103_3136.jpg http://turingmachine.org/~dmg/temp/110103_3137.jpg This is the remapped photo, using Michel projection data: http://turingmachine.org/~dmg/temp/thobyExample.jpg This is the PTmender script that I used for the conversion: Impressive, isn't it? Notice that there is no "b" parameter used (only pitch, roll and yaw). --- # PTStitcher script, written by hugin p f0 w2000 h2011 v150 n"TIFF_m c:NONE r:CROP" m g1 i0 f0 m2 p0.00784314 # output image lines o w3744 h5616 f0 TrX0 TrY0 TrZ0 a0 b0 c0 d33.6929 e-20.9346 g0 p2.59683955841122 r-89.8237202828159 t0 v68.7933 y-3.18239065182056e-16 u10 m0 n"110103_3136.jpg" o w3744 h5616 f8 TrX0 TrY0 TrZ0 a0 b0 c0 d0 e0 g0 p0.641272943899231 r-89.8468395110442 t0 v138.7 y0.0390779239535064 u10 m0 n"110103_3137.jpg" --- -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: Panini patents?
Tom> That was my conclusion also. Next time I revise the Panini-general Tom> code in libpano13 I shall put it under GPLv3. Tom> For version 1 of my Panini viewer/perspective tool I am using the Tom> Apache license, which is GPLv3 compatible but also allows a bit more Tom> restrictive licensing for proprietary uses, and GPLv3 for the parts Tom> that don't implement anything I want to patent. Hi Tom, I _think_ it will work. Hugin is GPLv2+, which means that it can link to GPLv3+, because it will effectively become GPLv3+ in binary form. Complicated ;) --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] Panini patents?
Thomas> I'm sure the trick is doable, but it clearly needs both good Thomas> legal preparation and good management of the patent rights. Thomas> Which in turn need to be sustained by some revenue. So it Thomas> won't happen unless I can actually find some customers who want Thomas> to build and sell Panini-based products. If I were 20 years Thomas> younger I'd probably try to start a company to make TV and Thomas> movie rendering software (and probably lose my shirt) but as it Thomas> is, someone else is going to have to do that. If any of you Thomas> wants to volunteer, or knows how to sell new technology to TV Thomas> or movie producers (or JVC Corporation, for that matter) I Thomas> would be happy to hear about it. I had informal (ie. non legal) conversation with E. Moglen and Bradley M. Kuhn (Technology Director of Software Freedom Law Center) with regard to this issue. The FSF would helps us with any questions regarding this issue. I described to them the main issue and it seems that the simplest solution for everybody (the patent holders and libpano/hugin) is that you, Tom, re-license the code from its current license (BSD-3 clauses) to a GPLv3+. Our code is GPLv2+ hence, it can link with GPLv3+ as in practice it will become GPLv3 at build time. Now, from a more pragmatic issue, the uncertainty of if a patent is going to exist or not is an important issue. Tom, your intention is to patent, and therefore we must take the necessary steps to address this potential problem. Tom, do you make a claim on the Equirectangular Pannini? --dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] 2010 Summer of Code projects announced
This is great news! -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: GSoC - Regression tests for pano13
>> With respect to your proposal, I'd prefer that the project is divided >> into two parts. In the first is the creation of basic test cases for the >> tools: mapping of images into different input and output projections with >> different basic parameters. Tests for the optimizer too. Basically, a >> simple set of tests that we can easily run to test regression. >> >> Then you can work on an automatic framework/method to do this >> >> The second part is to do testing a the function level. >> >> I think there are various advantages to this approach. The first is that >> you will get experience on the tools and how the scripts work (and the >> tool parameters). The second is that this test cases are valuable as >> soon as they are created (compared to a framework that needs to be >> finished to be useful). Tomasz> Yes, I think it is better approach than mine. In my opinion my Tomasz> proposal is already divided into two (or even 3) parts. Maybe those Tomasz> parts aren't visible enough. New timeline might look like this: hi Tom, The very first part should be test cases. I want tangible tests cases written in the first month, rather than design documents. revised schedule: Week 1. preparations. (2 weeks for just getting ready is too wayy much, in fact, this should take 2-3 days at most). Week 2-3. Creation of tests cases that stress the most important parts of the system (selection of images, creation of scripts, creation of reference output images, etc, this might involve some scripting, but we don't know what we need to create until we know what we have to create). Given that some of these tools can work in pipeline mode some tests could involve running many of the tools on a set of images, and looking at the results. Also, creating test cases gives you the ability to learn the tools, so you don't have to spend 1 week just learning what these tools do. PToptimizer, PTmender, PTroller, PTmasker, PTtiff2psd, PTcrop, PTuncrop, PTBatcher. Week 4-6. Create the framework for the automatic testing based on the tests created and that simplifies the creation of new tests. I think the framework design can be interleaved with the creation of tests. For instance, to understand what is needed in terms of testing PTmender you first need to create test-cases for PTmender. Perhaps interleaving them is a good approach. This is at the tools level. This should be broken down further into weekly deliverables. When is the first evaluation? This part should be mostly completed for the first evaluation. Tomasz> Part 0 - preparations Tomasz> May 1st – May 15th - preparations, discussions on mailing list, Tomasz> research, making developer blog (I am willing to write every two days Tomasz> reports) Tomasz> May 16th – May 24th - architecture of the system Tomasz> Part 1 - tests and framework for the tools Tomasz> May 25th – June 18th - create full set of tests (including the Tomasz> PToptimizer) Tomasz> June 19th – July 4th - creation testing framework for the command line Tomasz> applications in libpano and integrate existing tests with framework, Tomasz> add new tests if necessary Tomasz> July 5th – July 7th - write documentation to the framework Tomasz> Part 2 - function level testing Tomasz> July 8th – July 13th - add a special functionality to the libpano, for Tomasz> checking popularity of used functions – a path for the people who want Tomasz> to help in development We don't need a popularity counter. We know which functions are used by hugin by just looking at its source code. Scrap this part. Instead, use 1 week to determine what functionality (what functions) need to be tested in this framework. I will be helping you with this. Tomasz> July 14th – August 2nd - make framework for testing the main Tomasz> functionality of libpano as used by hugin (function level) and add Tomasz> tests for the framework (based on popularity checking path) Tomasz> August 3rd – August 9th - improving of the code, adding documentation, Tomasz> integrating two frameworks into one, ensuring that frameworks and Tomasz> tests will work on different platforms, testing Tomasz> August 10th – August 16th - as above + backup time This should be for each part (pre-post evaluation, not just wait to the end). In my opinion, we have two sub-projects. I also want you to indicate in your plan the number of hours you will be working on the project each week, and weekly tangible, deliverables that I can check. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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, s
Re: [hugin-ptx] Re: GSoC - Regression tests for pano13
Tomasz> Hi Tomasz> I created new testing tool written in python. It is available on: Tomasz> http://hugin-ptx.googlegroups.com/web/tests2.tar.gz?gda=yI6jqj8_m-Bmjzq5Pt_LOx1JMF0oI0W3JwwUvub6K5WnpSjMggDPXttxP6-sUHRZBFW1F7iccyFKn-rNKC-d1pM_IdV0&gsc=PVzG9gs75cSDwTgOMIvO-SxrrAdu Tomasz> with about 23 tests and additional bash scripts for using testing Tomasz> tool. It isn't completed but I think that it is a good way to extend Tomasz> existing testing framework. Hi Tomasz, I tried running the scripts, but I got this error (after setting the PATH to the current directory). How do I make it work? d...@phosphorus:/tmp/rip4$ sh makeReference.sh makeReference.sh: 16: [[: not found makeReference.sh: 16: [[: not found makeReference.sh: 16: [[: not found makeReference.sh: 16: [[: not found ... With respect to your proposal, I'd prefer that the project is divided into two parts. In the first is the creation of basic test cases for the tools: mapping of images into different input and output projections with different basic parameters. Tests for the optimizer too. Basically, a simple set of tests that we can easily run to test regression. Then you can work on an automatic framework/method to do this The second part is to do testing a the function level. I think there are various advantages to this approach. The first is that you will get experience on the tools and how the scripts work (and the tool parameters). The second is that this test cases are valuable as soon as they are created (compared to a framework that needs to be finished to be useful). What do others think? -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: Equisolid and Stereographic working
>> When a,b,c,d,e are different from zero, I get the same results (a >> perfect 360/180 panorama) with either projection (PTmender -> emblend) >> (input is 8 photos, with a 40D). >> >> I haven't tested it fullframe. It might be a different story. Robert> You can model equisolid with equidistant mapping plus PTLens Robert> correction quite well. Near-perfectly, in fact, so I am not that Robert> surprised. For 0 resulting in the polynomial correction to work _very_ well. Robert> The two 'problematic' mappings are orthographic and stereographic, Robert> from a mathematical point of view. Due to larger differences, the Robert> PTLens polynomial is neither able to yield a really good fit down to Robert> sub-pixel level nor does it stay entirely 'well-behaved'. However, Robert> orthographic was exactly implemented only once about thirty years ago Robert> (Nikkor 10mm OP fisheye), and just a few hundred of that lens were Robert> ever produced as far as I know. Robert> Stereographic is thus IMHO more important, since the Samyang 8mm full- Robert> frame fish has become quite popular and it implements a mapping quite Robert> close to stereographic. Modelling that geometry using a equidistant The code is there now, but I can't test it. If anybody provides me with perfectly aligned photos (a spherical panorama, taken with that lens on a tripod head, with good areas control points) then I'll test it. Otherwise the code is "as is". ---dmg Robert> fisheye mapping plus PTLens correction can produce differences of Robert> several pixels, at least in my experience. Since I read somewhere that Robert> support for different fish geometries in libpano was already working, Robert> I have only had a look into the Hugin sources, but I admit that I am Robert> still a bit confused right now, since the codebase is quite large (and Robert> entirely new to me). Anybody who wants to try it, just save the PToptimizer script. Change the type of lens from f3 (full frame equidistant) to f10 (stereographic) in all input images. Optimize with PToptimizer. You might need to 'seed' some values'. Then use PTmender to remap the photos. It 'should' work. --dmg Robert> Regards, Robert> Robert Robert> -- Robert> You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. Robert> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ Robert> To post to this group, send email to hugin-ptx@googlegroups.com Robert> To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com Robert> For more options, visit this group at http://groups.google.com/group/hugin-ptx Robert> To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
[hugin-ptx] Equisolid and Stereographic working
Hi everybody, I just committed code that allows the remapping of stereographic and equisolid input lenses. I tested the equisolid (which is the same as the Lambert Azimuthal Equal Area, I discovered) with the Nikkor 10.5. With a=b=c=d=e=0 parameters, the equisolid is clearly superior. But when b<>0 is used, the fisheye becomes as good as the equisolid. When a,b,c,d,e are different from zero, I get the same results (a perfect 360/180 panorama) with either projection (PTmender -> emblend) (input is 8 photos, with a 40D). I haven't tested it fullframe. It might be a different story. BTW, the input number for equisolid is 21 (19 is a bug), but it might change to the same as LambertEqual area (16) since they are the same projection. if anybody is interested, i'll post some photos. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
[hugin-ptx] implementing other fish eye input projections
Hi everybody, Some people have recently mentioned that it would be useful to implement new input projections in libpano/hugin to support a wider variety of fisheye lenses (i.e. samyang stereographic lenses, and potentially fine tune projections to fisheye lenses). I spent some time this weekend looking at the code in libpano trying to understand how this could be done. In a nutshell, this is the process used to map a photo (we do it backwards): // Building the conversion stack // // 1- Convert from panorama projection to equirectangular // 2- Rotate horizontally // 3- Convert to spherical from equirectangular // 4- Apply perspective correction (pitch and roll) in spherical coordinates // 5- Convert to image format (rectilinear, pano, equirectangular) // 6- Scale output image // 7- Do radial correction // 8- Do tilt // 9- Do vertical shift // 10- Do horizontal shift // 11- Do shear Spherical coordinates are equidistant ones (think equidistant fisheye). It is in spherical coordinates that the optimization step happens. To support a new input projection we need a function that maps from spherical coordinates to the output projection (and its inverse). The current candidates to be added as input projections are: equisolid, stereographic, mirror, and orthographic There was some work towards supporting them, but it was incomplete (it does not work in current version of panotools). I have gotten this far (work not committed yet): These two are implemented: * Orthographic: Not tested. seems to work. * Stereographic: Not tested, seems to work. This one is buggy: * equisolid NOT WORKING: equisolid_sphere_tp, and sphere_tp_equisolid are implemented but they don't work. The composition of the forward and the inverse is not returning the original points. * Mirror: NOT IMPLEMENTED. In theory, we could implement a projection that fits the lens (see http://michel.thoby.free.fr/Blur_Panorama/Nikkor10-5mm_or_Sigma8mm/Sigma_or_Nikkor/Comparison_Short_Version_Eng.html) Given that there are not that many fisheye lenses, we could have mappings that approximate the lens as close as possible. But I am stumped. My geometry sucks. My main problem is that I don't understand how the equirectangular coordinates are converted into equidistant ones, and vice-versa. Basically, I need to learn how the equidistant projection equations (see http://mathworld.wolfram.com/AzimuthalEquidistantProjection.html) are derived. If anybody can point me to a resource, or explain it here, I'll appreciate it. Other things that need to be done: In libpano: * Implement mirror transformation. There is already a mirror_erect. We need its inverse. * Determine what is wrong with equisolid. * Test orthographic and stereographic input projections. In Hugin: * Expose the projections in the user interface: IMAGE_FORMAT_EQUIRECTANGULAR = 4, IMAGE_FORMAT_MIRROR = 7, IMAGE_FORMAT_FISHEYE_ORTHOGRAPHIC = 8, IMAGE_FORMAT_FISHEYE_STEREOGRAPHIC = 10, IMAGE_FORMAT_FISHEYE_EQUISOLID = 21, I am sure that there will be some issues with respect to Full-frame vs circular fisheyes for these projections. But we can deal with them as the need arises. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: [hugin-ptx] GSOC 2010 – Accepted
Bruno Postle twisted the bytes to say: Bruno> On Thu 18-Mar-2010 at 21:00 +0100, Lukáš Jirkovský wrote: >> I've just got a great news – it seems that hugin was accepted[1] for >> the Google summer of code 2010! >> >> [1] http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2010 Bruno> We have two or three mentors volunteered so far, we need more at least Bruno> to do backup roles. Now is the time to volunteer for mentoring. We Bruno> also need a backup admin as I will have limited connectivity for some Bruno> of the SoC period. -- I can volunteer as a backup (given my success rate in the previos years). The project that I really want to see materialize is regression testing for panotools. If it was easier to test it might make life easier for those who want to hack it. Perhaps we can all pitch-in for a regression testing framework that can be configured for different tools. what do others think? --dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: [hugin-ptx] PTmender + Hugin = no love?
Hi Zoran, I can't see the images. But I'm interested on knowing that the issue is (and perhaps fix it) Location: http://hugin-ptx.googlegroups.com/web/nona-example.jpg Gmail Calendar Documents Reader Web more » Help | Sign in Google Groups Home Found Please click the following link to continue. /web/nona-example.jpg?gda= RQnSxUIAAABgE5HMzGwGqAOKWxgT_144cruHh-tp2W9yrfcaIv3ojkluqF0z3khbrGqcf62fklhV4u3aa4iAIyYQIqbG9naPgh6o8ccLBvP6Chud5KMzIQ -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] fixed autoconf for libpano
The HEAD of libpano should now be compilable using autoconf/automake. --dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: [PanoTools-devel] general panini and its parametrization
Thomas Sharpless twisted the bytes to say:
Thomas> Hi Daniel
Thomas> I put in 3 parameters and Hugin takes them OK. But it returns them
rounded to integer values.
this sounds like a restriction of hugin. The parameter sliders must be
programmed using integers, not floats.
A quick hack that will allow you to continue your work is to divide the
values in the sliders by 10 (specify 20 instead of 2) and then divide in
your code by the same factor.
yes, a hack, but at least you can keep working...
--dmg
Thomas> -- Tom
Thomas> On Thu, Dec 31, 2009 at 12:08 PM, D M German wrote:
Hi Tom,
Tom> Hi Daniel
Tom> I'm trying to set up to test my revised general pannini code in
libpano, and need some guidance about
how projection parameters get passed to/
Tom> from hugin.
Tom> First, I don't quite understand this code in queryfeatures.c
QueryFeatures was built as an interface to hugin. Hugin will use it to
know how many projections are supported, their field of view and any
parameters needed. Look at the albert conic projection for an example of
one with 2 parameters.
This way Hugin dynamically adjusts to the features of libpano without
having to be recompiled.
Tom> case PANO_FORMAT_PANINI_GENERAL:
Tom> features->maxVFOV = 179;
Tom> features->maxHFOV = 359;
Tom> features->numberOfParameters = 1;
Tom> features->parm[0].name = "d";
Tom> features->parm[1].name = "phi2";
Tom> for (i=0;i<2;i++) {
Tom> features->parm[i].minValue = +0.1;
Tom> features->parm[i].maxValue = 10e10;
Tom> }
Tom> break;
Tom> If there is just one parmeter, why do you intialize two of them?
What is phi2?
A "cloning" error. I just copied the code from the Albert. I should have
removed that line, and adjusted the for loop accordingly. I'll do that
right now.
As I mentioned before, queryfeatures is code that is not used inside
libpano (I think it should, for verification of parameters, but it is
not currently).
Tom> How is the size of parm[] set? What do I have to do to add two more
parameters?
#define PANO_PROJECTION_MAX_PARMS 3
I said yesterday it was equal to 2. I was wrong, it is currently equal
to 3. I am not sure how hugin sets it. So to add two parameters you
don' t need to do anything, just start using them in the projection. And
set them in the script, of course "P "
Tom> Second, are any source changes needed on the hugin side, or can I
Tom> just relink a several months old build of hugin against this
Tom> pano13.lib?
I'll check for the maximum number of parameters with the hugin
people. Maybe yes, maybe not (the only problem is how the maximum
number of parameters is set).
Tom> Happy New Year, Tom
Happy new year!
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
--
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: [PanoTools-devel] bug in libpano/PTmender
Hi Pablo, Pablo> D M German wrote: >> FYI, >> >> Adding Tr parameters to the script will restrict the output of the any >> remapped image be at most 180 degrees, even if it can spawn longer (such >> as most of the cylindrical panoramas). >> >> I am not sure why this happens yet. Pablo> Only images that have nonzero TrXYZ should be affected by this, as they Pablo> are fist projected onto a plane and thus cannot have more than 180 Pablo> degrees in the final panorama. Pablo> The behaviour of images with Tr(XYZ)0 should not change. I agree. The problem is the execution path of libpano. When a parameter is found, its corresponding function is executed as part of the stack, even if the parameters do not alter the image (such as Tr(XYZ)0). I suspect that the translation function becomes undefined (return nans) when the point if beyond 90 degrees on either of the four directions. The result of this is that the output image has the right size, but has no data outside the 90 degrees boundary. I suspect the best approach is to test for the values of the Tr* parameters in the parser, and if they are zero, do not set the im->cp.trans to TRUE. This can be done for several other parameters too, and will remove unnecessary processing. Pablo> ciao Pablo -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] bug in libpano/PTmender
FYI, Adding Tr parameters to the script will restrict the output of the any remapped image be at most 180 degrees, even if it can spawn longer (such as most of the cylindrical panoramas). I am not sure why this happens yet. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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] New tutorial, surveying buildings with Hugin
Hi Bruno, Very impressive! --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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: Canon 7D or SONY Alpha 850 - which one would you buy?
Yuval> I would assume such a group to have, on average, a biased opinion and I Yuval> am not looking for fan answers. Actually the best feedback I got so far Yuval> is from Nikon users :) Hi Yuv, Most of use are biased... because we don't use both cameras most of the time. I personally like Canon lenses. They are superb, and long term investments. My EF 85 1.8, my second Canon lens, still makes amazing photos 15 years later (I know, I know, some people use older lenses, but that is my point: lenses are long term investment). Of course, what lenses you get depends on your budget. Canon does not make many cheap great lenses (one the EF 50 1.8 mkII, which should be owned by anybody who does not have a more expensive 50mm). Look at the innovation in the new TS-E lenses, or the new 100 macro coming out soon. That does not mean I like Canon per-se. They hold technology to maximize their return. By the way, the 1ds3 is capable of doing 7 brackets at once, I think. I personally think the differences in sensors are there, but they are usually small compared to other "tangibles", such as lenses you have, your shooting style, and how comfortable you feel with each camera. After all, most of the photos we make could be equally be recorded with any of the sensors in the 1.6 or full frame SLR cameras in the market. What matters more often is you can control the camera to make the shot before it vanishes. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] it works!
The spherical model of libpano places some constraints on the Tr model, but with few adaptions it works. This is 11 photos taken along a narrow alley. the "stair" effect will show you where those photos are: http://turingmachine.org/~dmg/temp/wall.jpg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] I just committed the following:
In a nutshell, First warning. I had to reindent some functions. use svn diff -x -w to get diffs with whitespace ignored. * tilt parameters have been renamed to TiX, TiY, TiZ, and TiS. TiX, TiY, TiZ are now properly bound to -180,180 degrees. TiS can't be zero nor negative. * mosaic mode parameters are now TrX, TrY, and TrZ. * I have added a set of parameters for future testing: Te0, Te1, Te2, and Te3. These can be used for testing anything that requires optimization (i.e. a new lens model). SetMakeParams and SetInvMakeParams will need to include a new function to be used. Where in the stack is dependent of the purpose. Here is the same example I have been using. Layer 0 is the base photo, layer 1 is the tilted version, and layer 2 is the translated one. http://turingmachine.org/~dmg/temp/mergedFloorTiltTranslate.psd.bz2 Let me know what you think, and of course, if there are any bugs. --dmg -- 2009-09-25 * correct.c (SetCorrectDefaults): Initialized values of new parameters. * adjust.h (GetGlobalPtr): added parms to its prototype * PTcommon.c (panoPrintImage): Refactored this function from adjust.c * panorama.h (correct_Prefs): Added new parameters * adjust.c (SetAlignParams): Added new variables and renamed tilt ones. (panoAdjustPrintMakeParams): Renamed function to make it standard. Renamed variable g to optInfo (SetAlignParams): Make sure the tilt parameters never go outside incorrect values. * parser.c (panoParseVariable, ParseScript): Refactored some code. Sorry but I had to reindent the entire function. * parser.c (WriteResults): Added new parameters to the output. * parser.c (ParseScript): Renamed Tx, Ty, and Tz to TiX, TiY, and TiZ. Added translation variables TrX, TxY, and TrZ and test ones Te0, Te1, Te2, Te3. * filter.h: Added translation parameters, (trans[XYZ]), renamed optimization variables to a more meaningful name (suffix optVar), added a new set of variables for testing new functions in the stack. --- -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] cmake not working
I have a problem with the cmake configuration for libpano. -- d...@phosphorus:~/hacking/libpano$ cmake CMakeLists.txt CMake Error at CMakeLists.txt:38 (include): include could not find load file: HuginMacros CMake Error at /usr/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57 (MESSAGE): Could NOT find wxWidgets (missing: wxWidgets_FOUND) Call Stack (most recent call first): /usr/share/cmake-2.6/Modules/FindwxWidgets.cmake:765 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:54 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! d...@phosphorus:~/hacking/libpano$ -- Libpano is defined as dependent of hugin and wxWidgets. In my laptop I don't have neither one, so it fails. Libpano should not depend on hugin and wxwidgets. As far as I know, there is nothing on libpano that depends on hugin. Is this really necessary? libpano should depend only on zlib, java, libpng, libjpg, and libtiff. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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: Cleaning Up Libpano integration
Yuval Levy twisted the bytes to say: Yuval> dmg wrote: >> Would it be possible for someone to describe in the libpano mailing >> list what the problem is? Yuval> I tried. Seems that my message "awaits moderation". Hi Yuv, I don't know who is the moderator of the panotools-devel. Bruno, Jim, do you know who that person is? But at the very least, send me directly bug reports and I'll triage them. I am committed to fix them if they are accompanied with a good report. I'd really like to have any discussions on libpano on the panotools-devel mailing list. It helps with traceability and documentation. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] optimization of calculations in PTmender
Hi everybody, For those using (or wanting to use PTmender). for the sake of maintainability I have used only matrix multiplications right now. I am going to wait until we are sure about their correctness before I expand them. By the way, in the process of hacking the stack, I discovered that, if a parameter is present in the 'o' line, an operation in the stack is created, even if the parameter is zero, which is a penalty on speed. Hugin outputs many parameters, even if zero. Removing them will speed up operations a bit. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] libpano
I have committed the changes to support tilt of the camera in PToptimizer and PTmender. See the ChangeLog for details. the new parameters are: Tx, Ty, Tz, and Ts (for scale). --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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: Tilt transformation...
> > and this is a photo of the same place taken: > > http://turingmachine.org/~dmg/temp/floorInput.jpg sorry: http://turingmachine.org/~dmg/temp/floor.jpg And we should thank Dev and Google for this feature. I think it will go a long way into making the nadir photos easier. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] Tilt transformation...
(this code was brought to you by Google :) As you might know, Dev Gosh was one of Google Summer of Code students. Unfortunately he only completed part of his project. His idea was to allow for the rotation of the camera plane in two axis: around x, and around y. He did a good job with the math and, except for some very minor bugs, his code worked as expected. For example, for the tilt on X, imagine you take a photo, then you apply a "pitch" rotation (rotation around x), then a translation to recenter the image on (0,0). the same applies for rotation around Y. When I integrated his code I discovered that it would be good to add the ability to rotate around Z, and implemented it accordingly. Here is in example of the input: http://turingmachine.org/~dmg/temp/floorInput.jpg and the output: http://turingmachine.org/~dmg/temp/floorOutput.jpg and this is a photo of the same place taken: http://turingmachine.org/~dmg/temp/floorInput.jpg In this case, there is a tiltX of 32 degrees, and a tiltZ of -11 and a shear of -125 pixels. I have also added 3 parameters to the parser: Tx, Ty, and Tz, which are angles to rotate in degrees; and Ts, which is a scaling factor. I have the inverse transformations done. they are described here: http://turingmachine.org/~dmg/temp/tiltEq.pdf I am struggling with the inverse ones. If anybody wants to help, I'll be grateful. This is the only roadblock to have an alpha version of it. Now, the real question for hugin developers: can somebody create a branch of hugin that supports these new parameters during the optimization? shearX, shearY, tiltX, tiltY, tiltZ and tiltScale? I haven't committed my code but will do soon. in its current state the optimizer nor the cropping works (we need the forward transform for that). -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] how to add another parameter to the optimization?
hi Everybody, i am trying to finish and integrate the tilt function that Dev implemented during the summer. I have everything working except the optimization. I just can't understand the optimizer varies parameters, and how to instruct it to vary the values of the tilt. (yes, i have modified the parser, and Ptoptimizar correctly reports that the tilt variables are being optimized). Anybody has any clue? Thanks! -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] bug in shear parameter handling: READ IT if you use them!
Hi Everybody, There was a bug in panotools. It involves the parameters g and t (it has survived since their conception). In a nutshell, they have never worked properly. More specifically, its inverse was wrongly computed when both g and t were different from zero (I can elaborate on why, if there is interest). I have a patch now, that I'll commit in the following hours. This patch might disrupt some people's panoramas iff they use a script with both g and t <> 0. I think almost nobody does, because the parameters were useless. I suspect this is the reason they were never included in the hugin interface (besides the fact that they are of little practical use). Dev is finishing the code to add a new feature to the evaluation stack, called 'tilt'. This will be similar to shear, but will allow an effect similar to "shear" with independent parameters in each side of the image (think in terms of holding a photo and "tilting" it in any angle). Once his tilt code is finalized, the next step is to add code to the optimizer, in order for the new parameters of the tilt function to work. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] cropped output
Hi Dev,
I just checked the code.
The current version of PTmender does not support uncropped output (that
is done now by PTuncrop), except when the input image is fisheye.
Processing cropped is done for performance reasons. It greatly speeds up
processing (PTmender is significantly faster than nona). We don't do it
for fisheyes because we haven't developed a function to compute the
edges of its boundary reliably.
Essentially, any output format is ignored and converted to TIFF_m as
legacy. But a warning is output.
Should we enable it again? it is not hard to do, but I think it is
useless. WHat we should do is fix the calculation of the ROI (region of
interest).
I have the feeling that we have a bug in the way we compute the ROI in
the image when there is shift, but I am not sure. I'll look into
that. The code that does this is getROI
To disable cropped tiff output, it is easy: apply the following patch
(set croppedTIFFIntermediate = 0;)
Index: PTcommon.c
===
--- PTcommon.c (revision 1026)
+++ PTcommon.c (working copy)
@@ -738,6 +738,7 @@
if (prefs->im.format == _fisheye_circ) {
croppedTIFFIntermediate = 0;
}
+croppedTIFFIntermediate = 0;
colourCorrection = prefs->sBuf.colcorrect;
// This is a strange value:
--~--~-~--~~~---~--~~
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: Libpano locale fix
Hi Yuv, I have looked at the patch and this is the improper way to deal with this problem. It modifies a bunch of functions to reset the locale. It is too cross-cutting. Have you looked at the patch? It is basically ~40 insertions of this code: +setlocale(LC_ALL,old_locale); +free(old_locale); I suspect it would be easier to reset the locale in hugin after the panotools functions are called. that is just once place, compared to the 40 places that this patch would modify in libpano. What we need is to make libpano support internationalization. This is long overdue and might be a good project now that version 13 is out. What do others think? BTW, please reply to the panotools list. Yuval> http://sourceforge.net/tracker/?func=detail&atid=550441&aid=2826516&group_id=77506 Yuval> can somebody please apply the patch attached to Hugin's tracker to Yuval> Libpano? or even better: give Thomas Modes SVN write access to libpano? Yuval> Yuv Yuval> -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] License of file lu.c in hugin
Dear Antoine, I was going over the license statements of files in Hugin and I noticed that one file of which you are the author (src/hugin_base/hugin_math/lu.c) is licensed under the GPLv2. /* * * Licensed under the GPLv2 */ All other files in hugin as licensed under 'Version 2 of the License, or (at your option) any later version.' (including lu.h). Would you mind if this file is changed to 'Version 2 of the License, or (at your option) any later version.'? Thanks a lot! --daniel -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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] Files without license
Hi Everybody, I was going over the license statements in files in Hugin and discovered that the following files contain no license statement: ./src/hugin1/tests/test_projections.cpp ./src/hugin1/tools/color_correct_tiff.cpp ./src/hugin1/tools/img2vips.cpp ./src/hugin1/tools_vips/hdrmerge_vips.cpp ./src/hugin1/tools_vips/img2vips.cpp ./src/hugin_base/hugin_math/eig_jacobi.cpp ./src/hugin_base/panodata/PanoImage.cpp ./src/matchpoint/evaluation/c_eoverlap.cpp ./src/matchpoint/evaluation/descdist.cpp -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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: GSoC patch ideas
paul womack twisted the bytes to say:
paul> Bart.van.Andel wrote:
>> Although I'm not really into this code, shouldn't a divide by zero
>> result in NAN instead of INF?
paul> According to this:
paul> http://en.wikipedia.org/wiki/Division_by_zero
paul> It's well defined, and works as you would hope:
Yes, try this:
--
#include
#include
#include
int main(void)
{
double x = 0;
double y;
y = 1/x;
printf("hello world [%f]\n", y);
assert(isinf(y));
assert(isnan(y));
}
--
paul> IEEE floating-point standard, supported by almost all modern
paul> processors, specifies that every floating point arithmetic
paul> operation, including division by zero, has a well-defined
paul> result. In IEEE 754 arithmetic, a ÷ 0 is positive infinity when
paul> a is positive, negative infinity when a is negative, and NaN
paul> (not a number) when a = 0. The infinity signs change when
paul> dividing by -0 instead. This is possible because in IEEE 754
paul> there are two zero values, plus zero and minus zero, and thus
paul> no ambiguity.
BugBear
paul>
--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
--
Daniel M. German "I'm crazy, but I'm not stupid"
Jackie Chan
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
--~--~-~--~~~---~--~~
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: GSoC patch ideas
I am sorry Guido I dropped the ball from this. (This discussion should go into libpano, but there is also an issue with hugin). Hi Guido, I am looking at your patch right now, and I see you changed some of the computations. The biggest one I don't quite follow is: replacing: - C = cos(phi1) * cos(phi1) + 2.0 * n * sin(phi1); with + C = 1.0 + Aux_sin_phi1 * Aux_sin_phi2; I can try to follow the math but it is easier to ask you ;) Also, with respect to making it rho0 a huge number instead of letting the computation proceed with an INF value: rho0 = ( (n != 0) ? (Aux_1 / n) : (1.7E+308) ); I would prefer we use INF and deal with that where appropriate, which is the result of the calculation of the projection. Is hugin handling INF properly? It might be a problem in hugin, not in libpano. - twiceN = sin(phi1) + sin(phi2); - n = twiceN /2.0; - rho0 = sqrt(C - 2.0 * n * sin(phi0)) / n; +// precompute sinus functions +Aux_sin_phi0 = sin(phi0); +Aux_sin_phi1 = sin(phi1); +Aux_sin_phi2 = sin(phi2); + Aux_2N = Aux_sin_phi1 + Aux_sin_phi2; +n = Aux_2N / 2.0; + +// C = cos(phi1) * cos(phi1) + 2.0 * n * sin(phi1); +// rho0 = sqrt(C - 2.0 * n * sin(phi0)) / n; +Aux_1 = (C - (Aux_2N * Aux_sin_phi0)); +Aux_1 = ( (Aux_1 > 0) ? (sqrt(Aux_1)) : (0.0) ); +rho0 = ( (n != 0) ? (Aux_1 / n) : (1.7E+308) ); + -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- Daniel M. German "Sooner or later all the peoples of the world, without regard to the political system under which they live, will have to discover a way Martin Luther King, jr. -> to live together in peace." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
