Hello,

I'm trying to build Plus to communicate with StealthLink (I'm using VS2010 on an 64 bit Windows 10 machine). Without Stealthlink, Plus is able to build fully, with no failed builds or errors. However, upon including the Stealthlink flag, the build fails (specifically PlusLib and PlusApp) and build errors such as the following come up.

I've tried using only static libraries given the boost libraries asked for in the final error message posted below are static, but to no avail, as well as ensuring the library directories and libraries themselves are linked to.

I'm unsure how to proceed at this point and would appreciate any help.

Thanks,

Purav

12>msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: virtual __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::~basic_streambuf<char,struct std::char_traits<char> >(void)" (??1?$basic_streambuf@DU?$char_traits@D@std@@@std@@UEAA@XZ) already defined in StealthLink_static.lib(SubscriptionUpdateHandler.obj) [C:\D\PlusB-bin\PlusApp-bin\DiagnosticTools\DiagDataCollection.vcxproj]
12>msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl std::basic_ostream<char,struct std::char_traits<char> >::flush(void)" (?flush@?$basic_ostream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@XZ) already defined in StealthLink_static.lib(SubscriptionUpdateHandler.obj) [C:\D\PlusB-bin\PlusApp-bin\DiagnosticTools\DiagDataCollection.vcxproj]
12>msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: void __cdecl std::basic_ostream<char,struct std::char_traits<char> >::_Osfx(void)" (?_Osfx@?$basic_ostream@DU?$char_traits@D@std@@@std@@QEAAXXZ) already defined in StealthLink_static.lib(SubscriptionUpdateHandler.obj) [C:\D\PlusB-bin\PlusApp-bin\DiagnosticTools\DiagDataCollection.vcxproj]
12>msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: void __cdecl std::basic_ios<char,struct std::char_traits<char> >::setstate(int,bool)" (?setstate@?$basic_ios@DU?$char_traits@D@std@@@std@@QEAAXH_N@Z) already defined in StealthLink_static.lib(SubscriptionUpdateHandler.obj) [C:\D\PlusB-bin\PlusApp-bin\DiagnosticTools\DiagDataCollection.vcxproj]
12>msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: __int64 __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::sputn(char const *,__int64)" (?sputn@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QEAA_JPEBD_J@Z) already defined in StealthLink_static.lib(SubscriptionUpdateHandler.obj) [C:\D\PlusB-bin\PlusApp-bin\DiagnosticTools\DiagDataCollection.vcxproj]
12>msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: int __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::sputc(char)" (?sputc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QEAAHD@Z) already defined in StealthLink_static.lib(SubscriptionUpdateHandler.obj) [C:\D\PlusB-bin\PlusApp-bin\DiagnosticTools\DiagDataCollection.vcxproj]
12>LINK : fatal error LNK1104: cannot open file 'libboost_system-vc100-mt-s-1_46_1.lib' [C:\D\PlusB-bin\PlusApp-bin\DiagnosticTools\DiagDataCollection.vcxproj]

Some parameter names in the config files are still not informative enough. E.g.
VolumeReconstruction/OutputSpacing -- this could be OutputSpacingPixelsPerMm.
VolumeReconstruction/ClipRectangleOrigin ans Size -- this is clear for people who are familiar with VTK: http://www.vtk.org/Wiki/VTK/Tutorials/Extents , but not clear to other people. Maybe if units were added, that would make it easier to understand.

In general, when a parameter gives a measure, units must be specified in the name. When the parameter gives a geometrical object (point, vector, rectangle), it would be nice to also specify the coordinate system where the object is defined.

Migrated from https://app.assembla.com/spaces/plus/tickets/901/details

MicronTracker tracking seems to work fine, but the interface classes (PlusLib\src\Tracking\MicronTracking\Utils) are implemented very poorly. Need a review and clean-up including:
VERY IMPORTANT PROGRAMMING NOTE in MicronTrackerInterface.cpp
check ownedByMe handling (probably it should be set to false if the handle is not created by new)
consistent return values (sometimes int, sometimes bool; sometimes non-zero means error, sometimes 0, false)
check timestamp computation (mtGetLatestFrameTime(cam) function can provide accurate enough without filtering)

There also seem to be a larger time lag in the tracking in Plus than in the MicronTracker CPP demo.

Migrated from https://app.assembla.com/spaces/plus/tickets/571/details

If we connect to exam using Ulterius with UseSharedMemory set to true, and if the application crashes, in the second connection we cannot get Bmode image from the data collector. The issue resolves if we restart the exam software.

Migrated from https://app.assembla.com/spaces/plus/tickets/566/details

Currently we don't check the residual returned by the least-square solver. At least we should display a warning if the residual is above a certain tolerance (it means that the computed results are unreliable).

Migrated from https://app.assembla.com/spaces/plus/tickets/424/details

PLUS support acquiring color Doppler data (color v/v) using Porta sdk

Migrated from https://app.assembla.com/spaces/plus/tickets/1035/details

Move attributes such as TiltSensorWestAxisIndex, AhrsAlgorithm, AhrsAlgorithmGain, etc. in the tool elements.

To manage deprecation: PLUS_ENABLE_DEPRECATED_API controls supporting of deprecated config file or algo interface. Remove in next major version (or after 6 months). Add date of deprecation. Log warning when deprecated API is used and explain how to migrate to the supported version.

<Device
Type=”PhidgetSpatial”
Id=”TrackerDevice”
AcquisitionRate=”125”
LocalTimeOffsetSec=”0.0”>

<DataSources>
<DataSource Type=”Tool” Id=”Accelerometer” PortName=”Accelerometer” BufferSize=”2500” AveragedItemsForFiltering=”20”/>
<DataSource Type=”Tool” Id=”Gyroscope” PortName=”Gyroscope” BufferSize=”2500” AveragedItemsForFiltering=”20”/>
<DataSource Type=”Tool” Id=”Magnetometer” PortName=”Magnetometer” BufferSize=”2500” AveragedItemsForFiltering=”20”/>
<DataSource Type=”Tool” Id=”TiltSensor” PortName=”TiltSensor” BufferSize=”2500” AveragedItemsForFiltering=”20” TiltSensorWestAxisIndex=”1” AhrsAlgorithm=”NONE/MADGWICK_IMU/MAHONY_IMU” AhrsAlgorithmGain=”1.5” />
<DataSource Type=”Tool” Id=”OrientationSensor” PortName=”OrientationSensor” BufferSize=”2500” AveragedItemsForFiltering=”20” AhrsAlgorithm=”MADGWICK_MARG” AhrsAlgorithmGain=”1.5” />
</DataSources>
<OutputChannels>
<OutputChannel Id=”TrackerStream” >
<DataSource Id=”Accelerometer”/>
<DataSource Id=”Gyroscope”/>
<DataSource Id=”Magnetometer”/>
<DataSource Id=”TiltSensor”/>
<DataSource Id=”OrientationSensor”/>
</OutputChannel>
</OutputChannels>
</Device>

Migrated from https://app.assembla.com/spaces/plus/tickets/802/details

The vtkDataCollectorHardwareDevice works fine on its own, but when the sector size is changed, then the received frame size and the buffer size do not match.

The following code snippet produces the error, where the dataCollector is a pointer of vtkDataCollectorHardwareDevice type.

// Change sector size to 50%
vtkSonixVideoSource* sonixDataCollector= static_cast<vtkSonixVideoSource*> (dataCollector->GetVideoSource() );
sonixDataCollector->SetSector(50);

dataCollector->Start();

121911_172507.717 [ERROR] [016.838000] Received frame size (249604 bytes) doesn't match the buffer size (499204 bytes)! [in ......\PlusLib\src\ImageAcquisition\SonixVideo\vtkSonixVideoSource.cxx(292)]

Migrated from https://app.assembla.com/spaces/plus/tickets/415/details

As it stands, visualizationcontroller is the entry point for writing configuration files, this doesn't make sense as the visualizationcontroller is a client of the pluslib. If a different client is used, then such an action wouldn't produce the same results.

Migrated from https://app.assembla.com/spaces/plus/tickets/757/details

After starting the refactor to remove the SelectedDevice and SelectedChannel concepts, I've run across a piece of code that made me re-think devices.

Why do we define the device output? Isn't the output of the device defined by the device?

For example: In the EpiphanVideoDevice, the InternalConnect used the SelectedChannel concept. However, there should only ever be one output channel for the Epiphan containing video, and that should never change. The only thing that should be changed is perhaps the behaviour of the device (aka BufferSize, etc...).

Anyways, this ticket is just to instigate a discussion about how we define devices.

Migrated from https://app.assembla.com/spaces/plus/tickets/668/details

See https://www.assembla.com/spaces/plus/messages/2066353

Migrated from https://app.assembla.com/spaces/plus/tickets/545/details

https://scan.coverity.com/projects/916

Migrated from https://app.assembla.com/spaces/plus/tickets/885/details

Find out the source of the difference.

See http://crunch.cs.queensu.ca/CDash/viewTest.php?onlyfailed&buildid=10107

Migrated from https://app.assembla.com/spaces/plus/tickets/590/details

BK's GrabbieLib needs some fixes and improvements:

• The TcpClient::Write(buffer, size) method in BK returns (size+2) if the operation is successful. It should return (size) instead. See usage in vtkBkProFocusOemVideoSource::InternalUpdate().
• Improve CMake files: it should properly export all library targets

Migrated from https://app.assembla.com/spaces/plus/tickets/722/details

As previously reported by others, too, volumes reconstructed using PlusRemote appear shifted in Slicer. If the volume is loaded from file then position is correct, the position is only corrupted when the volume is sent over Openigtlink.

Implement GUI and linear object algorithm in PLUS

Migrated from https://app.assembla.com/spaces/plus/tickets/787/details

The volume is sent with an id and the id is created as deviceid+hash.
When sending this volume, send also custom attributes like patient name patient id description and slicer should know what to do with them.
This will be implemented in the vtkPlusStealthLinkCommand

Migrated from https://app.assembla.com/spaces/plus/tickets/904/details

Define default models and give the possibility to the user to choose among them if they don't have an STL file.
Default freehand and endocavity probe models, needle, stylus etc.
This could be defined as: instead of <DisplayableObject Type="Model" ObjectCoordinateFrame="TransducerOrigin" File="L14-5_38_ProbeModel.stl"...> we could use <DisplayableObject Type="Model" ObjectCoordinateFrame="TransducerOrigin" ModelDefault="FreehandProbe"...>

See comments in https://www.assembla.com/code/plus/subversion/changesets/1828

Migrated from https://app.assembla.com/spaces/plus/tickets/536/details

We receive udtRF data from Ultrasonix scanners (Exam software 5.7) with a dimension 2080x256 when using an L14-5 transducer with default imaging parameters. There is a slight shift in every second line.

In Plus the assumption was that the shift is due to IQ encoding, and therefore two lines were combined into one during brightness conversion step. However, this seems not to be the case, but each line should contain a simple real-value signal (http://research.ultrasonix.com/viewtopic.php?f=6&t=967&p=3665#p3665).

Once this information is confirmed, change the SonixVideo data source to interpret the data as US_IMG_RF_REAL instead of US_IMG_RF_I_LINE_Q_LINE (it should be just a matter of changing this enum).

Migrated from https://app.assembla.com/spaces/plus/tickets/744/details

Use DevPartnerStudio (license available in PerkLab)

Migrated from https://app.assembla.com/spaces/plus/tickets/952/details

The following warning in PlusBkProFocusReceiver.cxx is displayed in certain cases:

LOG_WARNING("Not enough space allocated to store all the RF samples. Input: "<<numberOfSamplePairsInInput<<", output: "<<numberOfSamplePairsInOutput);

Currently the warning has been disabled to reduce clogging of the error log, but we should investigate why this happens and fix it. If the warning is displayed then scanlines are cropped and axial spacing after scan conversion may be incorrect.

Even if we don't understand why the scanline length is inconsistent between Prepare and DataAvailable, we could dynamically allocate a larger buffer if we find that the already allocated buffer is too small.

Migrated from https://app.assembla.com/spaces/plus/tickets/701/details

Add support for the new Interson USB Ultrasound SDK with the C++ wrapper around the C# SDK.

Migrated from https://app.assembla.com/spaces/plus/tickets/892/details

Prevent user errors by creating a configuration file generator from a database of known devices/phantoms/segmentation configs/etc...

Always allow the user to add his own custom elements (new phantom, new params, etc..)

Migrated from https://app.assembla.com/spaces/plus/tickets/607/details

This may be an idea for a student project in the future.

Stephen Aylward suggested that we look into this toolkit:
http://mi.eng.cam.ac.uk/~rwp/stradx/
If it's not open-source now, Kitware can share their similar code if we want to integrate it into PLUS. It does homogeneity correction and/or corrects displacements due to varying pressure of the US probe on the tissue during scanning.

He also suggested to look into Danielle's work:
http://www.midasjournal.org/browse/publication/655
to see if we can harvest code/ideas.

Migrated from https://app.assembla.com/spaces/plus/tickets/637/details

Use this repo:
https://github.com/niravatgit/MatlabOpenIGTLink

and remove the files in Plus:
https://www.assembla.com/code/plus/subversion/nodes/3847/trunk/MatlabUtils/MatlabOpenIGTLinkInterface

Migrated from https://app.assembla.com/spaces/plus/tickets/951/details

Determine optimal sensor fusion parameters for motorized transrectal probe rotator, using an optical tracker as ground truth

Migrated from https://app.assembla.com/spaces/plus/tickets/774/details

3D printed stylus is pretty good still sometimes might be worth to put at the end a metal tip, sharper and that does not break. Because the one used has been pivoted so many times that the tip is not so sharp anymore.

Migrated from https://app.assembla.com/spaces/plus/tickets/938/details

This is a proposal for adding version information to Plus binaries, which could be really helpful identifying the actual dll and app version.
Under Windows, we just need to add an rc file for each binaries once and CMake will do the rest.

Here is what I used in another project:

Create a new CMake include file (VsInterface.rc.in):

#include <winresrc.h>

VS_VERSION_INFO VERSIONINFO
  FILEVERSION @VSI_VERSION_MAJOR@, @VSI_VERSION_MINOR@, @VSI_VERSION_PATCH@, @VSI_REVISION@
  PRODUCTVERSION @VSI_VERSION_MAJOR@, @VSI_VERSION_MINOR@, @VSI_VERSION_PATCH@, @VSI_REVISION@
  FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#ifndef NDEBUG
  FILEFLAGS 0
#else
  FILEFLAGS VS_FF_DEBUG
#endif
  FILEOS VOS_NT_WINDOWS32
#ifdef VsInterface_EXPORTS
  FILETYPE VFT_DLL
#else
  FILETYPE VFT_APP
#endif
  FILESUBTYPE VFT2_UNKNOWN
  BEGIN
    BLOCK "StringFileInfo"
    BEGIN
      BLOCK "04090000"
      BEGIN
        VALUE "FileDescription", "Visualization Subsystem Interface"
        VALUE "FileVersion", "@VSI_VERSION_MAJOR@.@VSI_VERSION_MINOR@.@VSI_VERSION_PATCH@.@VSI_REVISION@"
        VALUE "InternalName", "Visualization Subsystem Interface"
        VALUE "ProductName", "Visualization Subsystem Interface"
        VALUE "ProductVersion", "@VSI_VERSION_MAJOR@.@VSI_VERSION_MINOR@.@VSI_VERSION_PATCH@.@VSI_REVISION@"
      END
    END
    BLOCK "VarFileInfo"
    BEGIN
      VALUE "Translation", 0x409, 1252
    END
  END

This is what we need to add to the actual CMake file:

SET(VsInterface_RESOURCES)
IF (WIN32)
  configure_file(
	${CMAKE_CURRENT_SOURCE_DIR}/VsInterface.rc.in 
	${CMAKE_CURRENT_BINARY_DIR}/VsInterface.rc
	)  
  SET (VsInterface_RESOURCES
    ${CMAKE_CURRENT_BINARY_DIR}/VsInterface.rc
    )
  SOURCE_GROUP(Resources FILES ${VsInterface_RESOURCES}) 
ENDIF()
...
ADD_LIBRARY( VsInterface ${VsInterface_SRCS} ${VsInterface_HDRS} ${VsInterface_RESOURCES} )
...

Let me know your thoughts.

Migrated from https://app.assembla.com/spaces/plus/tickets/479/details

According to a former discussion with Tamas, it would significantly boost the currency of Plus, if we had a tutorial that can be done at home using no special hardware.

A possible approach is a MicronTracker-like home-made tracking system, consisting only of a webcam, and printed markers.

The biggest component we don't have is a (checkerboard) camera calibration algorithm, but there may be an open-source method we can integrate.

Migrated from https://app.assembla.com/spaces/plus/tickets/610/details

With rotation along a fixed axis the Phidget sensor "OrientationSensor" tool appears to provide a more complex trajectory (not just a rotation along a single axis, but also some transient twisting).

Tune the parameters, so that the sensor fusion works correctly for a 180deg rotation around a horizontal axis at a 3-4deg/sec speed.

Migrated from https://app.assembla.com/spaces/plus/tickets/675/details

The new correlation-based temporal calibration works well for free-hand US, but when the transducer is in a stabilizer then it is more convenient to do the temporal calibration with the same phantom used for spatial calibration.

Modify the temporal calibration algorithm so that it can use an externally-computed video-based position signal. Modify the iCal application to use the new temporal calibration method.

Change iCalBrachy so that it uses this temporal calibration instead of vtkDataCollectorSynchronizer. Delete vtkDataCollectorSynchronizer class from the repository.

Migrated from https://app.assembla.com/spaces/plus/tickets/487/details

fCal_1.0_Wiring_1.0 is symmetric, therefore there is no way to tell if the probe is rotated 180deg. fCal_1.2_Wiring_1.1 has an asymmetric wire pattern, so it should be possible to determine the wire labels automatically, regardless of the orientation of the probe. However, it should be tested that the labeling really works correctly for any probe orientation. Once the display of the wire names in the segmentation dialog box is completed (#308) then this functionality can be tested easily. If the labeling is correct only for a certain probe orientation then the labeling algorithm shall be improved so that it works for all probe orientations.

Migrated from https://app.assembla.com/spaces/plus/tickets/435/details

The volume reconstructor works for color images, but the output is hardcoded to be grayscale. Need to make vtkPasteSliceIntoVolume::ResetOutput.configurable.

See discussion here:
https://www.assembla.com/spaces/plus/messages/4964273#comment_4990023

Migrated from https://app.assembla.com/spaces/plus/tickets/977/details

Goal: Algorithms implemented in Plus should be reusable from Slicer modules or other external applications.

Approach: Modify PlusLib so it is usable alone. Compile PlusLib without hardware support.

Tasks:

• Try to compile PlusLib in a SlicerIGT module. Create superbuild CMake that checks out the code. (Andras)
• In the same module implement conversion between Plus tracked frame list and sequence nodes (Multidim Data). (Matt)
• Check how module/extension dependency works in Slicer so this module would automatically install Multidim Data. (Lower priority, Matt)

Migrated from https://app.assembla.com/spaces/plus/tickets/943/details

Maintain the list of Plus-related papers in doc\references.

Migrated from https://app.assembla.com/spaces/plus/tickets/711/details

For debugging purposes it would be useful to be able to draw the image orientation (two labelled arrows pointing to M and F directions) in the image pixels. This way it could be checked if the image orientation remains consistent during the processing, exporting, and importing the images.

Migrated from https://app.assembla.com/spaces/plus/tickets/423/details

Support for probes from:

http://www.capolabs.com/

Migrated from https://app.assembla.com/spaces/plus/tickets/1007/details

Currently, the OrientationSensor and FilteredTiltSensor tools in the PhidgetSpatial tracker require a couple of seconds (or more, depending on the gain value) to converge from the initial orientation to the current orientation. To avoid this artifact, when the first measurement is obtained from the sensor, that measurement data should be used to update the sensor fusion algorithm many times, making that converging to the orientation that corresponds to the current position. This initialization technique is implemented in the SpatialSensorFusion application, so it could be taken from there.

Migrated from https://app.assembla.com/spaces/plus/tickets/791/details

• Create wiring recommendation (XML description and screenshots)
• Create non-regression test case with test config file, image sequence, baseline data
• The letters on both sides are denoted with capital letters, one side should be lower case (as per fCal 2.0)
• Not all landmark dimples have the same depth

Migrated from https://app.assembla.com/spaces/plus/tickets/941/details

Currently only xxA port image orientation is supported. If input is xxD then the image should be flipped around the third axis, but it is not implemented yet.

Migrated from https://app.assembla.com/spaces/plus/tickets/960/details

With the current vtkBkProFocusVideoSource switching between sagittal and axial transducer requires disconnect and connect. Now Plus supports multiple output channels (each with a different video stream) for devices. However, the BK video source should be update to take advantage of this. The BK video source should detect which scan plane is used for each acquired frame and emit the video on the appropriate corresponding output channel.

Implementation steps:

• mechanism to get the plane info from BK (Andriy)
• second output channel (Andras, Adam)
• test everything with the real hardware (Andriy)

Migrated from https://app.assembla.com/spaces/plus/tickets/674/details

We have used the attached patch to add support for several additional BK probes (so far used with 8862 probe to acquire RF data during one neurosurgery case).
This issue is to request review and advice. In particular there are two points which would break support for the prostate probe:

L44: there is only one channel available (also for 8863 and 8820e probes)

• Should I add a configuration option to make this check contingent on a configured number of channels?

L57: the modelID field != 0 for at least the 8862

• Not sure what to do about this.

Thank you.

Migrated from https://app.assembla.com/spaces/plus/tickets/854/details

In vtkRfToBrightnessConvert when the input is brightness (so only scan conversion is performed) the pixels are copied line-by-line. Optimize the converter to not copy the pixels (see the TODO: text in vtkRfToBrightnessConvert.cxx)

Migrated from https://app.assembla.com/spaces/plus/tickets/691/details

Relevant OAPI function is RigidBodyAddFromFile()

• Get information about the commands (Andras)
• Implement class to communicate with the hardware

Migrated from https://app.assembla.com/spaces/plus/tickets/856/details

Amount of data generated by the vtkBkProFocusVideoSource is huge. Probably the RF scanlines need not to be acquired at full resolution. Expose the decimation parameter of the PlusBkProFocusReceiver as a parameter in the device set configuration file.

Migrated from https://app.assembla.com/spaces/plus/tickets/599/details

... and as in vtkBrackyStepperPhantomRegistrationAlgo

Migrated from https://app.assembla.com/spaces/plus/tickets/405/details

The depth is frequently changed during US-guided interventions. Since we have different ImageToProbe matrices for each depth, stored in different config files, the PlusServer should be restarted now at each change in depth. This takes unacceptably long time during interventions.

A possible solution: ImageToProbe matrices could be stored for every possible depth in one config file. PlusServer could always apply the one for the actual depth parameter.

Migrated from https://app.assembla.com/spaces/plus/tickets/582/details

Disable access to data sources, force all devices to request data from previous device in the pipeline, extract/copy any necessary data and place in new output channel.

This will increase memory requirements but provide a safer, cleaner, less bug-prone implementation.

Migrated from https://app.assembla.com/spaces/plus/tickets/756/details

With github workflow, I find it difficult to enforce requirement of referencing to an issue in each commit comment (re #999: Some message) and overall it has limited value (as you can include details in the commit comment and if more background is needed then an issue can be referenced anyway).

Why difficult to enforce:

• merge commits are not well formed by default
• rejecting commits from contributors because of not referencing an issue is not easy
• generic or old tickets can be referenced that formally fulfills the requirement but actually not useful
• sometimes developers not install pre-commit hook

What do you think about removing the pre-commit hook and the requirement of running SetupForDevelopment.sh?

@adamrankin @cpinter