ufo-kit / ufo-filters Goto Github PK

View Code? Open in Web Editor NEW

10.0 10.0 14.0 8.71 MB

Common plugin suite for the ufo-core processing framework

License: GNU Lesser General Public License v3.0

CMake 2.05% C 95.69% Python 0.88% Meson 0.72% Shell 0.30% C++ 0.37%

ufo-filters's People

Contributors

Stargazers

Watchers

Forkers

rshkarin apprisi chuan137 evoliptic kevinkit ggoek dominicwindisch raphaelpour raghavaro mitya57 ldorofeeva rmaciver dannytran1904 harishkumar-harihara

ufo-filters's Issues

How to provide both C and OpenCL filter implementations

I would like to implement a filter on a GPU (namely transpose) but there already is a C implementation. I thought I could make the C vs. OpenCL a property but there is this UFO_TASK_MODE_GPU which I see by many OpenCL-based filters. Does that just mean that the filter won't be executed on OpenCL CPU devices? If so I just don't use the flag and I should be good to go. Anyway, can @matze tell me what are the "best practices" here?

Sure, one can say that if the filter can run on any device I could just implement it only in OpenCL because it can run on CPU as well but there is the unnecessary host <-> device transfer overhead (let's say I have read -> transpose -> write pipeline, then I would of course use the pure C version, otherwise I would need to transfer "up" and "down" again, and if we say that the transpose is almost as fast as data copying it is pretty pointless to do it by OpenCL CPU device). If I remember correctly we could "map" the buffer or use CL_MEM_USE_HOST_PTR and then we don't need to transfer back and forth, but I don't know if the framework supports that already.

It would be maybe interesting for optimization of the graph execution to have only one task but a property or something which the user can use to make their graph efficient. This property could be available to the scheduler as well and it could even optimize the graph for the user automatically (minimize data copying).

Initialize lamino filter properties with default values

Phase retrieval unused parameters

Currently, width and height are not used. @rshkarin can we get rid of them or will we need them?

Unify flat corrections

Currently there is one for projections and one for sinograms, they are almost perfect duplicates, except the sinogram one takes 1D darks and flats and has absorption correction and the one for projections can take care of NANs (and that if I had a proper look takes place only in the CPU version, so it is actually obsolete after 4abb3cf).
So how about we merge them to one with absorption correction and without the nan stuff? Or we can leave out also the absorption, because, strictly speaking it has nothing to do with ffc, but on the other hand it is very handy to just set foo.props.absorptivity = True.

Merge ufo-tests into ufo-filters

There are too many test suites scattered around.

Some tasks recreate kernels/programs across scheduler runs

This usually causes weird errors.

Do not force CPU in slice filter

currently slice filter force data copied back to host memory with CPU, which could be a performance breaker. Improve the slice filter, keep data where it is if already on GPU.

ifft

usually, I would expect a factor like 1/volume in the formula of Fourier Transform.

    scale = 1.0f / ((gfloat) requisition->dims[0]);  
    if (priv->fft_dimensions == FFT_2D) { 
        scale /= (gfloat) requisition->dims[0];
    }

it might be scale /= (gfloat) requisition->dims[1]; ?

Output multiple maps in map-slice task

At the moment, the map-slice task outputs only a single map from a stream of input images. This should be generalized so that multiple maps are produced. This should also avoid the warning about input data being more than expected.

Frames lost after slice filter

Frames lost after slice filter.

Command:

ufo-launch read path='res/HT2.tif' ! stack number=2 ! monitor ! slice ! monitor ! null

Output

monitor: dims=[512 512 2] keys=[] location=host
monitor: dims=[512 512 2] keys=[] location=host
monitor: dims=[512 512 2] keys=[] location=host
monitor: dims=[512 512] keys=[] location=host
monitor: dims=[512 512] keys=[] location=host

In this example, 6 frames are expected after slice, but only 2 is streamed.

Cleanup src/ directory

At the moment it is quite a mess. We should at least put kernels in a respective kernel directory. Integrated third-party dependencies could go into a deps/ directory.

How to get GPU name in a task?

I optimized the back projection kernel in #119 but I forgot that to actually get the speedup I need to set the work group size myself. I guess the correct way is to implement CL_DEVICE_NAME inside ufo_gpu_node_get_info, right?

Merge FFT and IFFT

There is a lot of code duplication which could probably be reduced by merging both filters into a single FFT filter with an additional inverse flag.

raw cannot read single files

If reading only a single raw file, the process breaks with an assertion.

2D FFT doesn't work

With

ufo-launch read path="fc/*" end=1 ! fft dimensions=2 ! ifft dimensions=2 ! write filename=foo-%04i.tif

my foo file is just NaNs.
@rshkarin I guess this is why the phase retrieveal doesn't work either.

Phase retrieval gives odd results

for qp, qp2 and ctf. I can provide the data to @rshkarin to check.

Please make oclfft optional

Hello,

now that ufo-core was uploaded into Debian, I am preparing the filters part :).
I prefer to remove the oclfft code in oder to upload ufo-filters.
so I will repack by removing the oclfft directory.

this imply that the deps/CMakefileTxt should not fail when oclfft directory is missing.
could you add an option in order to compile with oclfft which should be ON or OFF as you convenience.

thanks

Fred

How to apply the median filter to a set of images?

ufo-launch read path=projections/ ! which filter??__parameter ? window size??_ ! write ...

Generalizing and unifying frequency filters

Rationale

Up to now, the filter task is mainly used for filtered backprojection, i.e. a one-dimensional, ramp-like filter in the Fourier domain. However, filtering has general purposes besides that and might be generalized in several directions:

We cannot model non-ramp-like filters such as low- and high-pass filters.
We are currently restricted to 1D filtering, however, two-dimensional passband filters are obviously pretty useful on images as well.
Windowing is conflated with the filter type.

Suggestions

Introduce a type property specifying what kind of filter we have, i.e. ramp, lowpass, highpass, to ease transition this will be shared with the old filter property and ramp will still be the default.
Introduce a window property with which the filter is multiplied, i.e. hamm, butterworth, faris-byer.
Introduce a dims property to choose between one- and two-dimensional filters. Again to ease transition, one-dimensional should be the default.
Maybe, remove the blur task and replace that with a gaussian as a filter type. On the other hand blur is implemented as a Gaussian kernel convolution and might be useful for certain applications.

@tfarago: what do you think?

How to do fft in the vertical direction?

Hi there,
I had a look at the properties and didn't find anything for this. I want to do a 1D fft on 2D image but in the vertical direction, i.e. the opposite from what we do by backprojection filtering.

DFI filter cannot use arbitrary angle steps

@rshkarin: Do I miss something or does the DFI filter always assume the angle step theta between successive projections to be number_of_projections / 2?

head does not compile on i386 machine

Hello, I am trying to compile ufo-filters on an i386 computer, but I get this error message.

[ 89%] Building C object src/CMakeFiles/ufofiltertranspose.dir/ufo-transpose-task.c.o
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c: In function ‘transpose_sse’:
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:84:5: error: unknown type name ‘__m128’
     __m128 row1 = _mm_loadu_ps (src);
     ^
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:84:5: warning: implicit declaration of function ‘_mm_loadu_ps’ [-Wimplicit-function-declaration]
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:84:5: warning: nested extern declaration of ‘_mm_loadu_ps’ [-Wnested-externs]
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:85:5: error: unknown type name ‘__m128’
     __m128 row2 = _mm_loadu_ps (src + height);
     ^
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:86:5: error: unknown type name ‘__m128’
     __m128 row3 = _mm_loadu_ps (src + 2 * height);
     ^
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:87:5: error: unknown type name ‘__m128’
     __m128 row4 = _mm_loadu_ps (src + 3 * height);
     ^
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:88:5: warning: implicit declaration of function ‘_MM_TRANSPOSE4_PS’ [-Wimplicit-function-declaration]
     _MM_TRANSPOSE4_PS (row1, row2, row3, row4);
     ^
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:88:5: warning: nested extern declaration of ‘_MM_TRANSPOSE4_PS’ [-Wnested-externs]
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:89:5: warning: implicit declaration of function ‘_mm_storeu_ps’ [-Wimplicit-function-declaration]
     _mm_storeu_ps (dst, row1);
     ^
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:89:5: warning: nested extern declaration of ‘_mm_storeu_ps’ [-Wnested-externs]
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c: In function ‘ufo_transpose_task_process’:
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:106:10: warning: unused variable ‘fast_height’ [-Wunused-variable]
     gint fast_height = height - height % 4;
          ^
/home/picca/Projets/ufo-filters/src/ufo-transpose-task.c:105:10: warning: unused variable ‘fast_width’ [-Wunused-variable]
     gint fast_width = width - width % 4;
          ^
src/CMakeFiles/ufofiltertranspose.dir/build.make:77: recipe for target 'src/CMakeFiles/ufofiltertranspose.dir/ufo-transpose-task.c.o' failed
make[2]: *** [src/CMakeFiles/ufofiltertranspose.dir/ufo-transpose-task.c.o] Error 1
CMakeFiles/Makefile2:2312: recipe for target 'src/CMakeFiles/ufofiltertranspose.dir/all' failed
make[1]: *** [src/CMakeFiles/ufofiltertranspose.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2

Classify and unify property names

Right now, it's quite a mess with the naming and naming scheme ...

FFT Varying input size

When a Generator connected to the fft/ifft plug-in creates inputs of varying size,
the fft returns strange outputs.
This might be due to the fact that the scheduler does not change the requisition size of the new buffer, or that the fft plug-in does not check the size of the buffer at each processing.

Split off loop functionality from buffer

A new loop buffer with a count parameter should help to allow keeping data on one location or another and simplify the code of the current Buffer task.

Reader filter ROI does not work

When I set my reader

reader = get_task('reader', path=base_dir + 'sinos/', region_of_interest=True, x=0, y=0, width=1296, height=1)

I get segmentation fault (tried with tiff images).

Reader documentation is out-of-date

Most importantly use of the different sub-loaders is not specified.

filter: tracing segfaults

Tracing the execution using the filter plugin causes segfaults when writing the OpenCL profile.

Debian warning during build

Hello, I will put here the warning obersev during the buildof ufo-filters

/home/picca/Debian/ufo-filters/ufo-filters/src/ufo-fftmult-task.c: In function ‘get_max_work_group_size’:
/home/picca/Debian/ufo-filters/ufo-filters/src/ufo-fftmult-task.c:108:23: warning: large integer implicitly truncated to unsigned type [-Woverflow]
     *x_worker_count = ULLONG_MAX;
                       ^~~~~~~~~~
[ 78%] Linking C shared library libufofilterfftmult.so


/home/picca/Debian/ufo-filters/ufo-filters/src/ufo-lamino-backproject-task.c: In function ‘ufo_lamino_backproject_task_setup’:
/home/picca/Debian/ufo-filters/ufo-filters/src/ufo-lamino-backproject-task.c:202:27: warning: ‘kernel_filename’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     priv->scalar_kernel = ufo_resources_get_kernel (resources, kernel_filename, "backproject_burst_1", error);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It seems that you forgot to link against m ;)

dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterremovecircle.so contient une référence au symbole sqrtf qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterfilterstripes1d.so contient une référence au symbole exp qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofiltervolumerender.so contient une référence au symbole sincos qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofiltercutsinogram.so contient une référence au symbole roundf qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterfilter.so contient une référence au symbole cos qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 12 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofiltercontrast.so contient une référence au symbole sqrt qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 2 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterfilterparticle.so contient une référence au symbole round qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 2 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterblur.so contient une référence au symbole exp qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterzeropad.so contient une référence au symbole pow qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 2 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterdenoise.so contient une référence au symbole sqrtf qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterfftmult.so contient une référence au symbole sqrtf qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofiltermapslice.so contient une référence au symbole ceil qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 1 autre avertissement semblable a été sauté (utiliser -v pour les voir tous)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofiltergetdupcirc.so contient une référence au symbole sqrtf qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterdumpring.so contient une référence au symbole roundf qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 2 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterlaminobackproject.so contient une référence au symbole ceil qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 6 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterpolarcoordinates.so contient une référence au symbole sqrt qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 2 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterbackproject.so contient une référence au symbole sin qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 1 autre avertissement semblable a été sauté (utiliser -v pour les voir tous)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterdfisinc.so contient une référence au symbole cos qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: 2 autres avertissements semblables ont été sautés (utiliser -v pour les voir tous).
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterringpattern.so contient une référence au symbole sqrt qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)
dpkg-shlibdeps: avertissement: debian/ufo-filters/usr/lib/i386-linux-gnu/ufo/libufofilterringwriter.so contient une référence au symbole roundf qui ne peut être résolue : il peut s'agir d'un greffon (« plugin »)

Real space RAMLAK

Computing the filter directly in the fourier space is much more efficient but causes aliasing in the reconstruction as described here. It would be nice to support the filter computation in the real space, for this we would need to transform the coefficients. From what I have seen in the phase retrieval the FFT is handled directly in the filter. I was thinking that this probably isn't the last time we will need to do FFTs internally so maybe some convenience functions would come in handy. Another option is to implement a separate task and connect it to IFFT and then the rest of the reco pipeline but that means ifs and elses in scripts and further code which I don't like too much.

Since I am digging into this I would also like to add some mollification to the filtering (we could suppress the high-frequencies in the RAMLAK) and there one could have also choices from different mollifiers.

Last, we could even support arbitrary coefficients, like:

fltr = pm.get_task('filter')
# New fancy coefficients
fltr.props.coeffs = np.ones(n, dtype=np.float32)

But then again, that's not so elegant to hook up with what's in tofu already. What do you think @matze?

An example shows a slice of a reconstructed cylinder filtered by computing the filter in real space and taking the FFT (red) vs. filtering with computed Fourier coefficients directly (blue).

You see there is a global offset and the blue curve is somehow bent. The ground truth is set to be one, so the real filtering comes closer.

Integrate oclfft directly into FFT filters

It is quite a painful step to first install/compile oclfft from ufo.kit.edu just to use these filters. Moreover, the library is, as far as I know, not used by any other of our projects.

Licenses are compatible, so we can integrate the Apple FFT directly into our source tree.

Writer should mkdir directory if it does not exist

Currently, it will say, that it cannot open the file to be written. That is technically correct, but not very convenient.

Cannot set axis on DFI filter

@rshkarin: is this intentional?

DFI: multi-GPU breaks reconstruction

If more than one GPU is used, the reconstructed slices might be corrupted.

dummy-data: init documentation is missing

It is.

Let stack take multiple inputs

Right now stack combines a single data stream however there are use cases to stack multiple streams and produce items on-the-fly.

the make test target doen not work

Hello, I can compile ufo-filters now, but when I try to run the test target there is an error.

Scanning dependencies of target test
python: can't open file '/home/picca/Projets/ufo-filters/src/../run_tests.py': [Errno 2] No such file or directory
src/CMakeFiles/test.dir/build.make:49: recipe for target 'src/CMakeFiles/test' failed

Cheers

writing to a file with wrong permissions fails badly

For example

sudo touch foo.tif
ufo-launch dummy-data ! write filename=foo.tif

should fail gracefully.

Can't build with HDF5

Cmake seems happy:

-- The C compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Found OpenCL: /usr/lib/libOpenCL.so 
-- checking for module 'ufo>=0.6'
--   found ufo, version 0.8.0
-- The CXX compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found TIFF: /usr/lib/x86_64-linux-gnu/libtiff.so 
-- Could NOT find CLFFT (missing:  CLFFT_LIBRARIES CLFFT_INCLUDE_DIRS) 
-- Found HDF5: /usr/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libm.so 
-- checking for module 'libuca>=1.2'
--   found libuca, version 1.4.0
-- checking for module 'opencv'
--   package 'opencv' not found
-- checking for module 'libtiff-4>=4.0.0'
--   package 'libtiff-4>=4.0.0' not found
-- checking for module 'gsl'
--   package 'gsl' not found
-- checking for module 'ufoir>=0.1'
--   package 'ufoir>=0.1' not found
-- Configuring done
-- Generating done
-- Build files have been written to: /home/farago/dev/ufo-filters/build

but make not so much:

Scanning dependencies of target ufofilterread
[ 68%] Building C object src/CMakeFiles/ufofilterread.dir/ufo-priv.c.o
[ 69%] Building C object src/CMakeFiles/ufofilterread.dir/ufo-read-task.c.o
[ 69%] Building C object src/CMakeFiles/ufofilterread.dir/readers/ufo-reader.c.o
[ 70%] Building C object src/CMakeFiles/ufofilterread.dir/readers/ufo-edf-reader.c.o
[ 71%] Building C object src/CMakeFiles/ufofilterread.dir/readers/ufo-tiff-reader.c.o
[ 72%] Building C object src/CMakeFiles/ufofilterread.dir/readers/ufo-hdf5-reader.c.o
/home/farago/dev/ufo-filters/src/readers/ufo-hdf5-reader.c: In function ‘ufo_hdf5_reader_open’:
/home/farago/dev/ufo-filters/src/readers/ufo-hdf5-reader.c:61:5: error: too many arguments to function ‘H5Dopen1’
/usr/include/H5Dpublic.h:145:14: note: declared here
make[2]: *** [src/CMakeFiles/ufofilterread.dir/readers/ufo-hdf5-reader.c.o] Error 1
make[1]: *** [src/CMakeFiles/ufofilterread.dir/all] Error 2
make: *** [all] Error 2

Which exact version of libhdf5 do I need please?

Multi-paged tif reading doesn't work

Only the first image in every multi-paged tif file is read.

libhdf5-openmpi-1.8.4 crashes the hdf5 writer compilation

On Ubuntu 12.04, the cmake recognizes it as a valid option, hence the HDF5 support is enabled but then the build fails.

[ 70%] Building C object src/CMakeFiles/ufofilterread.dir/readers/ufo-hdf5-reader.c.o
In file included from /usr/include/hdf5.h:24,
                 from /mnt/LSDF/anka-nc-cluster/all_users/sharedPrograms/ufo/git/ufo-filters/src/common/hdf5.h:11,
                 from /mnt/LSDF/anka-nc-cluster/all_users/sharedPrograms/ufo/git/ufo-filters/src/readers/ufo-hdf5-reader.c:20:
/usr/include/H5public.h:57: fatal error: mpi.h: No such file or directory
compilation terminated.
make[2]: *** [src/CMakeFiles/ufofilterread.dir/readers/ufo-hdf5-reader.c.o] Error 1
make[1]: *** [src/CMakeFiles/ufofilterread.dir/all] Error 2
make: *** [all] Error 2

DFI Kernel: lack of variables

Hi @GGoek ,

I tried to use DFI, but it seems that a part of code is missed.
Please:

Change raster_size2, raster_size_2 to raster_size_half
Add the part with declaration and calculation of out_idx_mirror, y_offset

median filter - two problems

ufo-query -p medianfilter
Error: ufo_medianfilter_task_new is not exported by module libufofiltermedianfilter.so: `ufo_medianfilter_task_new': /usr/lib/ufo/libufofiltermedianfilter.so: undefined symbol: ufo_medianfilter_task_new
ufo-launch read path="ADU/CT2_Abs_*.tif" ! medianfilter ! write filename=ProjAbsMedF/CT2_Abs_Proj_%04i.tif
Error parsing pipeline: ufo_medianfilter_task_new is not exported by module libufofiltermedianfilter.so: `ufo_medianfilter_task_new': /usr/lib/ufo/libufofiltermedianfilter.so: undefined symbol: ufo_medianfilter_task_new

Encode filetype metadata into filename?

While using HDF5 now for a while I noticed, we'd have to write a lot of specialty code in order to specify the dataset name. This is cumbersome, so I thought we could encode the dataset name into the filename property itself, i.e. instead of

 ufo-launch foo ! write filename=/tmp/foo.h5 dataset=/bar/baz

we could write the dataset name directly into the filename after a separator

ufo-launch foo ! write filename=/tmp/foo.h5:/bar/baz

That way we could avoid adding special code in GUIs and the like.

Please fix the copyright

~/Debian/ufo-filters/ufo-filters$ licensecheck -r . | grep UNKNOWN
./docs/Makefile: *No copyright* UNKNOWN
./docs/changes.rst: *No copyright* UNKNOWN
./docs/conf.py: *No copyright* UNKNOWN
./docs/copyright.rst: *No copyright* UNKNOWN
./docs/filters.rst: *No copyright* UNKNOWN
./docs/generators.rst: *No copyright* UNKNOWN
./docs/index.rst: *No copyright* UNKNOWN
./docs/install.rst: *No copyright* UNKNOWN
./docs/sinks.rst: *No copyright* UNKNOWN
./src/config.h.in: *No copyright* UNKNOWN
./src/lamino-roi.c: *No copyright* UNKNOWN
./src/lamino-roi.h: *No copyright* UNKNOWN
./src/ufo-priv.c: *No copyright* UNKNOWN
./src/ufo-priv.h: *No copyright* UNKNOWN
./src/ufo-ring-coordinates.h: *No copyright* UNKNOWN
./docs/sphinxgobject/__init__.py: *No copyright* UNKNOWN
./docs/sphinxgobject/domain.py: *No copyright* UNKNOWN

./src/common/hdf5.c: *No copyright* UNKNOWN
./src/common/hdf5.h: *No copyright* UNKNOWN
./src/common/ufo-fft.c: *No copyright* UNKNOWN
./src/common/ufo-fft.h: *No copyright* UNKNOWN

./src/kernels/arithmetics.cl: *No copyright* UNKNOWN
./src/kernels/bin.cl: *No copyright* UNKNOWN
./src/kernels/default.cl: *No copyright* UNKNOWN
./src/kernels/denoise.cl: *No copyright* UNKNOWN
./src/kernels/edge.cl: *No copyright* UNKNOWN
./src/kernels/fftmult.cl: *No copyright* UNKNOWN
./src/kernels/flip.cl: *No copyright* UNKNOWN
./src/kernels/median.cl: *No copyright* UNKNOWN
./src/kernels/ordfilt.cl: *No copyright* UNKNOWN
./src/kernels/piv.cl: *No copyright* UNKNOWN
./src/kernels/rescale.cl: *No copyright* UNKNOWN
./src/kernels/volume.cl: UNKNOWN

./src/kernels/templates/center_template.in: *No copyright* UNKNOWN
./src/kernels/templates/common.in: *No copyright* UNKNOWN
./src/kernels/templates/definitions.in: *No copyright* UNKNOWN
./src/kernels/templates/lamino_template.in: *No copyright* UNKNOWN
./src/kernels/templates/roll_template.in: *No copyright* UNKNOWN
./src/kernels/templates/z_template.in: *No copyright* UNKNOWN
./src/kernels/tools/make_burst_kernels.py: *No copyright* UNKNOWN

Use correct GPU node handling in phase retrieval

Right now, the phase retrieval multi GPU parallelization probably does not work correctly because a single command queue is stored during initialization.

Help improvements

I think that this is good idea to provide some exapmles of filter chains in help or wiki.
For ex. FBP, DFI and others.

Can we add start offset to the reader?

I want to ask before I implement anything because of this excerpt. It seems that it kind of splits the files to be read based on some higher power from the line 182. From what I have seen on my machine total was always one, so no problem. But if that can be more it will cause trouble (I cannot just say priv->current_count = index * partition + offset). Also, the partitioning would be kind of weird if total was more than one and count was not speicified. Can @matze shed some light on this please?

Reading TIFF hyperstack not working

A hyperstack is a 4-dimensional image, i.e. multiple stacks of 2D images. As of now, the TIFF read spits out only the very first frame but in fact should read out all images.

crop: from-center documentation missing

Width, height and position are documented, from-center is missing.

ufo-kit / ufo-filters Goto Github PK

ufo-filters's People

Contributors

Stargazers

Watchers

Forkers

ufo-filters's Issues

Rationale

Suggestions

Recommend Projects

Recommend Topics

Recommend Org

Jobs