From: Bruno P. <br...@po...> - 2006-05-08 20:47:25
|
On Mon 08-May-2006 at 17:33 -0000, John Houghton wrote: > --- In Pan...@ya..., "Fernando Chaves" <fernchaves@...>=20 > wrote: > > I've just tried pano12 2.8.1 on winxp sp2 with Ptgui 5.8.2. > > When press "Preview" button I got the message:...impossible to find=20 > > entrance point to TIFFClose process in pano12.dll. >=20 > I get the same message: "The procedure entry point TIFFClose could not=20 > be located in the link library pano12.dll". This is output when=20 > PTStitcher is run, whether it's the final panorama or the preview. Thanks for the report, this seem to be the same bug encountered by=20 Manfred Kr=F6ger (libpano12.def doesn't export the same symbols as=20 pano12.def). Hmm, this file was created specifically _not_ to export the TIFFxxxx=20 symbols. It's confusing that this release fails when 2.8.0 which=20 was built against the same library versions is apparently ok (unless=20 nobody bothered to report that). I won't have access to a windows machine again until the end of the=20 week, but I'm not really the right person to investigate this=20 anyway. I'll delete the windows binaries from sourceforge unless=20 somebody else finds that they are working for them. --=20 Bruno |
From: Max L. <max...@ve...> - 2006-05-08 23:50:59
Attachments:
pano12_error.gif
|
Thanks for announcing this new release. I'm looking forward to trying out the new projections! Im having a little problem with it, however. PTOptimizer runs correctly with this new version, but when I try and run PTStitcher, I see a window with the following message (see attached screenshot): "The procedure entry point TIFFClose could not be located in the dynamic link library pano12.dll". I've tried this on two machines (Windows XP SP1, and Windows XP SP2) with the same result...Anyone have any thoughts on what might be causing this? Thanks, Max > Version 2.8.1 of libpano12 has been released: > > http://sourceforge.net/project/showfiles.php?group_id=96188&package_id=132440 > > This release contains many small bugfixes and a number of useful new > features. > > Changes since 2.8.0 > =================== > > Four new projection types have been added (Pablo d'Angelo) > > * Stereographic (use f4 in the 'p-line') > > * Mercator (use f5 in the 'p-line') > > * Transverse mercator (use f6 in the 'p-line') > > * Sinusoidal (use f7 in the 'p-line') > > http://www.panotools.info/mediawiki/index.php?title=Projections > > These work with existing versions of PTStitcher, PTmender and the > upcoming hugin-0.6. > > Support for radiance 32bit float .hdr files (Thomas Rauscher) > > A new API allows application developers to optionally supply their > own callback functions for error and progress reporting (Pablo > d'Angelo). > > The release includes version 0.4.0 of PTmender and PTblender > with some new features: > > * Flattened TIFFs (Daniel M. German) > > * JPEG and PNG output (Daniel M. German) > > * Cropped TIFF output files (use n"TIFF_m r:CROP" in the 'p-line', Max Lyons) > > * LZW compressed output (use n"TIFF_m c:LZW" in the 'p-line', Max Lyons) > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> > Everything you need is oneclick away. Make Yahoo! your home pagenow. > http://us.click.yahoo.com/AHchtC/4FxNAA/yQLSAA/.Cr1lB/TM > --------------------------------------------------------------------~-> > > <*> PanoTools.Info (wiki, news and more...) > http://www.panotools.info > > <*> PanoTools List Reader @ GMane: > http://news.gmane.org/gmane.comp.graphics.panotools > > Yahoo! Groups Links > > <*> To visit your group on the web, go to: > http://groups.yahoo.com/group/PanoTools/ > > <*> To unsubscribe from this group, send an email to: > Pan...@ya... > > <*> Your use of Yahoo! Groups is subject to: > http://docs.yahoo.com/info/terms/ > > > |
From: Bruno P. <br...@po...> - 2006-05-09 09:36:15
|
Max Lyons wrote: > Thanks for announcing this new release. I'm looking forward to trying = out the=20 > new projections! >=20 > Im having a little problem with it, however. PTOptimizer runs correctl= y with=20 > this new version, but when I try and run PTStitcher, I see a window wit= h the=20 > following message (see attached screenshot): >=20 > "The procedure entry point TIFFClose could not be located in the dynami= c link=20 > library pano12.dll". Yes the windows binary is broken, I didn't test it and I guess=20 nobody else did :-( Next time we'll announce release candidates on the main panotools list. I've rebuilt it quickly using the hack given by Manfred Kr=F6ger=20 (copying pano12.def onto libpano12.def): http://panotools.sourceforge.net/snapshots/pano12-2.8.1rc3-win32.zip This one does work for me with both PTmender.exe and PTStitcher.exe,=20 though some notes from a few minutes testing: * PTmender crashes if the -o parameter isn't given (though it is no=20 longer space-sensitive). * The new projections work with both PTmender.exe and PTStitcher.exe. * LZW support in PTmender.exe is broken as the library I linked-to=20 doesn't have LZW support. * Cropped TIFF crashes PTmender.exe. Somebody is needed to take over win32 support, I don't really use=20 this platform so the current situation is less than ideal. --=20 Bruno |
From: Bruno P. <br...@po...> - 2006-05-09 20:53:41
|
On Tue 09-May-2006 at 10:33 +0100, Bruno Postle wrote: > > though some notes from a few minutes testing: > > * PTmender crashes if the -o parameter isn't given (though it is no > longer space-sensitive). This is a windows only problem. > * LZW support in PTmender.exe is broken as the library I linked-to > doesn't have LZW support. LZW compression works fine on Linux, though only for n"TIFF_m" and n"TIFF_mask". n"TIFF" files end up uncompressed. > * Cropped TIFF crashes PTmender.exe. Same problem on Linux, I thought this was working. -- Bruno |
From: Daniel M. G. <dmg...@uv...> - 2006-05-09 20:58:21
|
Bruno Postle twisted the bytes to say: Bruno> This is a windows only problem. >> * LZW support in PTmender.exe is broken as the library I linked-to >> doesn't have LZW support. Bruno> LZW compression works fine on Linux, though only for n"TIFF_m" and Bruno> n"TIFF_mask". n"TIFF" files end up uncompressed. Yes, this is due to the way PTmender works (it uses files as temporary storage). I'll have to update it so it uses the same type of compression in the final stages of the creation of the panorama too. It should not be a problem. >> * Cropped TIFF crashes PTmender.exe. Bruno> Same problem on Linux, I thought this was working. I'll investigate. I have not even try them. -- Daniel M. German "I did not believe the information, Peter Gabriel -> I just had to trust imagination." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2006-05-15 04:24:21
|
> >> * Cropped TIFF crashes PTmender.exe. > > Bruno> Same problem on Linux, I thought this was working. > > I'll investigate. I have not even try them. > All: I added the ability for PTMender to output cropped TIFF files a couple of months ago. The code has been moved around a little since I added it, but the bulk of it currently resides in /libpano/PTCommon.c (look for the croppedOutput variable and the getROI function). The code works by only requesting that Pano Tools remap the pixels inside a region of interest that contains the input file, rather than all pixels in the output canvas area. However, it doesn't currently work in conjunction with the "fast transform" code (see MyTransform() in resample.c). It appears that the fast transform code crashes unless the function is asked to remap the entire canvas area. In the short run, the solution is no to use cropped TIFF output in conjunction with the fast transform feature (i.e. don't add "f0" to the "m" line in a PTStitcher/PTMender script). In the longer run, I think that the fast transform code needs to be updated. I looked at this briefly a couple of months ago, and think that it is possible...I just haven't had time to do it. If anyone else has more familiarity with this code, then please feel free to fix it! Max |
From: Bruno P. <br...@po...> - 2006-05-15 11:32:07
|
On Mon 15-May-2006 at 00:24 -0400, Max Lyons wrote: > > > > * Cropped TIFF crashes PTmender.exe. > > > > Bruno> Same problem on Linux, I thought this was working. > In the short run, the solution is no to use cropped TIFF output in conjunction > with the fast transform feature (i.e. don't add "f0" to the "m" line in a > PTStitcher/PTMender script). Thanks, my problem was that the stitcher scripts produced by hugin always have "f0" set, PTmender is fine after editing the file. -- Bruno |
From: Max L. <max...@ve...> - 2006-05-16 02:34:40
|
I've found and the fixed bug in the fast transform code that was preventing cropped TIFFs being output by PTMender when the fast transform feature was enabled. The bug was in resample.c. PTMender can now output cropped TIFF files when the fast transform code is also used. When these two features (cropped TIFF and fast transform) are used together, the result is that tiff_m format files can be generated extremely quickly with virtually no memory use, even for projects with large numbers of files. To enable cropped TIFF output, the p line in the stitcher script should specify the output format like this example: p w4454 h1620 f1 u20 v22 n"TIFF_m r:CROP" To use the fast transform code, the m line in the stitched script should include "f0" like this example: m i1 g1 f0 Below is the changelog of my changes over the last couple of days. (I sent an e-mail yesterday to this list with most of this information, but it didn't appear to have made it to the list): 2006-05-16 Max Lyons (max...@ta...) * resample.c: Fixing bug in fast transform logic that caused crash when destRect.left != 0 (i.e. producing cropped TIFF output) 2006-05-15 Max Lyons (max...@ta...) * Removed old versions of ptcommon and colourbrightness from the tools...these had already been moved into libpano main directory * Updated Makefile.win32 to include missing references to sys_common.c, PTCommon.c, hdrfile.c, rgbe.c, ColourBrightness.c...should now build correctly using MingW * pano12.def: Removed duplicate entry for "StringtoFullPath" (exported twice). * PTcommon.c: Changed #include <filter.h> to #include "filter.h" (this prevented compilation with MingW) * PTcommon.c: Changed call to execute_stack to execute_stack_new (necessary as a result of modification to Transformation function type) * PTcommon.c: Removed InsertFileName definition. This is already defined in PTPicker, and prevented compilation with MingW. * ColourBrightness.c: Changed #include <filter.h> to #include "filter.h" (this prevented compilation with MingW) * PTBlender: Fixed comparison between pointer and integer error (line 102) Max > On Mon 15-May-2006 at 00:24 -0400, Max Lyons wrote: > > > > > > * Cropped TIFF crashes PTmender.exe. > > > > > > Bruno> Same problem on Linux, I thought this was working. > > > In the short run, the solution is no to use cropped TIFF output in conjunction > > with the fast transform feature (i.e. don't add "f0" to the "m" line in a > > PTStitcher/PTMender script). > > Thanks, my problem was that the stitcher scripts produced by hugin > always have "f0" set, PTmender is fine after editing the file. > > -- > Bruno > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel |
From: Bruno P. <br...@po...> - 2006-05-10 21:19:42
|
The windows binaries of libpano12-2.8.1 have been rebuilt and should now actually work: http://sourceforge.net/project/showfiles.php?group_id=96188&package_id=132440 The file has the same name as before but is slightly smaller: pano12-2.8.1-win32.zip 412kB I've tested the DLL with PTStitcher.exe, PTmender.exe and nona.exe and it seems to be ok. This version has LZW compression enabled. Note: A windows user is needed to create these in the future. I've built this on a borrowed XP laptop that doesn't have PTgui or PTassembler installed so it's not exactly easy to test. -- Bruno |
From: douglas w. <dgs...@ya...> - 2006-05-31 00:59:00
|
Hi there, ----- Original Message ---- [snip]> Thanks for the report, this seem to be the same bug encountered by= =20 > Manfred Kr=F6ger (libpano12.def doesn't export the same symbols as=20 > pano12.def). > Hmm, this file was created specifically _not_ to export the TIFFxxxx=20 > symbols. It's confusing that this release fails when 2.8.0 which=20 > was built against the same library versions is apparently ok (unless=20 > nobody bothered to report that). Just some insight into all of this, seeing as I created the additional .def= files originally :-) The reason that libpano12.def was created was specifically to _not_ export = the tiff definitions. This was because of a somewhat subtle bug that is int= roduced on the windows platform when the tiff definitions are re-exported a= nd the panotools lib is built statically.=20 The short explanation (longer one on request :-)) is that the tiff library = exists in two places, statically linked into the panotools library and _als= o_ statically linked into the application (in my case hugin). Not only that= but those tiff functions available are linked from the pano12 and the rest= from libtiff. What then happens is that portions of the application code i= ntialise the tiff library, but only in _one_ of the linked versions, leadin= g to some wierd and intermittent errors, depending on the link order. By re= moving the tiff exports, the application will only link to the tiff library= for tiff functions and all is well. This does not of course happen on the = linux platform as all libraries are dynamically linked to pano12.so :-) Unfortunately I could not remove the tiff exports out of pano12.def as (poo= rly behaved) PTStitcher relied on them! Now that PTMender is available, per= haps it is time once and for all to remove pano12.def? regards, Doug |
From: Daniel M. G. <dmg...@uv...> - 2006-05-31 06:59:37
|
douglas> Unfortunately I could not remove the tiff exports out of pano12.def as (poo= douglas> rly behaved) PTStitcher relied on them! Now that PTMender is available, per= douglas> haps it is time once and for all to remove pano12.def? douglas> regards, douglas> Doug One of the big questions we need to answer is when to stop supporting PTstitcher. PTmender does not do everything PTstitcher does, and viceversa. dmg -- Daniel M. German "You could wind up belivin' that paradise is nothin' more than a feelin' Marillion -> that goes on in your mind." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |