From: Thomas S. <tks...@gm...> - 2010-01-05 02:14:55
|
Hi Daniel I am very happily using your MSVC projects to build libpano for testing, but one thing puzzles me: pano13.lib always gets fully rebuilt, even if just one source file (or even no files at all) have been altered. I thought I knew MSVC pretty well, but for the life of me I cannot figure out what is making it act like that. Do you know? Still wrestling with the inverse general panini code and the math on which it is based. But should have it working soon. Using PTmender for most tests, as you suggested. The hugin fast preview is nice, but there is a problem with vFOV decreasing every time it updates. Have patched a few things in libpano, e.g. parser would not accept 3 params, setMakeParams would post negative distance param (which causes an endless loop in rotate_equi()), .... Will commit those along with general_panini. Regards, Tom |
From: Jim W. <jwa...@ph...> - 2010-01-05 05:05:11
|
Thomas Sharpless wrote: > I am very happily using your MSVC projects to build libpano for > testing, but one thing puzzles me: pano13.lib always gets fully > rebuilt, even if just one source file (or even no files at all) have > been altered. I thought I knew MSVC pretty well, but for the life of > me I cannot figure out what is making it act like that. Do you know? I don't know why this is happening. I have seen sometimes with other projects, that if you try to run the debugger that it thinks the result it dirty and needs to be relinked even if it was just rebuilt, but not recompile everything. But Pano13.lib is the only one I know of that insist that the entire project needs to be rebuilt each time. I have not put much effort in tracking this down. Maybe I will have some time tomorrow. A search found this tibbit from another project, and it might give some insight. "Any project depending on a static library wants to recompile all source, whether it belongs to the (already-build) static library or only to the project." -- Jim Watters http://photocreations.ca |
From: D M G. <dm...@uv...> - 2010-01-05 07:28:38
|
HI Tom, Sorry for being quiet... beginning of term here at our university... and major deadline this weekend... but will catch up Tom> Hi Daniel Tom> I am very happily using your MSVC projects to build libpano for please thank Jim. he is the man behind. I develop under linux, using the old autogen/autoconf set of tools ;) --dmg Tom> testing, but one thing puzzles me: pano13.lib always gets fully Tom> rebuilt, even if just one source file (or even no files at all) Tom> have been altered. I thought I knew MSVC pretty well, but for the Tom> life of me I cannot figure out what is making it act like that. Tom> Do you know? Tom> Still wrestling with the inverse general panini code and the math Tom> on which it is based. But should have it working soon. Using Tom> PTmender for most tests, as you suggested. The hugin fast preview Tom> is nice, but there is a problem with vFOV decreasing every time it Tom> updates. I really want to look into it this week. --dmg Tom> Have patched a few things in libpano, e.g. parser would not accept 3 params, setMakeParams would post negative distance param (which causes an endless loop in Tom> rotate_equi()), .... Will commit those along with general_panini. Tom> Regards, Tom Tom> ------------------------------------------------------------------------------ Tom> This SF.Net email is sponsored by the Verizon Developer Community Tom> Take advantage of Verizon's best-in-class app development support Tom> A streamlined, 14 day to market process makes app distribution fast and easy Tom> Join now and get one step closer to millions of Verizon customers Tom> http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Tom> PanoTools-devel mailing list Tom> Pan...@li... Tom> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Thomas S. <tks...@gm...> - 2010-01-05 20:07:00
|
Thanks, Jim I can live with this, but would be very curious to know why it is happening. Let me know if you discover anything. Regards, Tom On Tue, Jan 5, 2010 at 12:04 AM, Jim Watters <jwa...@ph...>wrote: > Thomas Sharpless wrote: > > I am very happily using your MSVC projects to build libpano for > > testing, but one thing puzzles me: pano13.lib always gets fully > > rebuilt, even if just one source file (or even no files at all) have > > been altered. I thought I knew MSVC pretty well, but for the life of > > me I cannot figure out what is making it act like that. Do you know? > I don't know why this is happening. I have seen sometimes with other > projects, that if you try to run the debugger that it thinks the result > it dirty and needs to be relinked even if it was just rebuilt, but not > recompile everything. But Pano13.lib is the only one I know of that > insist that the entire project needs to be rebuilt each time. I have > not put much effort in tracking this down. Maybe I will have some time > tomorrow. > > A search found this tibbit from another project, and it might give some > insight. > "Any project depending on a static library wants to recompile all > source, whether it belongs to the (already-build) static library or only > to the project." > > > -- > > Jim Watters > http://photocreations.ca > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Pablo d'A. <pab...@we...> - 2010-01-05 20:43:59
|
Thomas Sharpless wrote: > Still wrestling with the inverse general panini code and the math on > which it is based. But should have it working soon. Using PTmender for > most tests, as you suggested. I have just added a pano_trafo utility program to hugin, which is probably also useful for testing the coordinate transforms. This will let you make some test case coordinate files and transform them easily. I tried to add it to libpano13, but the parser of libpano13 was not suitable for that, and I didn't want to duplicate the very strange things that PTmender does when parsing a script file. ciao Pablo |
From: Thomas S. <tks...@gm...> - 2010-01-06 05:38:56
|
Hey Pablo Happy New Year! Can you explain anything about how hugin is meant to negotiate FOV with libpano? The general Panini is unusual in that its max hFOV varies with the eye distance parameter, and I see some odd behavior under the hugin preview windows. In particular the vFOV jumps down at each update. g.P. also depends on converting the equirectangular source image to absolute angles in radians -- linearly proportional is not enough -- which I'm not sure is happening yet. That would mean a distanceparam (or a stand-in for it) that is independent of the hFOV setting. I'm confident I can work around any such problem inside libpano; but do you know if hugin takes any interest in distanceparam? I wonder why there are not separate source and dest distanceparams in PT? Best, Tom On Tue, Jan 5, 2010 at 3:43 PM, Pablo d'Angelo <pab...@we...> wrote: > Thomas Sharpless wrote: > > > Still wrestling with the inverse general panini code and the math on > > which it is based. But should have it working soon. Using PTmender for > > most tests, as you suggested. > > I have just added a pano_trafo utility program to hugin, which is > probably also useful for testing the coordinate transforms. This will > let you make some test case coordinate files and transform them easily. > > I tried to add it to libpano13, but the parser of libpano13 was not > suitable for that, and I didn't want to duplicate the very strange > things that PTmender does when parsing a script file. > > ciao > Pablo > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Jim W. <jwa...@ph...> - 2010-01-05 22:18:40
|
I found the following knowledge based article on Microsoft but it does not applies to us. http://support.microsoft.com/kb/326946 The actual cause of the problem was the naming of the .pdb file generated. Using the variable $(InputName).pdb caused the problem and changing it to pano13.pdb fixed it. While testing a few things I have found a couple issues with projects for the tools. - Builds use the same names for temporary files, this causes a file in use error on a multicore machines. - Set the structure alignment for the tools to 8 bytes. (this would be better done by using #pragma in the header files). One thing I hate about editing project files and saving them in VS is the order of the configurations and platform change. The number of changes that show up in the diff is much larger than the actual changes made. Jim Watters On 2010/01/05 3:06 PM, Thomas Sharpless wrote: > Thanks, Jim > > I can live with this, but would be very curious to know why it is > happening. Let me know if you discover anything. > > Regards, Tom -- Jim Watters http://photocreations.ca |
From: Thomas S. <tks...@gm...> - 2010-01-05 23:48:40
|
Thanks, Jim On Tue, Jan 5, 2010 at 5:18 PM, Jim Watters <jwa...@ph...>wrote: > I found the following knowledge based article on Microsoft but it does > not applies to us. > http://support.microsoft.com/kb/326946 > > The actual cause of the problem was the naming of the .pdb file > generated. Using the variable $(InputName).pdb caused the problem and > changing it to pano13.pdb fixed it. > Hooray! That works here too. > > While testing a few things I have found a couple issues with projects > for the tools. > - Builds use the same names for temporary files, this causes a file in > use error on a multicore machines. > Is that why manifest tool fails so often? - Set the structure alignment for the tools to 8 bytes. (this would be > better done by using #pragma in the header files). > done. > > One thing I hate about editing project files and saving them in VS is > the order of the configurations and platform change. The number of > changes that show up in the diff is much larger than the actual changes > made. > BTW how do you set WXWIDGETS_HOME and JAVA_HOME? I add a property sheet that defines those macros, so I don't have to fiddle with the environment. But that has to be local, and if I commit it will break the project. We should implement a CMake build control system, and get the MSVC projects & Makefiles the hell out of the source tree. It works for building 'hugin's own' pano13.lib. Best, Tom > Jim Watters > > > On 2010/01/05 3:06 PM, Thomas Sharpless wrote: > > Thanks, Jim > > > > I can live with this, but would be very curious to know why it is > > happening. Let me know if you discover anything. > > > > Regards, Tom > > -- > Jim Watters > http://photocreations.ca > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |