search

Image-Py / imagepy

Image process framework based on plugin like imagej, it is esay to glue with scipy.ndimage, scikit-image, opencv, simpleitk, mayavi...and any libraries based on numpy
http://imagepy.org
BSD 4-Clause "Original" or "Old" License
1.29k stars 330 forks source link

Documentation #89

Open CsatiZoltan opened 4 years ago

CsatiZoltan commented 4 years ago

Some information can be found about ImagePy but they are scattered around the main repository, the demo plugin and image.sc. I propose creating a repo just for the documentation (could be hosted on https://github.com/Image-Py/imagepy-doc). I also recommend revising the spelling.

We could also document the input and output parameters of the most important methods, the user may often come across. Combined with a Doxygen documentation (see #63), new users could use ImagePy more efficiently.

yxdragon commented 4 years ago

document is the a problem for a long time. I did not have much time (you known, sometimes document need more energy than coding), and my english is not very good.

I think there are 3 types of document. sorted by importance:

  1. user menual for ImagePy is a bridge from developer to user. In this point, imagepy.doc folder, we can write some markdown file there, with the same structure and name with the plugins folder. Then it would be linked by the help button on parameter dialog. (if no parameter, or a tool, it is linked by right click), but I just put a demo in it now. (In fact I had tried to write a book, just like many imagej's book, and I has wroten many, but give up temporary)

  2. the developer document I think the best way is writting demos. such as the demo plugin. may be some more demos is needed such as how to use ips.data. I think a good framework should be: a science programer can writting plugin easily, and need not know the framework well.

  3. framework api document the doxygen document is a framework api, I am reconstructing ImagePy and split the ui as sciwx. When I comleted, we can rebuilt a doxygen.

In the end, may I invite you to imagepy's organization?

CsatiZoltan commented 4 years ago

Your classification makes sense. I propose the following:

  1. User manual You create the hierarchical document structure. Then we can start writing the documentation.
  2. Developer documentation You know ImagePy the best, so you could write the documentation (as your time allows) and I can revise it. I am not a native English speaker but I think I could catch some spelling mistakes and also notice if something is not clear. During the revision, I can learn both about Python and the working of ImagePy.
  3. API documentation Currently, I have no idea concerning this one.

may I invite you to imagepy's organization?

Yes, please. That would allow me to manage labels, milestones, etc. Since I am a beginner Python programmer, I will work on my own fork and contribute in form of pull requests. That way I cannot mess up the main ImagePy repository and you can edit my changes to conform to your needs.

This issue could be pinned on the main page to catch attention. Also, writing the documentation is a larger task, needing some planning. Hence, a project could be set up for this.