vxl-users — General mailing list for vxl users

Re: [Vxl-users] rubberbanding

[Amitha P. <pe...@cs...>]

My experience is that it works with GTK, but not with Windows/MFC. I
have no experience with Qt, but the problem you are describing seems
to match the behaviour with MFC.

Not much help, I'm afraid. Perhaps someone with more experience with
vgui will elaborate.

Amitha.

On Thu, Jan 31, 2002 at 09:07:38AM +0100, David Serby wrote:
> I set the GUI toolkit to qt (setenv vgui qt) and tried out the
> rubberband example in vgui/examples/kym. But there was no rubberbanding
> effect at all. The object (line, circle, ...) appeared only after having
> finished drawing it.
> 
> Has anybody ever tried this out? Or has anybody an idea why it doesn't
> work?
> 
> Regards,
> 
> David
> 
> 
> _______________________________________________
> Vxl-users mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-users

RE: [Vxl-users] Avoiding problems with smart pointers

[<Pet...@es...>]

> Is it true that only objects derived from vbl_ref_count can be used with smart pointers?

Not really: the only requirement is that the object must have a method ref() and a method unref().
These methods are themselves responsible for maintaining the reference count, and for deleting the object when the ref count goes from 1 to 0.
vbl_ref_count does all this, but vbl_smart_ptr does not assume you are using vbl_ref_count.


> That would rule out a smart pointer to a vnl_vector

Yes, indeed, since vnl_vector does not have a ref() or unref()


> or any one of its children, correct?

Not necessarily: you may derive from vnl_vector, thereby adding methods ref() and unref().


	Peter.

RE: [Vxl-users] Avoiding problems with smart pointers

[Ian S. <ian...@st...>]

No,

The object being pointed to is a pure abstraction as far as vbl_smart_ptr is
concerned. Anything that correctly implements ref() and unref() will work.
This is the beaty of templates.

Ian.

> -----Original Message-----
> From: Rob Campbell [mailto:rob...@at...]
> Sent: Thursday, January 31, 2002 11:10 AM
> To: vxl...@li...
> Subject: RE: [Vxl-users] Avoiding problems with smart pointers
>
>
> Thanks for the explaination.  I'll be sure to follow these guidelines.
>
> I have an unrelated question on VXL's smart pointers.  Is it
> true that only
> objects derived from vbl_ref_count can be used with smart
> pointers?  That
> would rule out a smart pointer to a vnl_vector or any one  of
> its children,
> correct?
>
> Thanks,
> Rob Campbell
> rob...@at...
>
> > -----Original Message-----
> > From: Pet...@es...
> > [mailto:Pet...@es...]
> > Sent: Thursday, January 31, 2002 5:53 AM
> > To: vxl...@li...; rob...@at...
> > Subject: Re: [Vxl-users] Avoiding problems with smart pointers
> >
> >
> > > Maybe by preventing assignment of normal pointers to
> smart pointers?
> >
> > Never assign the address of a local variable to a smart pointer.
> > More generally, a good rule-of-thumb in C++ is to never use
> > the "address of" (&) operator.
> >
> >
> > > 	vcsl_spatial aSpatial;
> > > 	vcsl_spatial *aPtr = new vcsl_spatial;
> >
> > In principle, never create a vcsl_spatial on the stack;
> > always use "new",
> > and immediately assign it to a smart pointer.
> > (This holds for every class that is designed to be accessed
> > though smart pointers.)
> > I.e., never use the "vcsl_spatial" type but use
> > "vcsl_spatial_sptr" exclusively:
> >
> > 	vcsl_spatial_sptr aPtr = new vcsl_spatial;
> > 	...
> > 	aPtr->valid_time(0);
> >
> > Consider "vcsl_spatial" as a "protected" implementation, and
> > "vcsl_spatial_sptr" as the interface.
> >
> >
> > --  Peter.
> >
>
>
> _______________________________________________
> Vxl-users mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-users
>

RE: [Vxl-users] Avoiding problems with smart pointers

[Rob C. <rob...@at...>]

Thanks for the explaination.  I'll be sure to follow these guidelines.

I have an unrelated question on VXL's smart pointers.  Is it true that only
objects derived from vbl_ref_count can be used with smart pointers?  That
would rule out a smart pointer to a vnl_vector or any one  of its children,
correct?

Thanks,
Rob Campbell
rob...@at...

> -----Original Message-----
> From: Pet...@es...
> [mailto:Pet...@es...]
> Sent: Thursday, January 31, 2002 5:53 AM
> To: vxl...@li...; rob...@at...
> Subject: Re: [Vxl-users] Avoiding problems with smart pointers
>
>
> > Maybe by preventing assignment of normal pointers to smart pointers?
>
> Never assign the address of a local variable to a smart pointer.
> More generally, a good rule-of-thumb in C++ is to never use
> the "address of" (&) operator.
>
>
> > 	vcsl_spatial aSpatial;
> > 	vcsl_spatial *aPtr = new vcsl_spatial;
>
> In principle, never create a vcsl_spatial on the stack;
> always use "new",
> and immediately assign it to a smart pointer.
> (This holds for every class that is designed to be accessed
> though smart pointers.)
> I.e., never use the "vcsl_spatial" type but use
> "vcsl_spatial_sptr" exclusively:
>
> 	vcsl_spatial_sptr aPtr = new vcsl_spatial;
> 	...
> 	aPtr->valid_time(0);
>
> Consider "vcsl_spatial" as a "protected" implementation, and
> "vcsl_spatial_sptr" as the interface.
>
>
> --  Peter.
>

Re: [Vxl-users] Avoiding problems with smart pointers

[<Pet...@es...>]

> Maybe by preventing assignment of normal pointers to smart pointers?

Never assign the address of a local variable to a smart pointer.
More generally, a good rule-of-thumb in C++ is to never use the "address of" (&) operator.


> 	vcsl_spatial aSpatial;
> 	vcsl_spatial *aPtr = new vcsl_spatial;

In principle, never create a vcsl_spatial on the stack; always use "new",
and immediately assign it to a smart pointer.
(This holds for every class that is designed to be accessed though smart pointers.)
I.e., never use the "vcsl_spatial" type but use "vcsl_spatial_sptr" exclusively:

	vcsl_spatial_sptr aPtr = new vcsl_spatial;
	...
	aPtr->valid_time(0);

Consider "vcsl_spatial" as a "protected" implementation, and "vcsl_spatial_sptr" as the interface.


--  Peter.

[Vxl-users] rubberbanding

[David S. <ds...@vi...>]

I set the GUI toolkit to qt (setenv vgui qt) and tried out the
rubberband example in vgui/examples/kym. But there was no rubberbanding
effect at all. The object (line, circle, ...) appeared only after having
finished drawing it.

Has anybody ever tried this out? Or has anybody an idea why it doesn't
work?

Regards,

David

[Vxl-users] Avoiding problems with smart pointers

[Rob C. <rob...@at...>]

I found out about this the hard way.  You may already be aware of it.  Is
there a way to prevent it?  Maybe by preventing assignment of normal
pointers to smart pointers?

In the following program, the assignment of either aPtr or the address of
aSpatial (depending on the definition of INNER_CRASH) to aSPtr will ref()
that object, increasing its reference count from 0 to 1.  When aSPtr goes
out of scope, its destructor will unref() the object, decreasing its
reference count from 1 to 0.  When this happends, unref() actually deletes
the object.

If INNER_CRASH is defined, this means it will try to delete aSpatial and
crash immediately.  If INNER_CRASH is not defined, it will delete the object
pointed to by aPtr.  The program will then crash as soon as soon as it tries
to acces the object via "aPtr->valid_time(0)".

Rob Campbell

#include <iostream>
#include <vxl/vxl/vcsl/vcsl_spatial.h>

#define INNER_CRASH

int main()
{
	vcsl_spatial aSpatial;
	vcsl_spatial *aPtr = new vcsl_spatial;

	{
		#ifdef INNER_CRASH
			vcsl_spatial_sptr aSPtr = &aSpatial;
		#else
			vcsl_spatial_sptr aSPtr = aPtr;
		#endif
	}
	std::cout << "Outside of inner scope\n";

	aPtr->valid_time(0);

	return 1;
}
Robert J. Campbell Jr.
rob...@at...

RE: [Vxl-users] Brief coordinate system how-to?

[Rob C. <rob...@at...>]

Thanks.  This is better than I ever hoped.  Are there links to this
information from the VXL website?  If there are, I missed them.  If not, I
think there should be.

Does the VXL project have the right to use this documentation?  I have
Acrobat Distiller, so at a minimum I could create PDF versions of these
documents to place on the VXL website.  Even better, it would be nice to
update them to reflect VXL and incorporate them in the VXL book.

Thanks again for your help.

Rob Campbell
rob...@at...

> -----Original Message-----
> From: Pet...@es...
> [mailto:Pet...@es...]
> Sent: Friday, January 25, 2002 6:56 AM
> To: rob...@at...; ian...@st...
> Subject: RE: [Vxl-users] Brief coordinate system how-to?
>
>
> > The co-ordinates systems stuff may have been ported from TargetJr.
> > http://www.google.com/search?q=targetjr Perhaps some
> documentation can be
> > found there.
>
> Actually, to be more precise: from the IUE.
> Have a look at
> ftp://ftp.esat.kuleuven.ac.be/pub/psi/visics/TargetJr/CDROM/iu
> e-overview.gtar.gz
> and extract the file Overview/ov-c7-coordsys.ps from this tar file.
>
>
> > Peter, I see that vcsl was imported into the CVS tree by
> > remcvs_depot_balltown.
>
> This is a pseudo-account at the "offsite" of GE-CRD.
> From the vcsl files, I understand that Francois Bertel did
> the porting.
> I suppose that Peter Tu (tu...@cr...) should be able to
> give more details.
>
>
> 	Peter.
>

RE: [Vxl-users] [CONTRIBUTION] vcsl_tutorial.cpp

[Rob C. <rob...@at...>]

Thanks for correcting me.  It's good advice that I'm going to start
following in my own project, fclib.sourceforge.net.

Rob Campbell
rob...@at...

> -----Original Message-----
> From: vxl...@li...
> [mailto:vxl...@li...]On Behalf Of Andrew
> Fitzgibbon
> Sent: Monday, January 28, 2002 5:55 AM
> To: 'Peter Vanroose'; 'Rob Campbell'
> Cc: vxl...@li...
> Subject: RE: [Vxl-users] [CONTRIBUTION] vcsl_tutorial.cpp
>
>
>
> Thanks for the contribution Rob!
>
> The body of the code looks great, but I would suggest that
> the headers are changed to follow the principles in the VXL
> book.  To summarize, because they may prove useful:
>
> 0.  Use forward slashes in include lines.
>     Rationale:
>     Very few operating systems use backslash as a filename
>     separator.
>
> 1.  All standard headers included as <x> should use <vcl_x.h>
>     Rationale:
>     This is the only supported way to get cross-platform
>     portability.
>
> 2.  Order from general to specific.
>     Rationale:
>     Think of inheritance -- the more general (base) class must
>     be defined before the more specific (dervied) class.
>     If this order is not possible -- i.e. there is a cycle,
>     that's a bug in the libraries, and should be fixed.
>
>     Note that vcsl depends on vnl, so vnl headers should be
>     included first.
>
> 3.  Use <> rather than "".
>     Rationale:
>     Safety -- one might copy the example file elsewhere, to
>     a directory with confusing contents.  The -I flags should
>     control the order of search, not the contents of the current
>     directory.
>
> 4.  The exception to 2 and 3 is the header file corresponding
>     to the current .cxx file.   This should be included at the
>     top of file.cxx, in "", with no path.
>     Rationale:
>     If the .h is at the top of the file, it ensures it's
>     free-standing and doesn't have any hidden dependencies.
>     Forces the .cxx and .h to be copied together, as a change
>     in the cxx will probably require a change in .h, and on many
>     compilation environments, it's hard to get the cxx right
>     unless the compiler includes exactly the correct .h.
>
> So, in the supplied example, the head of the file should be
>
> #include <vcl_iostream.h>
> #include <vxl/vxl/vnl/vnl_math.h>
> #include <vxl/vxl/vcsl/vcsl_cartesian_3d.h>
> #include <vxl/vxl/vcsl/vcsl_translation.h>
> #include <vxl/vxl/vcsl/vcsl_rotation.h>
> #include <vxl/vxl/vcsl/vcsl_displacement.h>
> #include <vxl/vxl/vcsl/vcsl_graph.h>
>
>
>
> _______________________________________________
> Vxl-users mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-users

RE: [Vxl-users] [CONTRIBUTION] vcsl_tutorial.cpp

[Andrew F. <aw...@ro...>]

Doh. Yes.  Thanks!

> Well, actually, it should be:
> 
> #include <vcl_iostream.h>
> #include <vnl/vnl_math.h>
> #include <vcsl_cartesian_3d.h>
> #include <vcsl/vcsl_translation.h>
> #include <vcsl/vcsl_rotation.h>
> #include <vcsl/vcsl_displacement.h>
> #include <vcsl/vcsl_graph.h>
> 
> I will soon CVS commit this new file.
> 
> 
> 	Peter.
> 

RE: [Vxl-users] [CONTRIBUTION] vcsl_tutorial.cpp

[Peter V. <Pet...@es...>]

> So, in the supplied example, the head of the file should be
> 
> #include <vcl_iostream.h>
> #include <vxl/vxl/vnl/vnl_math.h>
> #include <vxl/vxl/vcsl/vcsl_cartesian_3d.h>
> #include <vxl/vxl/vcsl/vcsl_translation.h>
> #include <vxl/vxl/vcsl/vcsl_rotation.h>
> #include <vxl/vxl/vcsl/vcsl_displacement.h>
> #include <vxl/vxl/vcsl/vcsl_graph.h>

Well, actually, it should be:

#include <vcl_iostream.h>
#include <vnl/vnl_math.h>
#include <vcsl_cartesian_3d.h>
#include <vcsl/vcsl_translation.h>
#include <vcsl/vcsl_rotation.h>
#include <vcsl/vcsl_displacement.h>
#include <vcsl/vcsl_graph.h>

I will soon CVS commit this new file.


	Peter.

RE: [Vxl-users] [CONTRIBUTION] vcsl_tutorial.cpp

[Andrew F. <aw...@ro...>]

Thanks for the contribution Rob!

The body of the code looks great, but I would suggest that 
the headers are changed to follow the principles in the VXL 
book.  To summarize, because they may prove useful:

0.  Use forward slashes in include lines.
    Rationale:
    Very few operating systems use backslash as a filename 
    separator.

1.  All standard headers included as <x> should use <vcl_x.h>
    Rationale:
    This is the only supported way to get cross-platform 
    portability.

2.  Order from general to specific.  
    Rationale:
    Think of inheritance -- the more general (base) class must 
    be defined before the more specific (dervied) class.
    If this order is not possible -- i.e. there is a cycle,
    that's a bug in the libraries, and should be fixed.

    Note that vcsl depends on vnl, so vnl headers should be 
    included first.

3.  Use <> rather than "".  
    Rationale:
    Safety -- one might copy the example file elsewhere, to 
    a directory with confusing contents.  The -I flags should
    control the order of search, not the contents of the current 
    directory.

4.  The exception to 2 and 3 is the header file corresponding 
    to the current .cxx file.   This should be included at the 
    top of file.cxx, in "", with no path.
    Rationale:
    If the .h is at the top of the file, it ensures it's 
    free-standing and doesn't have any hidden dependencies.
    Forces the .cxx and .h to be copied together, as a change 
    in the cxx will probably require a change in .h, and on many
    compilation environments, it's hard to get the cxx right 
    unless the compiler includes exactly the correct .h.

So, in the supplied example, the head of the file should be

#include <vcl_iostream.h>
#include <vxl/vxl/vnl/vnl_math.h>
#include <vxl/vxl/vcsl/vcsl_cartesian_3d.h>
#include <vxl/vxl/vcsl/vcsl_translation.h>
#include <vxl/vxl/vcsl/vcsl_rotation.h>
#include <vxl/vxl/vcsl/vcsl_displacement.h>
#include <vxl/vxl/vcsl/vcsl_graph.h>

Re: [Vxl-users] [CONTRIBUTION] vcsl_tutorial.cpp

[Peter V. <Pet...@es...>]

> Here is a little program I wrote to help me figure out how to use the vcsl
> library.  It's heavily commented.  It could shorten the learning curve for
> the next person trying to figure them out.  Is there a place for it?

Thanks for supplying this, and also for the addition of comments in the source
code of vcsl_spatial.  I have put the tutor programme in vcsl/examples/.

There are still some problems with object creation/deletion which I'm
currently looking into.  More specifically, vcl_vector data members
should not be stored as pointers but as plain vcl_vectors, hence
solving the problem of missing deletes in destructors, and also solving
an other problem: methods like parent(), scale(), beat() now return
a pointer to a data member, which defeats the data hiding principle.
With the changed approach, they return a copy of the vcl_vector.

I'll CVS commit these changes a.s.a.p., after thorough checking.


	Peter.

[Vxl-users] [PATCH] vcsl_spatial::set_unique() didn't make 'this' potential child of parent_

[Rob C. <rob...@at...>]

Here are a couple of patches for vcsl_spatial.h and vcsl_spatial.cxx.  The
significant change is to set_unique().  It was not not making 'this' a
potential child of the parent specified in the parameter list.  At least one
consequence of this was a crash in recursive_path_from_local_to_cs_exists()
when trying to reach the CS from its parent.

The other changes I made to both files was to add a lot of comments.

I'm not sure if the patches are the right format.  I created them with
"cvs -diff".  Please let me know, either way.  Also, please let me know if
the patches work for you and if/when they're checked into CVS.

Thanks,
Robert J. Campbell Jr.
rob...@at...

[Vxl-users] [CONTRIBUTION] vcsl_tutorial.cpp

[Rob C. <rob...@at...>]

Here is a little program I wrote to help me figure out how to use the vcsl
library.  It's heavily commented.  It could shorten the learning curve for
the next person trying to figure them out.  Is there a place for it?

Thanks,
Robert J. Campbell Jr.
rob...@at...

Re: [Vxl-users] Re: Problems with VXL 1.0 beta installation

[Peter V. <Pet...@es...>]

> > # My executable that depends (only) on mvl
> > ADD_EXECUTABLE( myexec mysource )
> > INCLUDE( ${allvxl_SOURCE_DIR}/oxl/mvl/CMakeListsLink.txt )
> 
> Excellent -- but where do I put that?  In a new CMakeListsLink.txt in my
> executable directory?  In the source file itself?  And does it handle run-time
> linking, too?

If you are using CMake, you just have to add that INCLUDE line to the
CMakeLists.txt file in the executable directory.
That's the main advantage of using CMake as compared to gmake,
where you must specify all libraries explicitly.


	Peter.

[Vxl-users] Re: Problems with VXL 1.0 beta installation

[Peter V. <Pet...@es...>]

> Warning: this may cause a link line explosion! It doesn't affect
> compilation speed or the resulting executable, but it may make the
> link line a little difficult to read.

And an other problem: on some platforms (notably SGI) there seems to be
a limit on the length of the rpath specified when linking an executable.

A solution to this would be to let CMake delete duplicates, which it
does not right now.

The solution which I'm using now is to specify LIBRARY_OUTPUT_PATH
(hence all libraries are put into a single directory).


	Peter.

Re: [Vxl-users] Re: Problems with VXL 1.0 beta installation

[Nick H. <nic...@ya...>]

--- Pet...@es... wrote:
> These should be in libqt.so (the Qt library, not from vxl).
> Maybe a Qt version problem?
 
Possibly, the library's there, the compiler finds it, it's just not finding
stuff inside it.  The graphics stuff is more trouble than it's worth -- because
of my system configuration, not VXL.
 
> > /home/hurlburt/code/vxl/oxl/mvl/libmvl.so: undefined reference to
> > `vnl_scatter_3x3<double>::compute_eigensystem()'
> 
> These are not in libvnl.so but in libvnl-algo.so

<slaps forehead in frustration>

Oh!  Yep, finds it all just fine, now.

--- Amitha Perera <pe...@cs...> wrote:
> # My executable that depends (only) on mvl
> ADD_EXECUTABLE( myexec mysource )
> INCLUDE( ${allvxl_SOURCE_DIR}/oxl/mvl/CMakeListsLink.txt )

Excellent -- but where do I put that?  In a new CMakeListsLink.txt in my
executable directory?  In the source file itself?  And does it handle run-time
linking, too?

Thanks ... again,
Nick


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

Re: [Vxl-users] Re: Problems with VXL 1.0 beta installation

[Amitha P. <pe...@cs...>]

> ... as well as in a program of my own, in which I use mvl, but
> libmvl.so can't resolve its own calls to libvnl.so:

The current way to do this "properly" is to use the
CMakeListsLink.txt. Using these, you only have to specify your
immediate dependencies, and the CMakeListsLink.txt takes care of all
the other dependencies.

# My executable that depends (only) on mvl
ADD_EXECUTABLE( myexec mysource )
INCLUDE( ${allvxl_SOURCE_DIR}/oxl/mvl/CMakeListsLink.txt )

Warning: this may cause a link line explosion! It doesn't affect
compilation speed or the resulting executable, but it may make the
link line a little difficult to read. Unfortunately, this is the best
way to do things until CMake gets more intelligent about dependency
handling.

Amitha.

Re: [Vxl-users] gnuawk --> awk (solaris)

[<Pet...@es...>]

> could we replace it with a syntax that works also with the sun awk?
> for example:
> 
> version=`$CXX -v < /dev/null 2>&1 | grep 'gcc version' | awk '{print $3}}'`

Agreed.  Especially since that "grep 'gcc version'" is already on the previous line.
I'll change this in CVS.


	Peter.

[Vxl-users] RE: [Vxl-maintainers] casting instead of rounding in templates

[Ian S. <ian...@st...>]

> (is vxl-maintainers a subset of vxl-users?)
>
>

No, they are two different lists. However, anyone who receives
vxl-maintainers is very likely to also receive vxl-users.

[Vxl-users] gnuawk --> awk (solaris)

[Manuel O. <moe...@vi...>]

Hi

In the configure.in file under config.cmake is a syntax from gnuawk
used.

version=`$CXX -v < /dev/null 2>&1 | awk '{if(/gcc version/){print $3}}'`

could we replace it with a syntax that works also with the sun awk?
for example:

version=`$CXX -v < /dev/null 2>&1 | grep 'gcc version' | awk '{print $3}}'`

cheers Manuel

--
_______     __________
__  __ \______  /___(_) ker Manuel & SysMgr @ ISG.EE -  D-ITET
_  / / /  _ \  __/_  / ETH-Zurich tel: +41(0)1-6325302 fax:..1199
/ /_/ //  __/ /_ _  / eMail: Manuel Oetiker <moe...@ee...>
\____/ \___/\__/ /_/ www: http://people.ee.ethz.ch/~moetiker

Re: [Vxl-users] Re: Problems with VXL 1.0 beta installation

[<Pet...@es...>]

> how do you tell a library where to look for another library?

Some platforms (e.g. SGI) support this what is called "transitive linking",
but it normally requires an additional compiler switch.
Vxl assumes no transitive linking, which implies that the link line
for the executable must specify all libraries needed down the path.


> /home/hurlburt/code/vxl/oxl/vgui/impl/qt/libvgui_qt.so: undefined reference to
> `QPopupMenu::setFont(QFont const&)'
> /home/hurlburt/code/vxl/oxl/vgui/impl/qt/libvgui_qt.so: undefined reference to
> `QGLWidget::updateGL()   '

These should be in libqt.so (the Qt library, not from vxl).
Maybe a Qt version problem?


> /home/hurlburt/code/vxl/oxl/mvl/libmvl.so: undefined reference to
> `vnl_scatter_3x3<double>::compute_eigensystem()'
> /home/hurlburt/code/vxl/oxl/mvl/libmvl.so: undefined reference to
> `vnl_qr<double>::determinant() const'

These are not in libvnl.so but in libvnl-algo.so


	Peter.

Re: [Vxl-users] Re: Problems with VXL 1.0 beta installation

[Nick H. <nic...@ya...>]

--- Peter Vanroose <Pet...@es...> wrote:
> So if your compile reaches this #include <GL/xmesa.h> it means that GL/gl.h
> really is from Mesa.  Try checking which GL/gl.h is included (look in
> the file oxl/vgui/cmake.depends in your build tree).

There is no cmake.depends in oxl/vgui.  Good call, though -- turns out xmesa.h
and gl.h are buried deep, deep down in a path apparently not included normally
with gcc (hey, I didn't set up the paths).  I have no idea how it found gl.h
and not xmesa.h, which are in the SAME DIRECTORY, but whatever.  I manually
-I'd the correct path and it worked fine.  After I learned that trick I fixed
(hacked) a few more errors, and got it down only (I hope) to a few linking
problems.

Maybe I *should* know this, but how do you tell a library where to look for
another library?  This happened both in making oxl/vgui/:

c++ -rdynamic -g -O2 2d-example.o  -L/home/hurlburt/code/vxl/v3p/Qv
-L/home/hurlburt/code/vxl/oxl/vgui -L/home/hurlburt/code/vxl/oxl/vgui/impl/glut
-L/home/hurlburt/code/vxl/oxl/vgui/impl/qt -L/home/hurlburt/code/vxl/vxl/vnl
-L/home/hurlburt/code/vxl/vcl -L/home/hurlburt/code/vxl/vxl/vnl/algo
-L/home/hurlburt/code/vxl/v3p/netlib -L/home/hurlburt/code/vxl/vxl/vil
-L/home/hurlburt/code/vxl/vxl/vgl -L/home/hurlburt/code/vxl/vxl/vpl
-L/home/hurlburt/code/vxl/vxl/vbl -L/home/hurlburt/code/vxl/vxl/vul
-L/dist/jazznet-linux/lib -L/usr/X11R6/lib -lMesaGL -lMesaGLU -lpthread -lglut
-lXi -lXmu -lX11 -lXext -lQv -lvgui -lvgui_glut -lqt -lvgui_qt -lvnl -lvcl -lm
-lvnl_algo -lnetlib -lm -lnetlib -lm -lvnl -lvcl -lm -lvil -lvcl -lm -ljpeg
-lpng -lz -ltiff -lvgl -lvcl -lm -lvpl -lvcl -lm -lvbl -lvcl -lm -lvul -lvcl
-lm -lMesaGL -lMesaGLU -lpthread -lglut -lXi -lXmu -lX11 -lXext -lQv -lvgui
-lvgui_glut -lqt -lvgui_qt -lvnl -lvcl -lm -lvnl_algo -lnetlib -lm -lnetlib -lm
-lvnl -lvcl -lm -lvil -lvcl -lm -ljpeg -lpng -lz -ltiff -lvgl -lvcl -lm -lvpl
-lvcl -lm -lvbl -lvcl -lm -lvul -lvcl -lm
-Wl,-rpath,/home/hurlburt/code/vxl/v3p/Qv:/home/hurlburt/code/vxl/oxl/vgui:/home/hurlburt/code/vxl/oxl/vgui/impl/glut:/home/hurlburt/code/vxl/oxl/vgui/impl/qt:/home/hurlburt/code/vxl/vxl/vnl:/home/hurlburt/code/vxl/vcl:/home/hurlburt/code/vxl/vxl/vnl/algo:/home/hurlburt/code/vxl/v3p/netlib:/home/hurlburt/code/vxl/vxl/vil:/home/hurlburt/code/vxl/vxl/vgl:/home/hurlburt/code/vxl/vxl/vpl:/home/hurlburt/code/vxl/vxl/vbl:/home/hurlburt/code/vxl/vxl/vul:/dist/jazznet-linux/lib:/usr/X11R6/lib
 -o 2d-example
/home/hurlburt/code/vxl/oxl/vgui/impl/qt/libvgui_qt.so: undefined reference to
`QPopupMenu::setFont(QFont const&)'
/home/hurlburt/code/vxl/oxl/vgui/impl/qt/libvgui_qt.so: undefined reference to
`QGLWidget::updateGL()   '
[...]

... as well as in a program of my own, in which I use mvl, but libmvl.so can't
resolve its own calls to libvnl.so:

g++	-o testFM ../imageread/Image.o ../cornerdetect/HarrisParams.o
../cornerdetect/Harris.o testFM.o -L /home/hurlburt/code/vxl/oxl/mvl -L
/home/hurlburt/code/vxl/vxl/vnl -lmvl -lvnl
/home/hurlburt/code/vxl/oxl/mvl/libmvl.so: undefined reference to
`vnl_scatter_3x3<double>::compute_eigensystem()'
/home/hurlburt/code/vxl/oxl/mvl/libmvl.so: undefined reference to
`vnl_qr<double>::determinant() const'
[...]

In the first case I don't know what it's looking for, but looks like some
library.  I'm guessing the solution is pretty simple, I just can't find it. 
Thanks for your help, this is one of the more active and helpful listservs I've
seen!

Nick









__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

[Vxl-users] casting instead of rounding in templates

[Wheeler, F. (CRD) <wh...@cr...>]

(is vxl-maintainers a subset of vxl-users?)

In file "vil_interpolate.txx", function "template <class T, class U> bool vil_interpolate_bilinear",
the final line is:

  *out = U(pix00 * weight00 + pix10 * weight10 + pix01 * weight01 + pix11 * weight11);

*out is of type T.  This is a nice and general template, but if both T and U are integral types, then
the right hand side above gets promoted to double because the weight* vars are type double.  Then,
the cast to type U gets to an integer by truncation.  I think it would be much better to go to the
nearest integer.  This is causing problems for me and I'd like to fix it.  I have not yet come up
with a clean and easy way, so I'm looking for suggestions.  My favorite attempt so far is below.
Alas, it is really not sufficient.  For one, I don't think vcl_numeric_limits works.  For two, this
breaks when instantiated with T as an rgb<unsigned char> (not quite the right name, but you know what
I mean) type because both the if and else clauses must be compiled even if only one will be used for
a certain type, and there is no >= for the rgb<unsigned char>.  Any suggestions or pointers?

  T x = pix00 * weight00 + pix10 * weight10 +
        pix01 * weight01 + pix11 * weight11;

  // conversion done depending on the template types
  // when casting a floating type to an integral type, round to nearest int
  if (std::numeric_limits<U>::is_specialized &&
      std::numeric_limits<T>::is_specialized &&
      std::numeric_limits<U>::is_integer &&
      ! std::numeric_limits<T>::is_integer ) {
    // add (subtract) 0.5 if greater (less) than 0
    // so truncation will lead to the nearest integer
    *out = U( x + ( (x >= T(0.0)) ? T(0.5) : T(-0.5) ) );
  } else {
    *out = U(x);
  }

Thanks,
Fred Wheeler