ufo-kit / ufo-filters Goto Github PK
View Code? Open in Web Editor NEWCommon plugin suite for the ufo-core processing framework
License: GNU Lesser General Public License v3.0
Common plugin suite for the ufo-core processing framework
License: GNU Lesser General Public License v3.0
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).
Currently, width
and height
are not used. @rshkarin can we get rid of them or will we need them?
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
.
There are too many test suites scattered around.
This usually causes weird errors.
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.
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];
?
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.
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.
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.
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?
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.
If reading only a single raw file, the process breaks with an assertion.
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.
for qp, qp2 and ctf. I can provide the data to @rshkarin to check.
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
ufo-launch read path=projections/ ! which filter??__parameter ? window size??_ ! write ...
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:
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.window
property with which the filter is multiplied, i.e. hamm
, butterworth
, faris-byer
.dims
property to choose between one- and two-dimensional filters. Again to ease transition, one-dimensional should be the default.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?
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.
@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
?
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
Right now, it's quite a mess with the naming and naming scheme ...
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.
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.
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).
Most importantly use of the different sub-loaders is not specified.
Tracing the execution using the filter
plugin causes segfaults when writing the OpenCL profile.
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 »)
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.
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.
Currently, it will say, that it cannot open the file to be written. That is technically correct, but not very convenient.
@rshkarin: is this intentional?
If more than one GPU is used, the reconstructed slices might be corrupted.
It is.
Right now stack combines a single data stream however there are use cases to stack multiple streams and produce items on-the-fly.
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
For example
sudo touch foo.tif
ufo-launch dummy-data ! write filename=foo.tif
should fail gracefully.
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?
Only the first image in every multi-paged tif file is read.
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
Hi @GGoek ,
I tried to use DFI, but it seems that a part of code is missed.
Please:
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
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.
~/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
Right now, the phase retrieval multi GPU parallelization probably does not work correctly because a single command queue is stored during initialization.
I think that this is good idea to provide some exapmles of filter chains in help or wiki.
For ex. FBP, DFI and others.
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?
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.
Width, height and position are documented, from-center is missing.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.