Panorama Tools

I would agree that the Java APIs are unnecessary in libpano13.  It is also
my impression that with the current source Java is entirely optional and
that libpano13 builds without it by default.  So what's the problem?

A much bigger problem in my mind is building the library as a Windows DLL.
I can build it as a static library without trouble, but there seem to be
some serious discrepancies between the source code and the .def file that
tells the Windows linker what symbols are to be exported.  It is tempting to
just remove the .def file lines that generate errors, but some of them may
be referenced by client programs and need to be fixed instead.  So I have
some questions for the PT developers...

-- Can anyone actually build a current libpano (12 or 13) as a Windows DLL?
-- Does any app link to a libpano DLL "by ordinal number"?  Or are C names
enough?
-- Can anyone produce a list of libpano13 entry points that are actually
usable? (i.e. not only declared but implemented and working)
-- Can anyone produce a list of such entry points that are actually called
by some app?

At a more specific level, does anyone know if any of the following entry
points should be considered necessary?

>  DLLInit
>  DispPrg
>  InfoPrg
>  SetWindowOwner
>
All are listed in the .def file but not found in the code by the linker.

The same is true for about 10 libtiff function names.  Does anyone know of a
reason why libpano should be exporting the functions of an independent
library?  Does any app actually call them via libpano?

Yours in perplexity,  Tom


On Sat, Sep 19, 2009 at 8:21 PM, Bruno Postle <bruno@...> wrote:

> On Sat 19-Sep-2009 at 16:05 -0700, Daniel M. German wrote:
> >I never understood how and why Java is used by libpano.
> >It would be really nice if we could abstract the java UI (I think
> >that is what it is used for) into a different package.
>
> ptpicker and pteditor are java and use libpano12.  They are
> abandoned and can't be relinked against libpano13, so it is a bit
> pointless having an interface for them.
>
> --
> Bruno
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> PanoTools-devel mailing list
> PanoTools-devel@...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>

Thomas> -- Can anyone produce a list of such entry points that are actually called by some app?

This is what the tools/* use:

panoCreatePanorama
panoFeatherFile
panoFileExists
panoFileMakeTemp
panoFileName
panoFileOutputNamesCreate
panoFlattenTIFF
panoPSDCreate
panoProjectionFeaturesQuery
panoReplaceExt
panoStitchReplaceMasks
panoTiffDisplayInfo
panoTiffRead
panoTiffVerifyAreCompatible







--
Daniel M. German                  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

I have been using a MS Visual Studio solution and project to build 
panotools and the tools for many years.  I have not used the CMake tools.

It has been a while since I have created pano13 into a dll but I am able 
to do it.
I have several configurations that I can build
Command | GUI
Debug | Release
Lib | DLL

The combinations give a total of 8.  All of them are built with Java 
support.

I was able to build GUI & DLL in both Debug and Release.
I was not able to build Command & DLL.  I get 20 unresolved external 
symbal errors
    1>pano13vc.def : error LNK2001: unresolved external symbol DLLInit

The difference between the two is if sys_ansi or sys_win is used in the 
project.
For the GUI applications like the Photoshop Plugins it requires sys_win 
but for the command tools like PTMender it requires the sys_ansi.

I am using pano13vc.def as the def file.

The PS Plugins use the following functions
FourToThreeBPP
SetWindowOwner
CopyImageData
SetImageDefaults
filter_main
writePSD
writePSDwithLayer
myfree

Jim Watters


Thomas Sharpless wrote:
> I would agree that the Java APIs are unnecessary in libpano13.  It is 
> also my impression that with the current source Java is entirely 
> optional and that libpano13 builds without it by default.  So what's 
> the problem?
>
> A much bigger problem in my mind is building the library as a Windows 
> DLL.  I can build it as a static library without trouble, but there 
> seem to be some serious discrepancies between the source code and the 
> .def file that tells the Windows linker what symbols are to be 
> exported.  It is tempting to just remove the .def file lines that 
> generate errors, but some of them may be referenced by client programs 
> and need to be fixed instead.  So I have some questions for the PT 
> developers...
>
> -- Can anyone actually build a current libpano (12 or 13) as a Windows 
> DLL?
> -- Does any app link to a libpano DLL "by ordinal number"?  Or are C 
> names enough?
> -- Can anyone produce a list of libpano13 entry points that are 
> actually usable? (i.e. not only declared but implemented and working)
> -- Can anyone produce a list of such entry points that are actually 
> called by some app?
>
> At a more specific level, does anyone know if any of the following 
> entry points should be considered necessary?
>
>      DLLInit
>      DispPrg
>      InfoPrg
>      SetWindowOwner
>
> All are listed in the .def file but not found in the code by the linker. 
>
> The same is true for about 10 libtiff function names.  Does anyone 
> know of a reason why libpano should be exporting the functions of an 
> independent library?  Does any app actually call them via libpano?
>
> Yours in perplexity,  Tom
>
>  
> On Sat, Sep 19, 2009 at 8:21 PM, Bruno Postle <bruno@... 
> <mailto:bruno@...>> wrote:
>
>     On Sat 19-Sep-2009 at 16:05 -0700, Daniel M. German wrote:
>     >I never understood how and why Java is used by libpano.
>     >It would be really nice if we could abstract the java UI (I think
>     >that is what it is used for) into a different package.
>
>     ptpicker and pteditor are java and use libpano12.  They are
>     abandoned and can't be relinked against libpano13, so it is a bit
>     pointless having an interface for them.
>
>     --
>     Bruno
>


-- 
Jim Watters
http://photocreations.ca

Thanks Dan & Jim

The problem I'm having with building a Windows DLL is that the .def file in
the SVN calls for a great many exports that are not present in the compiled
code.  The solution ought to be to provide a correct .def (actually a pair,
one without Java, one with).  Eveidently you have those, Jim;
maybe you could put them in the SVN trunk?

Regards, Tom


On Sun, Sep 20, 2009 at 12:33 AM, Jim Watters <jwatters@...:

> I have been using a MS Visual Studio solution and project to build
> panotools and the tools for many years.  I have not used the CMake tools.
>
> It has been a while since I have created pano13 into a dll but I am able
> to do it.
> I have several configurations that I can build
> Command | GUI
> Debug | Release
> Lib | DLL
>
> The combinations give a total of 8.  All of them are built with Java
> support.
>
> I was able to build GUI & DLL in both Debug and Release.
> I was not able to build Command & DLL.  I get 20 unresolved external
> symbal errors
>    1>pano13vc.def : error LNK2001: unresolved external symbol DLLInit
>
> The difference between the two is if sys_ansi or sys_win is used in the
> project.
> For the GUI applications like the Photoshop Plugins it requires sys_win
> but for the command tools like PTMender it requires the sys_ansi.
>
> I am using pano13vc.def as the def file.
>
> The PS Plugins use the following functions
> FourToThreeBPP
> SetWindowOwner
> CopyImageData
> SetImageDefaults
> filter_main
> writePSD
> writePSDwithLayer
> myfree
>
> Jim Watters
>
>
> Thomas Sharpless wrote:
> > I would agree that the Java APIs are unnecessary in libpano13.  It is
> > also my impression that with the current source Java is entirely
> > optional and that libpano13 builds without it by default.  So what's
> > the problem?
> >
> > A much bigger problem in my mind is building the library as a Windows
> > DLL.  I can build it as a static library without trouble, but there
> > seem to be some serious discrepancies between the source code and the
> > .def file that tells the Windows linker what symbols are to be
> > exported.  It is tempting to just remove the .def file lines that
> > generate errors, but some of them may be referenced by client programs
> > and need to be fixed instead.  So I have some questions for the PT
> > developers...
> >
> > -- Can anyone actually build a current libpano (12 or 13) as a Windows
> > DLL?
> > -- Does any app link to a libpano DLL "by ordinal number"?  Or are C
> > names enough?
> > -- Can anyone produce a list of libpano13 entry points that are
> > actually usable? (i.e. not only declared but implemented and working)
> > -- Can anyone produce a list of such entry points that are actually
> > called by some app?
> >
> > At a more specific level, does anyone know if any of the following
> > entry points should be considered necessary?
> >
> >      DLLInit
> >      DispPrg
> >      InfoPrg
> >      SetWindowOwner
> >
> > All are listed in the .def file but not found in the code by the linker.
> >
> > The same is true for about 10 libtiff function names.  Does anyone
> > know of a reason why libpano should be exporting the functions of an
> > independent library?  Does any app actually call them via libpano?
> >
> > Yours in perplexity,  Tom
> >
> >
> > On Sat, Sep 19, 2009 at 8:21 PM, Bruno Postle <bruno@...
> > <mailto:bruno@...>> wrote:
> >
> >     On Sat 19-Sep-2009 at 16:05 -0700, Daniel M. German wrote:
> >     >I never understood how and why Java is used by libpano.
> >     >It would be really nice if we could abstract the java UI (I think
> >     >that is what it is used for) into a different package.
> >
> >     ptpicker and pteditor are java and use libpano12.  They are
> >     abandoned and can't be relinked against libpano13, so it is a bit
> >     pointless having an interface for them.
> >
> >     --
> >     Bruno
> >
>
>
> --
> Jim Watters
> http://photocreations.ca
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> PanoTools-devel mailing list
> PanoTools-devel@...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>

Am Sonntag 20 September 2009 schrieb Thomas Sharpless:
> One more thing.  How does one build a static library with the present CMake
> script?  We need one for Hugin, and on Windows the DLL is not yet even
> buildable.

I compile on ubuntu, and don't need static library. But I could try to create this one too.

> -- Tom

	Kornel
-- 
Kornel Benko
Kornel.Benko@...

Hi Kornel

Please do commit the change to allow building static libpano; I will try it
on Windows.

Regards, Tom


On Sun, Sep 20, 2009 at 2:16 AM, Kornel Benko <Kornel.Benko@...:

> Am Sonntag 20 September 2009 schrieb Thomas Sharpless:
> > One more thing.  How does one build a static library with the present
> CMake
> > script?  We need one for Hugin, and on Windows the DLL is not yet even
> > buildable.
>
> I compile on ubuntu, and don't need static library. But I could try to
> create this one too.
>
> > -- Tom
>
>        Kornel
> --
> Kornel Benko
> Kornel.Benko@...
>

Am Sonntag 20 September 2009 schrieb Thomas Sharpless:
> Hi Kornel
>
> Please do commit the change to allow building static libpano; I will try it
> on Windows.
>
> Regards, Tom

Did it.

	Kornel

-- 
Kornel Benko
Kornel.Benko@...

On Sat 19-Sep-2009 at 19:08 -0700, Daniel M. German wrote:
>
>I'll really appreciate if people update the ChangeLog. And they can use
>the delta of the ChangeLog as the commit log message (which is what I
>do), but this is not as important.

The current ChangeLog file is created from the SVN commit messages.

-- 
Bruno

Am Sonntag 20 September 2009 schrieb Bruno Postle:
> On Sat 19-Sep-2009 at 19:08 -0700, Daniel M. German wrote:
> >I'll really appreciate if people update the ChangeLog. And they can use
> >the delta of the ChangeLog as the commit log message (which is what I
> >do), but this is not as important.
>
> The current ChangeLog file is created from the SVN commit messages.

How? I made a commit (white space only), but ChangeLog in repository did not change.

	Kornel
-- 
Kornel Benko
Kornel.Benko@...

On Sun 20-Sep-2009 at 11:53 +0200, Kornel Benko wrote:
>>
>> The current ChangeLog file is created from the SVN commit messages.
>
>How? I made a commit (white space only), but ChangeLog in repository did not change.

It is generated with svn2cl, but I usually only run it before a 
release.

-- 
Bruno

D M German wrote:
>  Bruno> /usr/local/bin/PTAInterpolate
>
> What does this program do? It is not built on my system.
>
> --dmg
>   
PTAinterpolate was written by Max Lyons as a replacement to PTInerpolate 
which never had the source code released like PTStitcher.
http://www.tawbaware.com/maxlyons/pano12ml.htm
http://wiki.panotools.org/PTInterpolate


-- 
Jim Watters
http://photocreations.ca