Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

clesperanto kernel convertion effort #16 #17

Open
StRigaud opened this issue Dec 8, 2021 · 7 comments
Open

clesperanto kernel convertion effort #16 #17

StRigaud opened this issue Dec 8, 2021 · 7 comments
Assignees
@StRigaud @haesleinhuepf
Labels
enhancement New feature or request

Comments

@StRigaud
Copy link
Member

StRigaud commented Dec 8, 2021 •
edited
Loading

Related to #16
Checked one are either under process or finished.
Once processed remove _xd and _x
@StRigaud StRigaud added the enhancement New feature or request label Dec 8, 2021
@StRigaud
Copy link
Member Author

StRigaud commented Feb 2, 2022

@haesleinhuepf Can you remove the kernels that cannot be nd form that list and kernel which are not relevant for now.
thanks!

@haesleinhuepf
Copy link
Member

haesleinhuepf commented Feb 11, 2022 •
edited by StRigaud
Loading

Hi @StRigaud ,

I just updated the list in your post above. I'm keeping two sub-lists here. The first should be done, but those are no filters, those are matrix operations and fancy stuff. The entries in the second list may be dropped:

Special but cool to have (no real 2D/3D filters)

  • generate_binary_overlap_matrix_2d_x.cl
  • generate_binary_overlap_matrix_3d_x.cl
  • generate_distance_matrix_x.cl
  • generate_touch_matrix_2d_x.cl
  • generate_touch_matrix_3d_x.cl
  • average_distance_of_n_far_off_distances_x.cl
  • average_distance_of_n_shortest_distances_x.cl
  • average_distance_of_touching_neighbors_x.cl
  • distance_matrix_to_mesh_x.cl
  • maximum_of_touching_neighbors_x.cl
  • mean_of_touching_neighbors_x.cl
  • median_of_touching_neighbors_x.cl
  • minimum_of_touching_neighbors_x.cl
  • n_shortest_distances_x.cl
  • n_shortest_points_x.cl

Potentially to drop entirely

  • maximum_z_projection_bounded_3d_2d_x.cl
  • maximum_slice_by_slice_sphere_3d_x.cl
  • mean_slice_by_slice_sphere_3d_x.cl
  • mean_z_projection_bounded_3d_2d_x.cl
  • median_slice_by_slice_box_3d_x.cl
  • median_slice_by_slice_sphere_3d_x.cl
  • minimum_distance_of_touching_neighbors_x.cl
  • minimum_slice_by_slice_sphere_3d_x.cl
  • minimum_z_projection_bounded_3d_2d_x.cl
  • minimum_z_projection_thresholded_bounded_3d_2d_x.cl
  • pointindexlist_to_mesh_3d_x.cl
  • standard_deviation_of_touching_neighbors_x.cl
  • touch_matrix_to_mesh_3d_x.cl
  • depth_projection_interpolation_x.cl
  • depth_projection_x.cl
  • distancemap_localPositiveMinimum_box_2d_x.cl
  • distancemap_localPositiveMinimum_box_3d_x.cl
  • distancemap_localPositiveMinimum_diamond_2d_x.cl
  • distancemap_localPositiveMinimum_diamond_3d_x.cl
  • exclude_labels_on_surface_2d_x.cl
  • exclude_labels_on_surface_3d_x.cl
  • exclude_labels_sub_surface_2d_x.cl
  • exclude_labels_sub_surface_3d_x.cl
  • piv.cl
  • watershed_binarize_labelmap_2d_x.cl
  • watershed_binarize_labelmap_3d_x.cl
  • watershed_detect_maxima_region_box_2d.cl
  • watershed_detect_maxima_region_box_3d.cl
  • watershed_eliminate_wrong_maxima_2d_x.cl
  • watershed_eliminate_wrong_maxima_3d_x.cl
  • watershed_local_maximum_2d_x.cl
  • watershed_local_maximum_3d_x.cl

@StRigaud
Copy link
Member Author

Question on kernel to be dropped

slice_by_slice kernels:
cons: They are redundant with classic operation applied at dimension n-1 in a loop so can be dropped
pros: They avoid host code from user and speed up some development
are they useful or not?

watershed:
is it because the algorithm is not optimized?
is there a way to make it relevant to keep in GPU?

@haesleinhuepf
Copy link
Member

watershed:
is it because the algorithm is not optimized?
is there a way to make it relevant to keep in GPU?

It doesn't work well. See here:

slice_by_slice kernels:
cons: They are redundant with classic operation applied at dimension n-1 in a loop so can be dropped
pros: They avoid host code from user and speed up some development
are they useful or not?

I think we can have the same functionality, e.g. by setting sigma_z=0, e.g. in the Gaussian blur. Plus, this would also work with X and Y, without having to maintain extra kernels

@StRigaud
Copy link
Member Author

I think we can have the same functionality, e.g. by setting sigma_z=0, e.g. in the Gaussian blur. Plus, this would also work with X and Y, without having to maintain extra kernels

indeed, though i will need to update kernels already pushed. ToDo later then 😄

@StRigaud
Copy link
Member Author

Continuing on the slice_by_slice kernels:

  • do we plan on keeping the other slice_by_slice kernel in the top list (e.g. count_nonzero_pixels_slice_by_slice_sphere_3d_x.cl)?
  • do we plan on keeping the one I have already updated (e.g. erode_box, dilate_box, detect_maxima, etc.) or do we want the same behaviour (3d data but z=0 mean slice_by_slice process)?

@StRigaud
Copy link
Member Author

From top post list

Raising the interest of keep the following kernels:

  • maximum_projection_3d_2d_x.cl ➡️ same as maximum_z_projection
  • minimum_projection_3d_2d_x.cl ➡️ same as minimum_z_projection

Raising interest of keeping, or renaming and extend to all axis (x,y,z) the following kernels:

  • mask_stack_with_plane_3d_x.cl ➡️ mask volume with binary plane along depth axis
  • multiply_stack_with_plane_3d_x.cl ➡️ multiply volume with plane along depth axis
  • multiply_stack_with_scalars_x.cl ➡️ multiply volume with vector along depth axis
  • maximum_of_masked_pixels_3d_2d_x.cl ➡️ masked max projection along depth axis
  • minimum_of_masked_pixels_3d_2d_x.cl ➡️ masked min projection along depth
  • count_non_zero_projection_3d_2d_x.cl ➡️ same as other (min,max,sum,etc.) projection kernel

❓ kernels:

  • excludeLabelsOnEdges_3d_x.cl ➡️ contains multiple kernel inside, should maybe split them?

There are other kernels left in the list, a quick discussion about them could be nice to see how to extend them to clEsperanto standards.

@StRigaud StRigaud mentioned this issue Nov 28, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@StRigaud StRigaud

@haesleinhuepf haesleinhuepf

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@StRigaud @haesleinhuepf