fxihub / libspimage Goto Github PK

libspimage produces 3D volumes with the wrong dimensions. Swapping the first and 3rd dimension in write_h5_img should fix this, but I'm afraid it breaks something else.

Hi,
There is an issue when trying to phase a 256x256x256 model with support update. I get a "CUDA error "invalid argument" at image_filter_cuda.cu:54" (at sp_gaussian_blur_cuda) at iteration 17 (spimage.sp_support_array_init(spimage.sp_support_area_alloc(blur_radius, support_area), 20)) on both a and c nodes. There is no problem to run with static support.
If reducing the size of the input from a cube of 256 to 254 there is no error.

This should give a more useful error message. If the area is given in #pixels for example.

I tried to install libspimage on a new computer but got an error I haven’t seen before (I have used cmake 3.2.3 before, now I installed cmake 3.9.0 from brew). It seems to be related to some new CMake policy related to RPATH:

https://cmake.org/cmake/help/v3.9/policy/CMP0068.html

Have you seen this before? I tried to set the INSTALL_NAME_DIR explicitly in the RPATH part (see starred ** rows below) of /libspimage/CMakeLists.txt, but no luck so far.

Any idea how to solve it?

Cheers,
Jonas

# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)

IF(APPLE)
  # There's a problem with install_name_tool which cannot
  # handle duplicate rpaths, so we'll take the calculated risk
  # of not including rpaths in the build on macosx
  SET(CMAKE_SKIP_BUILD_RPATH  TRUE)
  **SET(INSTALL_NAME_DIR  "")**
ELSE(APPLE)
  SET(CMAKE_SKIP_BUILD_RPATH  FALSE)
ENDIF(APPLE)

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

# the RPATH to be used when installing, but only if it's not a system directory
LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/lib${LIBRARY_SUFFIX}" isSystemDir)
IF("${isSystemDir}" STREQUAL "-1")
  SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib${LIBRARY_SUFFIX}")
  **SET(CMAKE_INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib${LIBRARY_SUFFIX}")**
ENDIF("${isSystemDir}" STREQUAL "-1")

When pressing g in ccmake:

CMake Warning (dev):
   Policy CMP0068 is not set: RPATH settings on macOS do not affect
   install_name.  Run "cmake --help-policy CMP0068" for policy details.  Use
   the cmake_policy command to set the policy and suppress this warning.

   For compatibility with older versions of CMake, the install_name fields for
   the following targets are still affected by RPATH settings:

    _spimage_pybackend
    spimage

 This warning is for project developers.  Use -Wno-dev to suppress it.

When compiling library with make:

src/CMakeFiles/_spimage_pybackend.dir/flags.make:10: *** multiple target patterns. Stop.
make[1]: *** [src/CMakeFiles/_spimage_pybackend.dir/all] Error 2
make: *** [all] Error 2

Throws following error in tests or when starting phasing with CUDA support:

CUDA error: "Invalid Device function" at phasing.cu:90

Fix: Set CUDA_NVCC_FLAGS in advanced cmake compilation options to -arch=sm_11 (or the computing capability version that the card supports).

It would be nicer if that was done automatically.

Problematic is also that low computing capability won't be supported for much longer by Thrust and CUDA...

When using python wrappers built on a system with a statically linked python interpreter (no dynamically linked libpython) you get the following error (reported by Benedikt):

python -c "import _spimage_pybackend.so"
Fatal Python error: PyThreadState_Get: no current thread

Abort trap: 6

likely due to symbols duplication.

Another example is described here in detail: https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/057P4uNWyCU

The (ugly) solution seems to be to avoid linking the module to libpython and tell the linker to ignore undefined symbols (-undefined dynamic_lookup).

Hi Filipe,

I found that choosing positivity constraint for a complex object forces the object to have positive real and imaginary parts. Is that how it is supposed to be?
We were assuming that positivity constraint only means that the real part is forced to be positive.

We were thinking about implementing a more general way of constraining the phase shift of the object. Filipe, what do you think?

I refer to the following two parts in the code:

phasing.c: phaser_apply_constraints(...)
}else if(constraints & SpPositiveComplexObject){
if(sp_real(new_model->image->data[i]) < 0){
if(constraints & SpPositivityFlipping){
sp_real(new_model->image->data[i]) = fabs(sp_real(new_model->image->data[i]));
}else{
sp_real(new_model->image->data[i]) = 0;
}
}
if(sp_imag(new_model->image->data[i]) < 0){
if(constraints & SpPositivityFlipping){
sp_imag(new_model->image->data[i]) = fabs(sp_imag(new_model->image->data[i]));
}else{
sp_imag(new_model->image->data[i]) = 0;
}
}

2. phasing_kernels.cu
   }else if(constraints & SpPositiveComplexObject){
   if(g[i].x < 0){
   if(constraints & SpPositivityFlipping){
   g[i].x = fabs(g[i].x);
   }else{
   g[i].x = 0;
   }
   }
   if(g[i].y < 0){
   if(constraints & SpPositivityFlipping){
   g[i].y = fabs(g[i].y);
   }else{
   g[i].y = 0;
   }
   }
   }

When using CUDA on Mac OSX (10.9.5) through libspimage, I get the following error:

dyld: Library not loaded: @rpath/libcudart.6.5.dylib
Referenced from: /usr/local/lib64/libspimage.1.dylib
Reason: image not found
./run_hawk: line 36: 16221 Trace/BPT trap: 5 uwrapc

This is solved by adding /usr/local/cuda/lib to the DYLD_LIBRARY_PATH, but it would be nicer if this was automatically taken care of by the cmake files in libspimage.

Currently, the reconstructor module can only handle 2D intensity images, it should be straightforward to extend it to also handle a 3D intensity model.

image_to_png always returns the "Usage: ..." text in the static build. This is not the case for the version from the master branch.

This is a low-priority fix, but on default libspimage installs to:

/usr/local/lib64/

which is found by ccmake when configuring Hawk, but once uwrapc runs the following error occurs:

$ uwrapc
dyld: Library not loaded: /usr/local/lib/libspimage.1.dylib
Referenced from: /usr/local/bin/uwrapc
Reason: image not found
Trace/BPT trap: 5

This can probably be fixed by setting DYLD_LIBRARY_PATH / LD_LIBRARY_PATH, but it would be nicer in the long run if this is fixed automatically during ccmake configuration/compilation

Diagnostics:

$ otool -L /usr/local/bin/uwrapc
/usr/local/bin/uwrapc:
/usr/local/lib/libspimage.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libhdf5.8.dylib (compatibility version 9.0.0, current version 9.2.0)
/usr/local/lib/libtiff.5.dylib (compatibility version 8.0.0, current version 8.0.0)
/usr/local/lib/libjpeg.8.dylib (compatibility version 13.0.0, current version 13.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/usr/local/lib/libpng16.16.dylib (compatibility version 30.0.0, current version 30.0.0)

The order of center coordinates is not in line with the order how image matrices are built (x=fastest changing dimension). This is confusing.

image_util.c:
res->detector->image_center[0] = (x-1)/2.0;
res->detector->image_center[1] = (y-1)/2.0;
res->detector->image_center[2] = (z-1)/2.0;

Make sure to warn when loading PNGs with color and properly handle floating point or non 8 bit pngs.