-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
comparing thickness algorithms #1
Comments
@slmanske: Sarah, what is the IPL version you used to calculate the thicknesses for this notebook? Is thickness calculated using the algorithms for XCT1 or XCT2? Thanks!!! @njneeteson and @mkuczyns: Let me know if you want me to create more shapes, happy to do it! |
@sbonaretti: Thanks for your work on this so far! I finished generating a few thousand images yesterday and created the IPL batch scripts last night so I will plan to run those along with the Python scripts today. I generated hollow and filled spheres/cylinders with varying radii and lengths ranging from 1 voxel thick to 50 voxels thick (or about 3 mm) and square plates of varying thickness and length. I also generated a copy of each image without padding on the Z-axis. I spoke with Sarah yesterday and we will run the IPL thickness function as follows for each shape:
For each of these cases, we will test a Once we parse through the log files in Python, we can generate some tables and plots to compare between functions and between IPL and Python. |
@sbonaretti: A few other details. We're using IPL v5.42 (we should document this somewhere). I don't think any point to testing XCT1 (IMHO) - this used a different function (dt_mat_param to calculate TbN), and didn't measure TbTh directly. |
Recent paper on a related topic, quite insightful - https://pubmed.ncbi.nlm.nih.gov/36659857/ |
Thanks @soupault! Yes, let's keep an eye on the literature as well! Got an idea to share: What if each of us implements one thickness measurement algo, and then we compare the algorithms using both synthetic and actual data? It would not be a challenge, but a comparison of existing (and new?) algorithms. None of us would need to show that their algorithm is the best, it would just be a fair comparison. And maybe while doing this, we will find some reliable methods that we can confidently use in our research. Eventually, we could write a collective paper, and make the code open, with all the use cases, etc. What do you all think? Would it make sense? Would it be helpful? |
Another thread from ITK to keep an eye on: InsightSoftwareConsortium/itk_cucim#13 (comment) |
@ALL please review this parabolic morphology distance map PR: InsightSoftwareConsortium/ITKParabolicMorphology#43 |
Hey @njneeteson @mkuczyns @slmanske @thewtex @ajburghardt,
Here is the notebook with the various shapes that I showed in the meeting yesterday.
Previous relevant GitHub conversations:
@soupault, @Besler, @dzenanz: please, join the conversation!
The text was updated successfully, but these errors were encountered: