A vigra array without axistags should have the same behaviour of a numpy array on the c++ and python side

We should make more use of Doxygen's built-in grouping support (look how the ITK page http://www.itk.org/Doxygen/html/modules.html uses \defgroup and \ingroup, compare the source http://itk.org/gitweb?p=ITK.git;a=blob_plain;f=Documentation/Doxygen/Modules.dox;hb=HEAD)

Also, we should review if the post-processing (post.py and makeFunctionIndex.py) is still necessary or if doxygen meanwhile provides better ways of achieving this.

Of course, we should also fix all warnings in the Doxygen output.

Some entities don't seem to belong to any group and are just deocumented in their respective namespaces. This should be fixed.

I would like to use the vigra library on images saved from MeVisLab.

Background: MeVisLab uses a DCM/TIFF format, in which a .dcm file contains the medical meta information and a corresponding .tif file contains the image data. However, this uses tiled TIFF format (as MeVisLab uses a tiled image representation internally to be able to handle arbitrarily large images). This is rather esoteric in the sense that really not many programs can read tiled TIFFs.

I have had a glance at the tiled image loading documentation of libtiff, but it is quite terse. The existing TIFFDecoderImpl in tiff.cxx is already quite complex, so I hope I won't mess things up.

What particularly struck me, was that Andrew Mihal has explicitly changed back from the strip-based, to a scanline-based loading method in 2004 (commenting that the former can be a memory hog), see the tiff.?xx changes in 86fda5d. However, I think going to a tile-based loader would revert this change.

Since we switch officially to github (see Ullis mail on bv-mip), the vigra homepage should point to github and not to the mercurial repo.

I saved the code (together with the entire 3D Canny operator code) into branch 'feature-canny3d'

a function able to work with different sigmas in different direction should be allowed to get sigmas with associate axistag in each direction, for example gaussian smoothing with sigmas different for x and y and z

Currently, one has to write:

using namespace vigra::functor;
combineTwoMultiArrays(srcMultiArrayRange(a1), srcMultiArray(a2), destMultiArray(a3),
                      exp(-Arg1()*abs(Arg2())));

It would be easier to be able to write:

a3 = exp(-a1*abs(a2));

However, to implement this efficiently (without temporary arrays and unnecessary copying) requires considerable work. Essentially, the latter mathematical expression must be converted automatically into the former functor-based form, using template magic similar to the blitz++ library.

Besides the usual functionality, it should also support overlapping bins (i.e. sampling prefilters that are better than the simple box function of a naive histogram class).

Altough this functionality is already available using inspectImage(), member functions of MultiArrayView like in numpy are much more convenient. We would like

• min
• max
• mean
• variance
• stddev
• quantile(double percentile)
  When the histogram class is ready, a histogram function will also be possible. Restriction of the function to particule axes should be supported by the following syntax:

MultiArray<3, double> u(Shape3(200, 100, 50)), uMax(Shape3(1, 100, 1));
... // fill u
u.max(uMax);  // compute maximum along the singleton dimensions 0 and 2  

should probably be done after refactoring (see #16)

Based on implementations by Martin Lindner, Xinghua Lou, and Hans Meine

I found out that on my system (Mac OS X 10.7, 64bit, g++-4.2.1) the following example from the doc fails:

vigra::reflectImage(srcImageRange(src), destImage(dest), vigra::horizontal | vigra::vertical);

The compiler argues with an error: no matching function for call to ‘reflectImage(foo, ..., int)’. I think that this is quite correct, because the reflectImage method is just defined for vigra::Reflect mode as last parameter, an the "or" of both modes gives an int - 3, which is not a valid entry in the vigra::Reflect enum.

I thus propose to extend the enum Reflect by adding a third value both = horizontal | vertical. The other code may remain unchanged. Please note that this problem also affects the transposeImage function.

I have no idea, why I get this error nowadays, I used the reflect function times ago with older compilers and never came to this issue...

A SplineImageView does not work with an image(width,1).
At least there should be a precondition_violation() if that case is not supported.
Instead the program segfaults.

Test Case:

diff --git a/test/imgproc/test.cxx b/test/imgproc/test.cxx
index 0b16f24..77a3d93 100755
--- a/test/imgproc/test.cxx
+++ b/test/imgproc/test.cxx
@@ -1471,6 +1471,19 @@ struct SplineImageViewTest
         catch(vigra::PreconditionViolation) {}
     }

+    void test1d() {
+        // test reading a 1D-Spline-Image view
+        Image img_1d;
+        img_1d.resize(128,1);
+        for (int x=0; x<img_1d.width(); x++)
+        {
+            img_1d(x,0)= rand()/(double)RAND_MAX;
+        }
+
+        SplineImageView<N, double> view_1d(srcImageRange(img_1d));
+        for (int x=0; x<img_1d.width(); x++)
+        {
+            shouldEqual( view_1d(x, 0), img_1d(x,0));
+        }
+    }
+

     void testVectorSIV()
     {
         // (compile-time only test for now)
@@ -1681,6 +1694,7 @@ struct ImageFunctionsTestSuite
         add( testCase( &SplineImageViewTest<3>::testCoefficientArray));
         add( testCase( &SplineImageViewTest<3>::testImageResize));
         add( testCase( &SplineImageViewTest<3>::testOutside));
+        add( testCase( &SplineImageViewTest<3>::test1d));
         add( testCase( &SplineImageViewTest<5>::testPSF));
         add( testCase( &SplineImageViewTest<5>::testCoefficientArray));
         add( testCase( &SplineImageViewTest<5>::testImageResize));

Returns:
Failure in SplineImageViewTest<3>::test1d()
Unexpected signal: memory access violation

Encompasses #23

use HDF5File class if possible

Running make check produces an error in test_impex.py

executing test file /home/miheld/src/vigra_git/build/vigranumpy/test/test_impex.py

..E

ERROR: test_impex.test_writeAndReadVolumeHDF5

Traceback (most recent call last):
File "/home/miheld/lib/python2.7/site-packages/nose-0.11.4-py2.7.egg/nose/case.py", line 186, in runTest
self.test(*self.arg)
File "/home/miheld/src/vigra_git/build/vigranumpy/test/test_impex.py", line 141, in test_writeAndReadVolumeHDF5
im.writeVolumeToHDF5(volume256, "hdf5test.hd5", "group/subgroup/voldata")
RuntimeError: createDataset(): unable to open output file.

The problem can be easily fixed by adding h5py_file.close() at the end of test_writeAndReadImageHDF5 and test_writeAndReadVolumeHDF5

When a new axistags is inserted the shape of the underling array should be modified accordingly, and maybe insert one sigleton dimension.

Moreover there should be a method to query how many indeces are associated with a certain axistag and there should be a way to squeeze signgleton dimensions and at the same time remove the corresponding axistags.

Ulli, did your migration script also convert the former version tags so that you could push them?
Otherwise I'll extract them from .hgtags and add them to git.

This Python program causes non-deterministic segmentation faults on
AMD64 (code snippet equivalent to vigranumpy/test/test2.py):

import numpy
import vigra.noise
import vigra.arraytypes
image = vigra.arraytypes.ScalarImage(numpy.random.rand(100,100)*255, dtype=numpy.float32)
vigra.noise.noiseVarianceClustering(image)

With the current development version I get the following output:

RuntimeError: 
Invariant violation!
noiseVarianceListMedianCut(): internal error (k: 0, k1: 0, k2: -1, noise.size(): 0, clusters.size(): 1).

see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586247

This is on ubuntu. Maybe static build should disable vigranumpy?

tesch@x:/src/vigra-build$ cmake -DVIGRA_STATIC_LIB=ON ../vigra
tesch@x:/src/vigra-build$ make
....
Copying module to temporary module directory
[ 81%] Built target vigranumpy_geometry
Scanning dependencies of target vigranumpy_impex
[ 84%] Building CXX object vigranumpy/src/core/CMakeFiles/vigranumpy_impex.dir/impex.cxx.o
Linking CXX shared library impex.so
/usr/bin/ld: ../../../src/impex/libvigraimpex.a(codecmanager.cxx.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
../../../src/impex/libvigraimpex.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [vigranumpy/src/core/impex.so] Error 1
make[1]: *** [vigranumpy/src/core/CMakeFiles/vigranumpy_impex.dir/all] Error 2
make: *** [all] Error 2

Need for the Gyrus segmentation workflow

If the axistags are not set is not possible to print vigraArray since they the internal swap axis order function needs axistags.

Probably the should be printed as unknown axis tags or with a special flag for non set axistags.

Compare with Michael's matlab implementation, using the same random numbers.

And while you are at it: variable names and Python documentation could also be improved.

see, for example, Eirc Jonssons report on an implementation of Linköping University.

This should be based on the histogram class of issue #38.

The API is now ready for publication. From the comment:

// Usage:
//
// void time_it()
// {
//     USETICTOC
//
//     TIC
//      ... // code to be timed
//     TOC
//      ... // untimed code
//     TIC
//      ... // other code to be timed
//     TOC
// }
//
// Intead of TOC which outputs the time difference to std::cerr, 
// you may use TOCN (the time difference in msec as a double)
// or TOCS (the time difference as a std::string). 
//
// Alternatively, you can performe nested timing like so:
//
// void time_it()
// {
//     USE_NESTED_TICTOC
//
//     TICPUSH
//      ...      // code to be timed
//     TICPUSH
//      ...      // nested code to be timed
//     TOC       // print time for nested code
//      ...      // more code to be timed
//     TOC       // print total time
// }
//
// Timings below 1 msec are generally subject to round-off errors. Under
// LINUX, you can #define VIGRA_HIRES_TIMING to get better
// accuracy, but this requires linking against librt.

for example:

    b = array.dropAxis(indexOrKey, at)
    # equivalent to:
    #   array[:, 0, ...] with the appropriate binding position
    # in fact this could be extended to a sophisticated binding function, e.g.
    b = array.bind(y = :, x = 1:10, z=1, c=0)
    # where the keyword arguments are translated into axis keys
    # however, this may not work because the kw dictionary doesn't store the keyword order

    b = array[..., vigra.newaxis(vigra.AxisInfo(...))]
    # equivalent to:
    #   b = array[..., numpy.newaxis]
    #   b.axistags = vigra.AxisTags(b.axistags[0], b.axistags[1], vigra.AxisInfo(...))

    s = array.axistags['x'].shape
    # equivalent to (this is probably good enough):
    #   s = array.shape[array.axistags.index('x')]

    b = vigra.taggedview(plain_ndarray, axistags)  
    # equivalent to (modulo some consistency checks):
    #   b = plain_ndarray.view(vigra.VigraArray)
    #   b.axistags = copy.copy(axistags)

    # make te following work (currently, the assignment is into a copy of the AxisInfo)
    a.axistags[1].resolution = 1.0
    # or add an alternative function, like
    a.axistags.setResolution(1, 1.0)
    # currently, we have to write
    #   ai = a.axistags[1]
    #   ai.resolution = 1.0
    #   a.axistags[1] = ai

Also mark axistags functions as 'private' that should only be called from within an array function.

merge Luca's changes

Found and corrected bug in nearBorderDirectionsCausal() it has to be tested for all the possible direction.
Additionally extend the vigra test suit to test all the volume functions also for the 26 neighbourhood when possible.

See http://www.stack.nl/~dimitri/doxygen/formulas.html for details.