You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some proposed changes to DICOM.jl that I wanted to ask for comments from people more familiar with the format and with GitHub/Julia development. Since I'm still learning, please let me know any better ways to communicate about issues or organize changes.
should we change current read/write functions to load/save that are compatible with FileIO and import that and enter dcm into their registry? Any cons or comments?
I would like to create separate types for the DICOM header and image, so that they could have separate display routines (namely, display the image as an image instead of an array and display header as a list). Would this cause any problems?
Another side benefit is that we might be able to get rid of the double indexing mentioned in fix Arrays for 0.5 #14 since (as far as I know) the pixeldata for the image is the only DcmElt data that really needs to be stored in an Array{Any}.
I want to improve the documentation both in the code and in the repo. I have been making all my notes about what I've learned about DICOM in a Jupyter notebook and would be happy to put a cleaned up version here, but would it be better to update on the README.md? Do we need separate docs for users and developers? I am just learning some of the Julia documentation mechanisms and love how you can access it from the REPL. Is it overkill to use the Documenter.jl makedocs system for such a small project?
Thanks for comments.
The text was updated successfully, but these errors were encountered:
I have some proposed changes to DICOM.jl that I wanted to ask for comments from people more familiar with the format and with GitHub/Julia development. Since I'm still learning, please let me know any better ways to communicate about issues or organize changes.
should we change current
read/write
functions toload/save
that are compatible withFileIO
and import that and enterdcm
into their registry? Any cons or comments?I would like to create separate types for the DICOM header and image, so that they could have separate display routines (namely, display the image as an image instead of an array and display header as a list). Would this cause any problems?
Another side benefit is that we might be able to get rid of the double indexing mentioned in fix Arrays for 0.5 #14 since (as far as I know) the pixeldata for the image is the only DcmElt data that really needs to be stored in an Array{Any}.
I want to improve the documentation both in the code and in the repo. I have been making all my notes about what I've learned about DICOM in a Jupyter notebook and would be happy to put a cleaned up version here, but would it be better to update on the README.md? Do we need separate docs for users and developers? I am just learning some of the Julia documentation mechanisms and love how you can access it from the REPL. Is it overkill to use the Documenter.jl makedocs system for such a small project?
Thanks for comments.
The text was updated successfully, but these errors were encountered: