open-vv / vv Goto Github PK

Tool to draw a ROI (following ImageJ tools)

• open an image with vv
• enlarge / shrink the image
• press the refresh button
  ⇒ the sliders are not limited to the correct values

I had a 3D image with one slice. The vv tool seems to be very sensitive to the kernel sizes I chose. I’m in favor of removing this vv tool.

Couldn’t compile with MSVC++. Pardon my French but it took me a while to get it... The error message was:

1>d:\src\clitk3\clitk3\itk\clitkSliceBySliceRelativePositionFilter.txx(223): error C2668: 'clitk::JoinSlices' : ambiguous call to overloaded function
1> d:\src\clitk3\clitk3\itk\clitkSegmentationUtils.txx(541): could be 'itk::SmartPointer clitk::JoinSlices(std::vector<_Ty> &,const ImageType *,int)'
1> with
1> [
1> TObjectType=itk::Imageclitk::uchar,3,
1> ImageType=InputImageType,
1> _Ty=itk::SmartPointer<itk::Image<unsigned char,2>>
1> ]
1> d:\src\clitk3\clitk3\itk\clitkSegmentationUtils.h(226): or 'itk::SmartPointer clitk::JoinSlices(std::vector<_Ty> &,const ImageType *,int)'
1> with
1> [
1> TObjectType=itk::Imageclitk::uchar,3,
1> ImageType=InputImageType,
1> _Ty=itk::SmartPointer<itk::Image<unsigned char,2>>
1> ]
1> while trying to match the argument list '(std::vector<_Ty>, itk::SmartPointer, int)'
1> with
1> [
1> _Ty=itk::SmartPointer<itk::Image<unsigned char,2>>
1> ]
1> and
1> [
1> TObjectType=itk::Imageclitk::uchar,3
1> ]

I understood the reason when I saved the output of the preprocessor. It turns out that clitkSegmentationUtils.txx includes itkSliceBySliceRelativePositionFilter.h and itkSliceBySliceRelativePositionFilter.txx includes clitkSegmentationUtils.h. As a result, it ends up using JoinSlices before it’s defined. I think it’s logical to have a compiler error but I don’t know why gcc manages better.
Temp fix: commented out JoinSlices declaration in .h but this is a nasty patch.

Note: this seems to be link to this commit I had to do to compile and which did not make any sense: http://cvs.creatis.insa-lyon.fr/viewvc/clitk3/itk/clitkSegmentationUtils.txx?r1=1.9&r2=1.10

in small executables with appropriate naming.

I am using vv from git master with experimental features enabled. When trying to perform deformable registration I get:

sh: deformableregistration: command not found

As no executable with that name is built I assumed that clitkDemonsDeformableRegistration would be the correct name. However this leads to

./clitkDemonsDeformableRegistration: invalid option – d

Additional errors show that clitkVFMerge is referenced which does not exist as well.

In addition, all the helper tools such as clitkZeroVF or clitkVFMerge have to be in $PATH in order to be found.

In the info panel:
The size calculated from #pixel is not totally consistent.
Eg:
With an image of 28049408 short voxels (ie. 2 bytes per voxel) the size is:
28049408 * 2 = 56 MB. But it's written 54 MB.
It's due to the function GetActualMemorySize. The output is in kibibytes (1024 bytes). And then we convert it in MB by divided by 1000 instead of 1024 to have Mebibyte (and to be coherent) or 1000²/1024 to have MB.

Proposition: To be more understandable I will convert everything in kB, MB, GB. (even the memory usage)

In /srit/data/ChristophZollner, if I do
vv patient.mhd
Tools/Register Manually
vv crashes and sends:
Error
terminate called after throwing an instance of 'itk::ExceptionObject’
what(): /home/tbaudier/vv/vv_Thomas/itk_src/Modules/Core/Transform/include/itkRigid3DTransform.hxx:94:
itk::ERROR: Euler3DTransform(0x4ae8a80): Attempting to set a non-orthogonal rotation matrix
Abandon

Open a 4D image.
Overlay a 4D vector field.

It fails:
Error while reading vf_midp_4D.mhd
itk::MemoryAllocationError (0x7fc9f0000940)
Location: "TElement* itk::ImportImageContainer<TElementIdentifier, TElement>::AllocateElements(itk::ImportImageContainer<TElementIdentifier, TElement>::ElementIdentifier, bool) const [with TElementIdentifier = long unsigned int; TElement = itk::Vector<float, 3u>; itk::ImportImageContainer<TElementIdentifier, TElement>::ElementIdentifier = long unsigned int]"
File: /usr/local/include/ITK-4.9/itkImportImageContainer.hxx
Line: 199
Description: Failed to allocate memory for image.

Mavericks builds for Mac 10.9 were broken.

A series of patches have been created that address this.

https://github.com/hjmjohnson/vv/tree/20140605_MacBuildFixes

I’ve also added patches to this ticket that contain the necessary changes.
patch.ZIP
The easiest way to merge these changes is the following:

cd VV
git fetch origin
git remote add hjmjohnson https://github.com/hjmjohnson/vv/tree/20140605_MacBuildFixes
git checkout 20140605_MacBuildFixes
git rebase origin/master
git push origin 20140605_MacBuildFixes:master

=========
commit ec4326b807e18e9cac3d25837ee79aa8c7624fc4
Author: Hans Johnson [email protected]
Date: Thu Jun 5 10:59:00 2014 -0500

STYLE: Move CMake commands to match new conventions

The next step in removing end-of-lines is to run through all the
    CMakeLists.txt files and clean them up.

This also changes all the key words to lower
    case. The primary reason for changing key words is that all documentation for
    CMakeLists.txt now shows the key words as lower case. Even the printed
    “Mastering CMake v5” uses lower case. I’ve come across this several
    times in my class where students stumble over the fact that the
    documentation about Cmake does not match the implementation in ITK.

I have a script (a wrapper around a vim macro) written that can make
    these substituions reliably (Tested on the BRAINS tree, the Slicer3
    tree, and the ITK tree without causing any errors).  more complete
    documentaiton can be found attached to

commit 9108f90304fbc233087748de89fa3d0fd9acd2a8
Author: Hans Johnson [email protected]
Date: Thu Jun 5 10:47:48 2014 -0500

COMP: Remove circular downloading of vv

The superbuild process does not require re-downloading
    vv inside of the build directory.  This patch points to the
    original parent downloaded directory for building.

By removing the redundant download, it is much easier to
    identify and test changes.

commit b14e05d
Author: Hans Johnson [email protected]
Date: Thu Jun 5 09:43:10 2014 -0500
COMP: First Mac 10.9 build fixes.

This patch probably includes a few items that are
    not strictly necessary, but during the fumbling
    around to find a working solution, these
    were the identified failures.

Updating VTK and ITK were key components to
    make this process work.

commit b054222
Author: Hans Johnson [email protected]
Date: Sat May 31 09:01:12 2014 -0500

COMP: Update ITK and VTK

ITK and VTK updates allow building with c++11 on
    mavericks with the latest apple clang compiler.

commit 6451a54
Author: Hans Johnson [email protected]
Date: Sat May 31 07:59:26 2014 -0500
COMP: C++11 identified type missmatches

rtkHisImageIO.cxx:149:53: error: constant
    expression evaluates to 134 which cannot be narrowed to type 'char'
    [-Wc++11-narrowing]

A suggestion from Christoph Zollner, I have no clue if this would be doable... It would be nice if one could open another image from the command line in an existing VV instead of having to open another VV instance.

clitkSum -i foo.mhd -o foo2.mhd -d 1
It seems that foo2.mhd is flipped around y-axis.

For the moment, we can obtain the correct image with:
clitkAffineTransform -i foo.mhd -o foo2.mhd -m foo.mat --transform_grid
clitkSum -i foo2.mhd -o foo3.mhd -d 1

with foo.mat:
1 0 0 0
0 1 0 0
0 0 -1 0
0 0 0 1

Add check on required modules for ITK and VTK with meaningful user message if one is missing. Maybe make ITK_Module_review optional with conditional compilation in the cmake file.

Stop using default.afdb

The static compilation fails.

[ 98%] Built target vvLib
vv/CMakeFiles/vv.dir/build.make:317: * target pattern contains no '%'. Arrêt.
CMakeFiles/Makefile2:98: recipe for target 'vv/CMakeFiles/vv.dir/all’ failed
make1: [vv/CMakeFiles/vv.dir/all] Error 2
make1: Attente des tâches non terminées....
[ 99%] Built target clitkDicomRTStruct2Image
[ 99%] Built target clitkAffineRegistration
Makefile:149: recipe for target 'all’ failed
make: * [all] Error 2

And into vv/CMakeFiles/vv.dir/build.make:317
bin/vv: Qt5::UiPlugin-NOTFOUND

vv.pro.zip

With VTK5.10 and Qt5.x
The fusion image isn’t refreshed.

(cf Adrien)

The bug seems to be reproducible with VTK6 and QT5 during few seconds:
Open vv
Open the CT
Open the SPECT
don’t move the mouse pointer.

Instead of sliders, many users would prefer something we could grab with the mouse on the image to do the registration manually.

For example, in clavaire:DB/Base_de_donnees_unsorted/TF^^/CT/...
There is 2 series of dicom in the same folder (open it with vv/Open Dicom).
And there is only one .mhd file binding the 2 dicom series.

It’s a problem but I don’t know where is the problem:

• Is a sorting issue? : ie the 2 dicom series have to be in 2 different folders.
  or - Is a Dicom2Image conversion issue? : ie. we want to have 2 .mhd files.

Moreover, in the help of clitkDicom2Image, there is a tag: --extract_series (-s). If I understand well, with this tag it should separate the 2 dicom series. But it doesn’t because software look the tag (0020, 0011) with the same value for both series. Maybe it should wath another tag, eg: (0009, 111e) or (0009, 1146).

The transform is copied but I think the new origin is not accurate. At least, after cropping, the two images do not overlap when I used vv img.mha --overlay crop.mha.

It is only working after going to another application and coming back

Hi Developers, thanks for this great tool.
I have a feature request: visualisation in the x-t plane (or y-t, or z-t). In such a plane you can see the motion over time at once, by observing how straight the edges are. This article contains some examples:
http://www.bigr.nl/files/publications/613_Metz2010MEDIA.pdf
I hope I explain it clear enough. Perhaps it’s already possible, but I didn’t find it.
Kind regards,
Stefan

It seems that commontk.org provides a qt dicom widget. It would be nice to use it in vv to query dicom servers.

For example.
clitkDicomRTStruct2Image -i foo.dcm .....
I obtain 2 images from the 2 dicom structures:
one called struct1.mhd and the second: struct2(%Max=5).mhd (eg. name given by Dosisoft’s software).

Do:
vv struct1.mhd : it works (with a 0 and 1 image)
vv struct2(%Max=5).mhd : the image is opened but it’s totally black (0 everywhere)
rename struct1.mhd into struct1(%Max=5).mhd, struct1.raw into struct1(%Max=5).raw and change in the .mhd the path to the raw file.
vv struct1(%Max=5).raw : the image is opened but it’s totally black (0 everywhere)
rename struct1(%Max=5).mhd into struct1.mhd, struct1(%Max=5).raw into struct1.raw and change in the .mhd the path to the raw file.
vv struct1.mhd : it works (with a 0 and 1 image)
rename struct2(%Max=5).mhd into struct2.mhd, struct2(%Max=5).raw into struct2.raw and change in the .mhd the path to the raw file.
vv struct2(%Max=5).mhd : the image is opened but it’s totally black (0 everywhere)

---------- mail from Gloria ----------
When she want to save .jpg or .png screenshots; the saved images is totally black

The problem occurs sometimes with clitkWriteDicomSeries (cf Cyril).

The mhd image has a spacing of: [0.200000003, 0.200000003, 0.25]
But in the .mhd file the spacing is : [0.2, 0.2, 0.25]
The dicom spacing is : [0.2, 0.2, 0.25] (it’s correct)

So when I do 'if ([mhd spacing] == [dcm spacing])' the answer is FALSE instead of TRUE.
It’s due to a precision problem in itk::ImageFileReader
but for the moment, I don’t find the solution to change the precision.

I don’t get them but I think this is related to virtual inheritance

3>d:\src\clitk3\clitk3\segmentation\clitkTestStation7.h(32): warning C4250: 'LymphStationSegmentationFilterBase' : inherits 'clitk::FilterWithAnatomicalFeatureDatabaseManagement::clitk::FilterWithAnatomicalFeatureDatabaseManagement::GetNameOfClass' via dominance
3> d:\src\clitk3\clitk3\segmentation\clitkFilterWithAnatomicalFeatureDatabaseManagement.h(42) : see declaration of 'clitk::FilterWithAnatomicalFeatureDatabaseManagement::GetNameOfClass'
3>d:\src\clitk3\clitk3\segmentation\clitkTestStation7.h(115): warning C4250: 'ExtractLymphStation_7' : inherits 'clitk::FilterWithAnatomicalFeatureDatabaseManagement::clitk::FilterWithAnatomicalFeatureDatabaseManagement::GetNameOfClass' via dominance
3> d:\src\clitk3\clitk3\segmentation\clitkFilterWithAnatomicalFeatureDatabaseManagement.h(42) : see declaration of 'clitk::FilterWithAnatomicalFeatureDatabaseManagement::GetNameOfClass'

vtkImageReslice is used to take into account the transforms. It seems that the spacing is not approprately computed for an anisotropic image where axes are flipped (although the [[http://www.vtk.org/doc/nightly/html/classvtkImageReslice.html#a5637b6baa5f4e3e013dc801786e8dd29]] indicates it should).

from David:
Open an Image in vv.
Tools/Open ROI : it crashes with a Segmentation fault error

Hi,

I have started a custom visualization mode for simultaneous visualization (fusion) of 4D-CT and 2D+t US, with a working prototype, and I am asking for feedback whether this feature would be of interest for integration into vv.

For US data, each frame has its own transform matrix, indicating the position of the (moving) probe wrt the room.
I also know the transform matrix between the CT image and the room. M_CT2US
What I want is to display, for any given frame t_US of the US, the corresponding slice (typically, an oblique slice through the current CT volume t_CT)

To do so, I load the 4DCT, with an associated .mat which projects it into the US coordinate system.
I load the US sequence as a 'modified’ fusion ; doing so, I store the individual transforms (Mt_US) attached to each US frame. For display, I replace all of them by identity matrices, so I can see the US images in plane.
Then, I use sliders to select the current US frame, and apply a transform matrix to the CT (composing Mt_US and M_CT2US) such that the correct oblique slice of the CT volume is displayed simultaneously.
Further, to facilitate navigation, the US sequence is also opened independently and linked (using vv link feature) to the fused 4DCT+US (and tied according to my code), such that clicking somewhere on this US image recenters the 4DCT+US to the US plane.
In a next step, I intend to add some kind of temporal synchronization, such that based on additional information, the visualization mode could automatically select the matching CT frame (t_CT) for a given t_US, and vice versa.

I am far from an expert with git, but if you explain me how to do it, I could push my code and some test data into an experimental branch so you can check how it works, and so we can discuss whether & how this could be useful for vv.

Best,

Rémi

Consistently having issues...

vector fileds

• on XY plane (axial) are not show. it seems to be a z-buffer issue...

fusion

• overlay intermittently disappears as we navigate through slices. may be a z-buffer issue too...

either for a given amount of time (~1s) or while w is pressed.

For some reason the code has been commented out:
98b2e75

Hi,

when fusing a 2D image to a 3D volume, I encounter a few issues:

• as mentioned in another bug report, when visualizing things such that the 2D image is aligned with one of the main plane (e.g. axial) it no longer appear on the orthogonal views
• Let’s say the 2D image is in the (x,y) plane at zi=0, when browsing the volume along the z direction, the image is invisible for z<zi and visible at z=zi (as expected so far), but remains visible for any z>zi – regardless of the actual image voxel size (the 2D image is actually a 3D image with 1 voxel thickness)
• I also experience an issue of voxel values set to 0 for entire 2D slices. I encountered the issue when working on a custom visualization mode for fusion of 4DCT and US sequences. However the issue seems reproducible when trying to overlay a 2D+t sequence on top of a 3D+t sequence.
  This may have something to do with rounding issues with rotations/translations, but I couldn’t figure it out.
  I can send/link to the data I use for reproducing the issue if necessary.

Best,

Rémi

Text boxes for window, level and manual registration are difficult to use in practice. A simple test is to enter manually the values of the rigid registration obtained with elastix. I’m not sure how this should be fixed but it should...

With Qt5.5.1 (or less), the mouse movement are slow.
It’s due to XCB. The proble is reported with Opensuse
The problem is described here with a patch:
https://codereview.qt-project.org/#/c/115531/

You have to copy/paste the 3 joined files into:
qtbase/src/plugins/platforms/xcb/
patch.zip

With large image, the computer isn’t sufficient to open it (out of core).
Use the itk tool: IOStreaming to open them.

Subsampling only changes when scale or width (Overlay panel) is also changed, and that still only after the image is clicked.

vvToolRigidReg is unrobust to gimbal lock configurations.

To have a better vector field comparison, we could display different vector fields using multiple colors.

Works under Windows.

vvLib has been created for gtest. I don’t think we want to use this anymore. Maybe trash vvLib along with all gtest aspects?

This is just a reminder that we should attempt to stick to generic tools for this sort of operation. Nothing urgent, we may need to discuss with David how he does produce his tools.

Jérôme thinks that being able to look at the histogram of an image and adjusting the window/level accordingly is what he’s missing the most in VV compared to ImageJ.

Opening a 3.3 GB image takes 17 GB of RAM in the latest version.

On the latest VTK7 ITK 4.9, I have the following Warning when using vv with meshes:
Warning: POINT type not fully supported. (don’t use GetMesh() with this!)

but if I have the manual registration window (and maybe others), it doesn’t quit vv

The transform in the mha of a ROI is not accounted for, it would be nice if it were.

With VTK7 and OpenGL2, some includes aren’t supported, eg:
vv/vvBlendImageActor.cxx:26:39: fatal error: vtkOpenGLExtensionManager.h: Aucun fichier ou dossier de ce type
#include “vtkOpenGLExtensionManager.h”

There isn’t replacement:
http://vtk.1045678.n5.nabble.com/VTKOpenGLExtensionManager-in-VTK-7-0-td5736440.html

Is it possible to add (compiled) binary releases for VV to Github? I see they're only available here [1] right now, which may not be obvious.

[1] https://www.creatis.insa-lyon.fr/rio/vv