Panorama Tools

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:
>     PanoTools-unsubscribe@...
> 
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
>  
> 
>

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

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

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 .

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

>  >> * 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

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

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 (maxlyons@...)

	* 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 (maxlyons@...)

	* 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
> PanoTools-devel@...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel

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

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 .