jointtrack-devel — Mailing list for JointTrack developers

Re: [Jointtrack-devel] JointTrack Biplane Project Files

[Shang Mu <sm...@gm...>]

Bardiya,

Unfortunately, no.

As you can probably figure out from the project files, some of the includes
were set up by setting the $(JT_INCLUDE), $(JT_ICE_HOME) environment
variables in the OS. My guess is you have already built the single-plane
version. After that you should then be able to find the appropriate
directories and add them to the JT_INCLUDE and possibly other environment
variables to make things a little easier.

Shang


On Thu, Jun 1, 2017 at 1:30 PM, Bardiya Akhbari <bar...@gm...>
wrote:

> Hello all,
>
> Is there any coherent JointTrack Biplane cpp solution available for
> download? I cannot figure out all of the libraries and include files that
> they are needed for Biplane version. There isn't any CMakeList available
> also.
>
> Thank you so much, I really appreciate your help.
>
> Best Regards,
> Bardiya Akhbari, Ph.D. Student
> Biomedical Engineering, Brown University
> E-mail: bar...@br...
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jointtrack-devel mailing list
> Joi...@li...
> https://lists.sourceforge.net/lists/listinfo/jointtrack-devel
>
>

[Jointtrack-devel] JointTrack Biplane Project Files

[Bardiya A. <bar...@gm...>]

Hello all,

Is there any coherent JointTrack Biplane cpp solution available for
download? I cannot figure out all of the libraries and include files that
they are needed for Biplane version. There isn't any CMakeList available
also.

Thank you so much, I really appreciate your help.

Best Regards,
Bardiya Akhbari, Ph.D. Student
Biomedical Engineering, Brown University
E-mail: bar...@br...

[Jointtrack-devel] JointTrack 2.3.0

[Shang Mu <smu...@gm...>]

Download it here!
https://sourceforge.net/projects/jointtrack/files/JointTrack/2.3.0%20(API%2C%20experimental%20Python%20plugins)/


Changes:

====================
2.3.0 (API, experimental Python plugins)
--------------------

*User experience:*
* % Enhanced: *Faster iterations in the optimization loop if the model
display window(s) is minimized (because drawing to the screen and the
associated extra computation is skipped). This is most noticable if the
models are displayed in edge mode.
* %** Fixed:*    Image file is not read correctly by the alternative image
reader ReaderOpenCV (not used by default) if the image's horizontal
resolution is not a multiple of 4 (e.g. 1023x1023 instead of 1024x1024).
*            * This fix was previously released as a standalone hotfix to
ReaderOpenCV.exe.
 * %** Fixed:*    Transparent rendering stops working properly in the main
display window after it changes size to display a different sized image.
*            * The issue affected only the display and not the images
generated for the registration algorithm.
* %** Fixed:*    Rare Ctrl+Shift+Left/Right model manipulation crash, if it
is the first-ever model manipulation performed in the main display window
when there is a model selected but no prior mouse clicks in the main
display area.
* %** Adjusted:* Simulated Annealing and Simplex default parameters have
been adjusted. Especially, the default translational bound parameter has
been adjusted to be more appropriate for most cases where mm rather than
inch is used.
*            * Minor algorithm enhancement on the initial step size used
for the first iteration in Simulated Annealing.
* %** Adjusted:* Increased maximum allowed resolution of images in the
configuration files.
* % Enhanced: *The autosave .jts files are automatically deleted upon
normal exit by default. Autosave behaviors can be adjusted by modifying the
GUIwx.config file.
* % Enhanced: *Minor user experience enhancements in the registration
parameter configuration dialog.

*Features for advaced users:*
* % New:    *  Python plugin support. Python 2.7 (2.7.x only) required.
(Binaries for Python 2.6.x can be provided upon request).
 *            * A helper class PluginObjParamsI.py implementing the
JTPlugin::PluginObjParams interface is provided for easier creation of new
plugins.
* % New:    *  Ability to load an XML Model Specification file that
specifies all the STL models used (needed for some experimental algorithms).
*            * See SampleModelSpecFile.xml in the program's folder for an
example.
* % New:    *  Configurable GUI component startup delay before it tries to
communicate with JointTrack core and other necessary components.
 *            * Edit GUIwx.config if the GUI consistently fails to start
due to other components taking too long to start.

*Algorithms:*
 * % New:    *  Experimental algorithms, with certain components written in
Python (NumPy package required. Some functionality also uses SciPy).
 *            * These are disabled by default. To enable, move/copy
appropriate ".cfg" files from the "plugins\disabled" or
"plugins_python\disabled" directories into their parent folder, and edit
the GUIwx.config file.

[Jointtrack-devel] JointTrack 2.2.0 released

[Mu, S. <smu...@gm...>]

We are glad to announce that JointTrack 2.2.0 is available for download 
now:

https://sourceforge.net/projects/jointtrack/files/JointTrack/2.2.0%20(algorithm,%20feature)/


Changes:

====================
2.2.0 (algorithm, feature)
--------------------

*Algorithms:*
* %** New:  *    KneeTrack method (enhanced).
* % New:    *  Simplex opimizer + Mahfouz metric.
* % Enhance: * Mahfouz metric: User can now change the weights placed 
upon the intensity score and edge score, as well as choose whether to 
use smoothing on the edge images.
* * *To switch between different registration algorithms, comment out / 
uncomment relevant lines in GUIwx.config which is a plain text file. 
After you've decided which one is best for you, you can prevent 
irrelavant plugins from running by altering the file name extension for 
appropriate ".cfg" files in the "plugins" folder.

*Others:*
* % Added: *  Capability to save screenshots (in File menu).
* % Added: *  Capability to remove a model (in right mouse button 
context menu).
* % Added:*   Auto backup of kinematics on changing current frame.
* % Fixed:*   User is now asked for confirmation when overwriting an 
existing kinematics file.
* % Added:  * In keyboard control, added rotation about model's z-axis. 
Originally there was only z-rotation about the z of the x-ray system 
coordinates. Tweaked some other keyboard controls.
* % Tweak:*   Rearranged load/save kinematics buttons. User can opt to 
use an enhanced version of the old layout by renaming files in the "rc" 
directory.
* % Added: *  Capability to load external calibration parameters. (A 
user can now work in his own cooridnate system.)
* % Fixed: *  Improper display of x-ray images in original size after 
displaying images downsampled.

[Jointtrack-devel] JointTrack 2.1.3 released

[Mu, S. <smu...@gm...>]

We are glad to announce that JointTrack 2.1.3 is available for download now:

http://sourceforge.net/project/showfiles.php?group_id=167273&package_id=190235&release_id=638281

Changes:
====================
2.1.3 (feature)
--------------------
 % Added:   Enabled transparent rendering for display and registration. 
(JTRendererVTK, GUIwx)
 % Added:   Automatic down-sampling of big images for display purpose 
only. See "Images" section in Readme.txt for more info. (JTRendererVTK)
 % Added:   90-degree-rotation keyboard shortcuts in secondary view. See 
"Controls" section in Readme.txt for more info. (JTRendererVTK)
 % Fixed:   More numerical stability fixes in pose I/O and calculation - 
avoid compiler optimization error. (core)

[Jointtrack-devel] JointTrack 2.1.2 (hotfix)

[Mu, S. <smu...@gm...>]

JointTrack 2.1.2 fixed a potential deadlock introduced in the last version. Please download the new version if you installed v2.1.1.

http://sourceforge.net/project/showfiles.php?group_id=167273&package_id=190235&release_id=619056

Change log:
====================
2.1.2 (hotfix)
--------------------

 % Fixed:   The program may freeze when switching images / loading models. This bug was due to a potential deadlock introduced in last version's plotting code. (JTRendererVTK)

[Jointtrack-devel] JointTrack 2.1.1

[Shang M. <smu...@gm...>]

JointTrack 2.1.1 is released. Check out the plots!

http://sourceforge.net/project/showfiles.php?group_id=167273&package_id=190235&release_id=618040

Change log:
====================
2.1.1 (feature, bug fix)
--------------------

 % Added:   Side graphs/plots to facilitate registration. (JTRendererVTK, core)
 % Fixed:   Primary model display window: keyboard interaction crashes
the program if the user has never had mouse interaction in the window.
(JTRendererVTK)
 % Fixed:   Rotation center of keyboard z-rotation interaction was
supposed to be changed to model's origin in last version.
(JTRendererVTK)
 % Fixed:   (fixed again) mouse wheel may cause the model or view to
move dramatically. This bug was reintroduced in the last version due
to the bugged wxVTKRenderWindowInteractor. (JTRendererVTK)

[Jointtrack-devel] JointTrack 2.1.0 released

[Mu, S. <smu...@gm...>]

We are glad to announce the release of JointTrack 2.1.0:

http://sourceforge.net/project/showfiles.php?group_id=167273&package_id=190235&release_id=610096

Change log:
====================
2.1.0 (feature, API, bug fix)
--------------------

User experience:
 % Changed: New jts file format. See the last section for more 
information. (core)
 % Added:   Utility: jtsconvert.exe to convert kinematics (.jts) file 
between different pose representations or convert old format .jts file 
to the new format.
 % Changed: Instead of having to click exactly on the model to move it, 
user interaction now acts on the current model. Be careful though: you 
may accidently rotate a model when you are just trying to bring the 
window to foreground. (JTRendererVTK)
 % Changed: All rotations are now about the model's origin(not center). 
(JTRendererVTK)
 % Changed: Changed how the program calculates rotation for left mouse 
button interaction (without pressing ctrl key). (JTRendererVTK)
 % Changed: Some default values (rotation search bounds and termination 
tolerance) in the 'config registration' dialog. (OptiSimAnneal_Ice)
 % Added:   "Optimize whole sequence" button. (GUIwx)
 % Added:   "Save all kinematics" and "Load all kinematics" buttons. 
(core, GUIwx)
 % Added:   User now gets a warning if the jts file being loaded 
contains more data than needed. (core)
 % Fixed:   Unchecking checkbox "image is black (bones) on white 
(background)" did not take immediate effect if the user has already run 
the optimization once with that checkbox checked. The bug remained in 
effect until the user switched to a different image. (CostFuncSFMahfouz)
 % Fixed:   During optimization the program may crash or hang if the 
user tries to interact with the model display windows. (JTRendererVTK)
 % Fixed:   "Reset" button for the canny edge parameters no longer 
causes error. (GUIwx)
 % Fixed:   No more problems at image loading when the user has invalid 
intensity/canny parameters in the UI controls. (GUIwx)
 % Fixed:   Pressing Q or E in the secondary model display window caused 
it to close. (JTRendererVTK)
 % Fixed:   User can no longer close the model display windows. User can 
no longer resize the main model display window. (JTRendererVTK)
 % Fixed:   Model may become half clipped in the secondary model display 
window when user manipulates the model using keyboard. (JTRendererVTK)
 % Fixed:   The secondary model display window initially may show up 
behind the main model display window. This no longer happens unless the 
main model display window is very big. (JTRendererVTK)
 % Fixed:   A singularity value (in the sense of Euler angles) may cause 
JointTrack to generate jts files with invalid values. (This was due to 
compiler optimization error, so it wouldn't happen in debug build.) (core)
 % Removed: Removed non-functioning buttons. (GUIwx)

Major API changes:
 % Added one inheritance level to plugin hierarchy so that 
non-image-based registration routine can be added later.
 % Data order in Pose.rotation vector is now required to conform to the 
actual Euler sequence (if Euler angle is being used).

Kinematics(.jts) file format change note:
 JointTrack still can load old format kinematics files. In addition to 
saving kinematics to new format files in JointTrack, user can also use 
command-line tool jtsconvert.exe to convert old format files to the new 
format.
 In old jts files, the six columns were "x_tran, y_tran, z_tran, x_rot, 
y_rot, z_rot". In order to represent symmetric Euler sequences (for 
example, 3-1-3), column orders have been changed to conform to the 
actual Euler sequence. New format jts files have column headers.

[Jointtrack-devel] Notice - BlackOnWhite bug

[Shang M. <smu...@gm...>]

Dear JointTrack users,

A bug that could affect the accuracy of the registration result was
discovered in JointTrack.

Symptom:
The checkbox "image is black (bones) on white (background)" does not
always immediately take effect. The bug only occurs when your image is
actually white on black, and you have already run the optimization
once with that checkbox checked.

Workaround:
If you have multiple images loaded, switching to a different image and
then switching back will force the checkbox to take effect.

Fix:
The fix will be included in the next release. The bug is in the
"CostFuncSFMahfouz" plugin.


Shang

[Jointtrack-devel] JointTrack 2.0.2 is released

[Shang M. <smu...@gm...>]

http://sourceforge.net/project/showfiles.php?group_id=167273&package_id=190235&release_id=567980

If you have older version installed, please delete the "plugins"
folder before installing the new version. This is because the port
number for each plugin has been re-assigned - deleting all the old
config files ensures no conflicts would happen. Additionally,
FilterCannyEdge.exe/cfg has been renamed to
FilterCannyEdgeOpenCV.exe/cfg.

The decision to re-assign the port numbers is trying to make it a
little bit easier to find an unused port when a new plugin is added.
The port numbers now are assigned in reference to the particular
plugin's "Category" as defined in JointTrack.h.



Change log:

2.0.2 (bugfix/maintenance)
--------------------
In plugins:
All:
 % Fixed large image causing Ice::MemoryLimitException.
JTRendererVTK:
 % Fixed model disappearing when using "copy previous/next" or "Load
kinematics".
 % Fixed bug: application could not be shut down normally if the vtk
window is not yet
   created(User closed JointTrack before loading any images).
GUIwx:
 % Fixed invalid canny edge detector causing uncaught exception.
 % Fixed the range of low_thres and high_thres for canny edge detector.
 % Changed the names of the load/save buttons (hopefully making them
more user-friendly).
OptiSimAnneal_Ice:
 % Fixed default initial temperature; increased textbox display length
for search range parameter.
MyMahfouzRegistration:
 % The displayed iteration number is now 'real'(reset for each optimzation).
ReaderTIFFVTK:
 % Fixed several internal/API bugs.
FilterCannyEdgeOpenCV:
 % Renamed the EXE and config file of FilterCannyEdgeOpenCV to
FilterCannyEdgeOpenCV.exe/cfg
   instead of the old FilterCannyEdge.exe/cfg.

Re: [Jointtrack-devel] JTRendererVTK does not shut down?

[Shang M. <smu...@gm...>]

Bryan,

Was there any problem with the application when that happened?
For example, if one render window crashed when JointTrack was running,
the core may be unable to shut JTRendererVTK down thereafter.

Did you close the GUI first or the console windows first? But I do not
think that is a big issue.

By the way, is the secondary window still frozen on your computer?

Shang


On 12/4/07, Bryan P. Conrad <co...@or...> wrote:
>
>
>
>
> When I close JointTrack, sometimes JTRendererVTK does not shut down I have
> to kill it in the task manager.  It does not exhibit this behavior every
> time and I am not sure what steps are necessary to reproduce the issue.  Has
> anyone else noticed this?
>
>
>
> ____________________________
>
> Bryan P. Conrad, M.Eng.
>
> Biomedical Engineer
>
>
>
> Department of Orthopaedics and Rehabilitation
>
> University of Florida
>
> PO Box 112727
>
> Gainesville, FL 32611
>
> Phone: 352.273.7412
>
> Fax: 352.273.7407
>
>
>
>
>
> This communication may contain information that is legally exempt from
> disclosure. If you are not the intended recipient, please note that
>
> any dissemination, distribution or copying of this communication is strictly
> prohibited.  Anyone who receives this message in error should
>
> notify the sender immediately by telephone, or by return email and delete
> the message from their computer.
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Jointtrack-devel mailing list
> Joi...@li...
> https://lists.sourceforge.net/lists/listinfo/jointtrack-devel
>
>

[Jointtrack-devel] JTRendererVTK does not shut down?

[Bryan P. C. <co...@or...>]

When I close JointTrack, sometimes JTRendererVTK does not shut down I
have to kill it in the task manager.  It does not exhibit this behavior
every time and I am not sure what steps are necessary to reproduce the
issue.  Has anyone else noticed this?

=20

____________________________

Bryan P. Conrad, M.Eng.

Biomedical Engineer

=20

Department of Orthopaedics and Rehabilitation

University of Florida

PO Box 112727

Gainesville, FL 32611

Phone: 352.273.7412

Fax: 352.273.7407

=20

=20

This communication may contain information that is legally exempt from
disclosure. If you are not the intended recipient, please note that

any dissemination, distribution or copying of this communication is
strictly prohibited.  Anyone who receives this message in error should

notify the sender immediately by telephone, or by return email and
delete the message from their computer.

=20

Re: [Jointtrack-devel] SVN directory structure re-organized

[Shang M. <smu...@gm...>]

Everything works fine. Most of the reference/output path changes
happen on the project file level. On the source file level only two
header files in project GUIwx need modification to the "#include"
lines.

Shang


On 11/30/07, Shang Mu <smu...@gm...> wrote:
> all,
>
> I have reorganized the directory tree.
> If you need to get the old structured repository, please use revision
> 81 or tags/v2.0_stable.
>
> I'm in the middle of correcting the reference path for the VC project
> files and verifying nothing is broken. I'll let you know once I
> verified everything works OK.
>
> Shang
>

[Jointtrack-devel] SVN directory structure re-organized

[Shang M. <smu...@gm...>]

all,

I have reorganized the directory tree.
If you need to get the old structured repository, please use revision
81 or tags/v2.0_stable.

I'm in the middle of correcting the reference path for the VC project
files and verifying nothing is broken. I'll let you know once I
verified everything works OK.

Shang

Re: [Jointtrack-devel] [Jointtrack-users] JointTrack 2.0 is released

[Bryan P. C. <co...@or...>]

I have only played with keyboard controls for about two minutes and I am
already in love with the +/- function to change scales.  That is an
AWESOME idea, good job!

-bryan

-----Original Message-----
From: joi...@li...
[mailto:joi...@li...] On Behalf Of
Shang Mu
Sent: Thursday, November 29, 2007 6:28 PM
To: joi...@li...;
joi...@li...
Subject: [Jointtrack-users] JointTrack 2.0 is released

Other than minor GUI tweaks, the only major change is that you can use
+/- keys to increase/decrease the step size for keyboard controls.

Link:

http://sourceforge.net/project/showfiles.php?group_id=3D167273&package_id=
=3D
190235&release_id=3D558002


Shang

------------------------------------------------------------------------
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jointtrack-users mailing list
Joi...@li...
https://lists.sourceforge.net/lists/listinfo/jointtrack-users

[Jointtrack-devel] JointTrack 2.0 is released

[Shang M. <smu...@gm...>]

Other than minor GUI tweaks, the only major change is that you can use
+/- keys to increase/decrease the step size for keyboard controls.

Link:

http://sourceforge.net/project/showfiles.php?group_id=167273&package_id=190235&release_id=558002


Shang

Re: [Jointtrack-devel] First cross-platform patch for the JTMVCModel directory.

[Shang M. <smu...@gm...>]

I applied the patch to the svn, except the #include issue.
The <> include directives are generated from .ice files by the
slice2cpp program of Ice. I do not quite understand their choice, but
what i did is I included "." in the include searching path.

Ice even discourages use of "" includes in .ice files. From Ice documentation:
'''
Note that you should avoid #include with double quotes:
#include "Clock.ice" // Not recommended!
While double quotes will work, the directory in which the preprocessor tries to
locate the file can vary depending on the operating system, so the included file
may not always be found where you expect it. Instead, use angle brackets (<>);
you can control which directories are search for the file with the -I
option of the
Slice compiler (see page 169).
'''
And there is a section talking about the generation of include
directives in C++ focusing on the path of the header file in the
generated files, for example #include <include/a.h>.

If you feel those are nonsense, we probably should bring those issues
up on Ice's forum.

Shang


On 11/12/07, Jonathan Merritt <me...@un...> wrote:
> Hi Guys,
>
> I have submitted a first patch to the tracker (Request ID 1830252).
> I'm not sure how you will apply the patch under Windows, but the
> normal UNIX patch command is:
>     patch -p0 < patch
> This should be run when the patch file is in the root directory.  You
> can do a dry-run using:
>     patch --dry-run -p0 < patch
> (Also note, it's safest NOT to do this on a working copy that has
> local changes.  The safest way is to check out a fresh working copy,
> apply the patch, review it, and then commit.  You can then merge those
> committed changes into your own working copy with an svn up.  Please
> disregard if you're experienced with patching.)
>
> Can you please check that this patch doesn't break anything for the
> Windows build, and then commit it?  I will start working on the
> Windows-specific filesystem stuff in the JTMVCModel directory next.
>
> This patch addresses the following three problems in the JTMVCModel
> directory:
>
> 1. Use of "" vs <> in #include directives.  For project-specific
> headers, the use of double-quotation marks "" rather than angled
> brackets <> is more typical.  The use of angled brackets for project-
> specific headers causes problems for g++.
>
> 2. Passing temporary objects by non-const reference.  Consider below:
>
> The following C++ program is illegal (according to the actual
> standard).  The main() function attempts to pass a temporary
> std::string object by non-const reference.
> === START CODE ===
> #include <iostream>
> void printString(std::string &myString) {
> 	std::cout << myString << std::endl;
> }
> std::string makeString() {
> 	return std::string("Hello World!");
> }
> int main (int argc, char * const argv[]) {
> 	printString(makeString());
> }
> === END CODE ===
>
> The program can be made legal either by explicitly instantiating the
> std::string object (making it appear on the stack) or by using a const-
> reference.  The use of a const reference is illustrated below:
> === START CODE ===
> #include <iostream>
> void printString(const std::string &myString) {
> 	std::cout << myString << std::endl;
> }
> std::string makeString() {
> 	return std::string("Hello World!");
> }
> int main (int argc, char * const argv[]) {
> 	printString(makeString());
> 	// OR, put the string on the stack:
> 	//  std::string s = makeString();
> 	//  printString(s);
> }
> === END CODE ===
>
> I have changed the passing of JTHint in CObservableObserver::Notify()
> to const.  If this will not work (i.e. if JTHint is actually
> modified), then the code can be fixed by following this pattern for
> JTHint passing:
> Change:
>     Notify( HintGen(JT_Activity_ALL), this, caller);
> To:
>     JTHint hint = HintGen(JT_Activity_ALL);
>     Notify(hint, this, caller);
> (Or something similar that actually places a JTHint on the stack.)
>
> C++ is a complicated language, and Microsoft do NOT make things easier
> by allowing non-standard behavior! :-(
>
> 3. The "typename" keyword is required in a couple of places.  I don't
> fully understand this one myself, but the g++ errors indicated the fix.
>
> Jonathan Merritt.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Jointtrack-devel mailing list
> Joi...@li...
> https://lists.sourceforge.net/lists/listinfo/jointtrack-devel
>

[Jointtrack-devel] First cross-platform patch for the JTMVCModel directory.

[Jonathan M. <me...@un...>]

Hi Guys,

I have submitted a first patch to the tracker (Request ID 1830252).   
I'm not sure how you will apply the patch under Windows, but the  
normal UNIX patch command is:
    patch -p0 < patch
This should be run when the patch file is in the root directory.  You  
can do a dry-run using:
    patch --dry-run -p0 < patch
(Also note, it's safest NOT to do this on a working copy that has  
local changes.  The safest way is to check out a fresh working copy,  
apply the patch, review it, and then commit.  You can then merge those  
committed changes into your own working copy with an svn up.  Please  
disregard if you're experienced with patching.)

Can you please check that this patch doesn't break anything for the  
Windows build, and then commit it?  I will start working on the  
Windows-specific filesystem stuff in the JTMVCModel directory next.

This patch addresses the following three problems in the JTMVCModel  
directory:

1. Use of "" vs <> in #include directives.  For project-specific  
headers, the use of double-quotation marks "" rather than angled  
brackets <> is more typical.  The use of angled brackets for project- 
specific headers causes problems for g++.

2. Passing temporary objects by non-const reference.  Consider below:

The following C++ program is illegal (according to the actual  
standard).  The main() function attempts to pass a temporary  
std::string object by non-const reference.
=== START CODE ===
#include <iostream>
void printString(std::string &myString) {
	std::cout << myString << std::endl;
}
std::string makeString() {
	return std::string("Hello World!");
}
int main (int argc, char * const argv[]) {
	printString(makeString());
}
=== END CODE ===

The program can be made legal either by explicitly instantiating the  
std::string object (making it appear on the stack) or by using a const- 
reference.  The use of a const reference is illustrated below:
=== START CODE ===
#include <iostream>
void printString(const std::string &myString) {
	std::cout << myString << std::endl;
}
std::string makeString() {
	return std::string("Hello World!");
}
int main (int argc, char * const argv[]) {
	printString(makeString());
	// OR, put the string on the stack:
	//  std::string s = makeString();
	//  printString(s);
}
=== END CODE ===

I have changed the passing of JTHint in CObservableObserver::Notify()  
to const.  If this will not work (i.e. if JTHint is actually  
modified), then the code can be fixed by following this pattern for  
JTHint passing:
Change:
    Notify( HintGen(JT_Activity_ALL), this, caller);
To:
    JTHint hint = HintGen(JT_Activity_ALL);
    Notify(hint, this, caller);
(Or something similar that actually places a JTHint on the stack.)

C++ is a complicated language, and Microsoft do NOT make things easier  
by allowing non-standard behavior! :-(

3. The "typename" keyword is required in a couple of places.  I don't  
fully understand this one myself, but the g++ errors indicated the fix.

Jonathan Merritt.

[Jointtrack-devel] First cross-platform patch for the JTMVCModel directory.

[Jonathan M. <me...@un...>]

Hi Guys,

I have submitted a first patch to the tracker (Request ID 1830252).   
I'm not sure how you will apply the patch under Windows, but the  
normal UNIX patch command is:
    patch -p0 < patch
This should be run when the patch file is in the root directory.  You  
can do a dry-run using:
    patch --dry-run -p0 < patch
(Also note, it's safest NOT to do this on a working copy that has  
local changes.  The safest way is to check out a fresh working copy,  
apply the patch, review it, and then commit.  You can then merge those  
committed changes into your own working copy with an svn up.  Please  
disregard if you're experienced with patching.)

Can you please check that this patch doesn't break anything for the  
Windows build, and then commit it?  I will start working on the  
Windows-specific filesystem stuff in the JTMVCModel directory next.

This patch addresses the following three problems in the JTMVCModel  
directory:

1. Use of "" vs <> in #include directives.  For project-specific  
headers, the use of double-quotation marks "" rather than angled  
brackets <> is more typical.  The use of angled brackets for project- 
specific headers causes problems for g++.

2. Passing temporary objects by non-const reference.  Consider below:

The following C++ program is illegal (according to the actual  
standard).  The main() function attempts to pass a temporary  
std::string object by non-const reference.
=== START CODE ===
#include <iostream>
void printString(std::string &myString) {
	std::cout << myString << std::endl;
}
std::string makeString() {
	return std::string("Hello World!");
}
int main (int argc, char * const argv[]) {
	printString(makeString());
}
=== END CODE ===

The program can be made legal either by explicitly instantiating the  
std::string object (making it appear on the stack) or by using a const- 
reference.  The use of a const reference is illustrated below:
=== START CODE ===
#include <iostream>
void printString(const std::string &myString) {
	std::cout << myString << std::endl;
}
std::string makeString() {
	return std::string("Hello World!");
}
int main (int argc, char * const argv[]) {
	printString(makeString());
	// OR, put the string on the stack:
	//  std::string s = makeString();
	//  printString(s);
}
=== END CODE ===

I have changed the passing of JTHint in CObservableObserver::Notify()  
to const.  If this will not work (i.e. if JTHint is actually  
modified), then the code can be fixed by following this pattern for  
JTHint passing:
Change:
    Notify( HintGen(JT_Activity_ALL), this, caller);
To:
    JTHint hint = HintGen(JT_Activity_ALL);
    Notify(hint, this, caller);
(Or something similar that actually places a JTHint on the stack.)

C++ is a complicated language, and Microsoft do NOT make things easier  
by allowing non-standard behavior! :-(

3. The "typename" keyword is required in a couple of places.  I don't  
fully understand this one myself, but the g++ errors indicated the fix.

Jonathan Merritt.

Re: [Jointtrack-devel] Mac OS X Port

[Shang M. <smu...@gm...>]

> I mean to add both the headers and libraries of each of the
> dependencies.  The idea is to have a working copy of the dependencies
> which are regarded as "current" for the project.  For example, here's
> the Blender lib directory from SVN:
> 
> http://projects.blender.org/plugins/scmsvn/viewcvs.php/trunk/lib/?root=bf-blender
> It has compiled versions of each dependency for each platform - just
> headers and libs.
>
> I guess this may not be important until there are more developers, but
> certainly on the Mac platform, getting all of the dependencies
> compiled is a huge pain.  Then people can use different settings when
> they're compiling, which can lead to some bizarre problems.

I should check the policy of sourceforge. If they have no problem with 
binaries, I'll be glad to do that. I'm also planning to re-organize the 
directory tree. Maybe we'll do them all together.


> I'll get back to you about that sometime.  I'll see if I can find out
> how other cross-platform apps are using VTK.  I've been wondering
> whether embedding the VTK window inside a WX window might solve some
> of the message-passing issues.  I haven't had the chance to look at
> any of it in detail yet though.
>

That's also what I've been thinking about recently. I actually thought about 
this for quite a while before replying your previous email. But I think I 
was led to the wrong way by the wrong idea of not being able to use 
vtkRenderWindowInteractor any more. We'll see.

Re: [Jointtrack-devel] Mac OS X Port

[Jonathan M. <me...@un...>]

Hi Shang,

On 10/11/2007, at 3:06 PM, Shang Mu wrote:

> Welcome to the project! You might be senior than any of us in the  
> aspect of software engineering. Feel free to give advices. See my  
> replies to your individual questions below:

LOL!  I doubt it. :-)  I've probably just been tinkering for longer.

> >     - I plan to set up an XCode project to handle the build.  (XCode
> > is the free-as-in-beer IDE that Apple provide as part of OS X.)  Is
> > this OK?
>
> That's OK. Apparently you know Mac much better than us. If that's  
> the proper/most usual way to do it under OS X, just do it. That  
> said, maybe CMake or other cross-platform tool would serve the job  
> better.

The advantage of CMake is that it could be used for Linux builds too  
(and Windoze ;-).  I'm interested in XCode for its ability to act as a  
well-integrated IDE (editing, debugging, profiling, etc.).  However,  
I'll look into CMake since there has apparently been some work done to  
allow it actually to generate XCode projects.

> >     - What is your policy on including OS X headers and libraries  
> for
> > the dependencies (ICE, Boost, VTK, OpenCV) in the JointTrack SVN
> > repository?  Quite a few other projects (e.g. Blender and OsiriX) do
> > this to make things easier on developers.
>
> Not sure what you mean. Add header to the dependencies? Or add  
> headers to JointTrack source files so that those dependencies work  
> fine?

I mean to add both the headers and libraries of each of the  
dependencies.  The idea is to have a working copy of the dependencies  
which are regarded as "current" for the project.  For example, here's  
the Blender lib directory from SVN:
     http://projects.blender.org/plugins/scmsvn/viewcvs.php/trunk/lib/?root=bf-blender
It has compiled versions of each dependency for each platform - just  
headers and libs.

I guess this may not be important until there are more developers, but  
certainly on the Mac platform, getting all of the dependencies  
compiled is a huge pain.  Then people can use different settings when  
they're compiling, which can lead to some bizarre problems.

> >     - Are there any major problems you can foresee with the porting
> > task?
>
> I'm not sure if the following is a problem:
> VTK gave me much more pain than any other library. One particular  
> problem is "wglMakeCurrent() failed" error (which is not entirely  
> vtk's fault). On Windows, an openGL context can only be current to a  
> single thread(i don't know if it's the same case on OS X or linux).  
> vtkRenderWindowInteractor creates a thread by itself. Apparently in  
> JointTrack we need access from other threads for many other tasks  
> like change the display mode or switch to another image. In vtk  
> there seems to be no easy way to let the interactor thread release  
> its OpenGL context, so wglMakeCurrent() fails every time some  
> operation is invoked in another thread. But it does not make much  
> sense to derive a class from vtkRenderWindowInteractor because it  
> actually has platform-specific subclasses called  
> vtkWin32RenderWindowInteractor, etc. To get around the problem, I  
> added vtkRenderWindow::IgnoreMakeCurrentOn/Off(), but inter-thread  
> function call is needed when a redraw of the window is needed: I  
> used SendMessage(WM_PAINT,...). To avoid platform specific call like  
> SendMessage(), the only way I can think of is to indiviually derive  
> classes from vtkWin32RenderWindowInteractor,  
> vtkXRenderWindowInteractor ... in which case things like "#ifdef  
> _WIN32" is still needed.

I think the JTRendererVTK stuff will need a lot of work.  I noticed  
it's probably the most heavily tied to the Windows platform,  
especially as you mention, with all of those Windows messages that are  
being sent.

I'll get back to you about that sometime.  I'll see if I can find out  
how other cross-platform apps are using VTK.  I've been wondering  
whether embedding the VTK window inside a WX window might solve some  
of the message-passing issues.  I haven't had the chance to look at  
any of it in detail yet though.

> Because you joined, we officially begin to use the mailing list at  
> this moment!

I'll upload some patches to the SourceForge Tracker sometime this week  
(hopefully I'll have time).  I have the core bits in the JTMVCModel  
directory compiling nicely, but I've commented out all of the  
filesystem stuff for now (I won't submit commented-out parts in the  
patches!).

Unfortunately, I don't have (easy) access to the MS development tools,  
so probably the best thing is if you guys can check that my patches  
don't break the Windows build before committing them (or eventually I  
can commit them and you can just revert them with a message if they  
cause problems).

Thanks,

Jonathan Merritt.

Re: [Jointtrack-devel] Possibly incomplete SVN repository?

[Shang M. <smu...@gm...>]

They are obsolete. The new files are named ExternalCalibInfo.h/cpp.
However, the new files do not have many methods implemented as well - for a 
single-plane setup, we haven't needed that class.

Shang


----- Original Message ----- 
From: "Jonathan Merritt" <me...@un...>
To: <joi...@li...>
Cc: <yam...@us...>; <ms...@us...>
Sent: Friday, November 09, 2007 1:09 AM
Subject: Possibly incomplete SVN repository?


> Hello,
>
> I've found one file (so far... there may be more?) in the SVN  repository 
> which doesn't seem to be complete:
> 
> http://jointtrack.svn.sourceforge.net/viewvc/jointtrack/trunk/JTMVCModel/ExternalCalibrationData.cpp?view=markup
>
> None of the methods from ExternalCalibrationData.h are implemented. 
> Could this file have been  cut-off during an SVN import?  Or is it 
> perhaps obsolete?
>
> Thanks,
>
> Jonathan Merritt.
> 

Re: [Jointtrack-devel] Mac OS X Port

[Shang M. <smu...@gm...>]

Jonathan,

Welcome to the project! You might be senior than any of us in the aspect =
of software engineering. Feel free to give advices. See my replies to =
your individual questions below:


----- Original Message -----=20
From: "Jonathan Merritt" <me...@un...>
To: <joi...@li...>
Cc: <ms...@us...>; <yam...@us...>
Sent: Thursday, November 08, 2007 8:36 PM
Subject: Mac OS X Port


> Hi Guys,
>=20
> I'm a post-doc in Marcus Pandy's lab (University of Melbourne), and =20
> I'm interested in creating an OS X port of JointTrack.  (I don't use =20
> JointTrack directly, but others in our lab may do soon.)  Initially, I =
=20
> am targeting an Intel-only build for OS X 10.5 (Leopard).
>=20
> The dependency situation under OS X is as follows:
>     - WxWidgets.  Version 2.8 is actually included with OS X!
>     - ICE.  Zero C provide OS X Intel headers and libraries.
>     - Boost.  Can compile if necessary (haven't checked if your usage  =

> is headers-only).

Right now only the boost string algorithm library is used - so header =
only. We probably will also use Boost serialization library for =
saving/loading project files.

>     - VTK.  Compiles.  (Should work - used by other OS X projects =20
> like OsiriX.)
>     - OpenCV.  OS X instructions here: =
http://opencvlibrary.sourceforge.net/Mac_OS_X_OpenCV_Port
>=20
> I have noticed that your code uses some Microsoft-specific functions =20
> (such as _access() to determine whether a file exists and can be =20
> opened).  In order to get an OS X build working, I will need to swap =20
> these out for cross-platform equivalents.
>=20
> I guess at this stage, I have a few questions:
>     - Is anyone currently working on OS X or Linux ports?  (i.e. am I  =

> duplicating any efforts?)

No.

>     - I plan to set up an XCode project to handle the build.  (XCode =20
> is the free-as-in-beer IDE that Apple provide as part of OS X.)  Is =20
> this OK?

That's OK. Apparently you know Mac much better than us. If that's the =
proper/most usual way to do it under OS X, just do it. That said, maybe =
CMake or other cross-platform tool would serve the job better.

>     - What is your policy on including OS X headers and libraries for  =

> the dependencies (ICE, Boost, VTK, OpenCV) in the JointTrack SVN =20
> repository?  Quite a few other projects (e.g. Blender and OsiriX) do =20
> this to make things easier on developers.

Not sure what you mean. Add header to the dependencies? Or add headers =
to JointTrack source files so that those dependencies work fine?

>     - Are there any major problems you can foresee with the porting =20
> task?

I'm not sure if the following is a problem:
VTK gave me much more pain than any other library. One particular =
problem is "wglMakeCurrent() failed" error (which is not entirely vtk's =
fault). On Windows, an openGL context can only be current to a single =
thread(i don't know if it's the same case on OS X or linux). =
vtkRenderWindowInteractor creates a thread by itself. Apparently in =
JointTrack we need access from other threads for many other tasks like =
change the display mode or switch to another image. In vtk there seems =
to be no easy way to let the interactor thread release its OpenGL =
context, so wglMakeCurrent() fails every time some operation is invoked =
in another thread. But it does not make much sense to derive a class =
from vtkRenderWindowInteractor because it actually has platform-specific =
subclasses called vtkWin32RenderWindowInteractor, etc. To get around the =
problem, I added vtkRenderWindow::IgnoreMakeCurrentOn/Off(), but =
inter-thread function call is needed when a redraw of the window is =
needed: I used SendMessage(WM_PAINT,...). To avoid platform specific =
call like SendMessage(), the only way I can think of is to indiviually =
derive classes from vtkWin32RenderWindowInteractor, =
vtkXRenderWindowInteractor ... in which case things like "#ifdef _WIN32" =
is still needed.

>=20
> Thanks,
>=20
> Jonathan Merritt.
>=20
> PS - I CC'd this to the project admins since I'm not sure whether =20
> you're using your SourceForge devel list.

Because you joined, we officially begin to use the mailing list at this =
moment!


Shang

[Jointtrack-devel] Possibly incomplete SVN repository?

[Jonathan M. <me...@un...>]

Hello,

I've found one file (so far... there may be more?) in the SVN  
repository which doesn't seem to be complete:
     http://jointtrack.svn.sourceforge.net/viewvc/jointtrack/trunk/JTMVCModel/ExternalCalibrationData.cpp?view=markup

None of the methods from ExternalCalibrationData.h are implemented.   
Could this file have been  cut-off during an SVN import?  Or is it  
perhaps obsolete?

Thanks,

Jonathan Merritt.

[Jointtrack-devel] Mac OS X Port

[Jonathan M. <me...@un...>]

Hi Guys,

I'm a post-doc in Marcus Pandy's lab (University of Melbourne), and  
I'm interested in creating an OS X port of JointTrack.  (I don't use  
JointTrack directly, but others in our lab may do soon.)  Initially, I  
am targeting an Intel-only build for OS X 10.5 (Leopard).

The dependency situation under OS X is as follows:
     - WxWidgets.  Version 2.8 is actually included with OS X!
     - ICE.  Zero C provide OS X Intel headers and libraries.
     - Boost.  Can compile if necessary (haven't checked if your usage  
is headers-only).
     - VTK.  Compiles.  (Should work - used by other OS X projects  
like OsiriX.)
     - OpenCV.  OS X instructions here: http://opencvlibrary.sourceforge.net/Mac_OS_X_OpenCV_Port

I have noticed that your code uses some Microsoft-specific functions  
(such as _access() to determine whether a file exists and can be  
opened).  In order to get an OS X build working, I will need to swap  
these out for cross-platform equivalents.

I guess at this stage, I have a few questions:
     - Is anyone currently working on OS X or Linux ports?  (i.e. am I  
duplicating any efforts?)
     - I plan to set up an XCode project to handle the build.  (XCode  
is the free-as-in-beer IDE that Apple provide as part of OS X.)  Is  
this OK?
     - What is your policy on including OS X headers and libraries for  
the dependencies (ICE, Boost, VTK, OpenCV) in the JointTrack SVN  
repository?  Quite a few other projects (e.g. Blender and OsiriX) do  
this to make things easier on developers.
     - Are there any major problems you can foresee with the porting  
task?

Thanks,

Jonathan Merritt.

PS - I CC'd this to the project admins since I'm not sure whether  
you're using your SourceForge devel list.