How could we increase the accessibility and diffusion of image processing / analysis infrastructures, especially in terms of software packages? Existing software packages already offer a rich and wide range of tools for processing and analysis of microscope images. They are constantly evolving and the number of new functions is steadily growing. With so many options offered to users, the problem for them is now to choose the best tool that matches their needs. In other words, the accessibility is already excellent, but bridging this accessibility to a specific demand is missing. Moreover, the enhancement and strengthening of a human network that can boost the diffusion of the existing software through collaborations / consultations / teachings is equally important. To overcome the imminent problem that exists as a gap between the availability of software tools and the difficulty of a specific choice, the flow of information could be smoothed from multiple angles. At the same time staging the role of “analysts” at the community level will be key. For these reasons, we propose the following actions:

    A Web Tool

A list of software packages is already available (the alliance), but from the user side this is not really practical because in actual research scenarios we want to find a specific function that matches the need regardless of the package in which it is contained. Many software packages are developed as a unit, so their documentations are monolithic. The list and associated documentations should become more functional rather than a one-dimensional listing of package names.

A web platform that integrates all  documentations should be created. It could decrease perpetual “reinventions of the wheel” and may at the same time channel the new developments towards truly innovative extensions. We call such user-oriented functional and highly interactive web platform as a “web tool” and propose the following specifications:

1. One page per Function

   1. Users try to find functions based on their needs rather than by name of the software package. This means that each function (plugin, menu item) included in the software packages should be assigned a single documentation page, and ideally should not be categorized by package.

   2. This is partially actualized in the Fiji project wiki page, where each contributed plugin features a page listing the name of the developer, the link to the source code and the usage instructions. This way of documentation should be extended to include all software packages and presented as single web document that offers higher accessibility to users.

2. Multiple tagging per Function

   1. A documentation page prepared for each function / modules / plugins / site-packages should have a tagging functionality. Tags are like keywords given to each page. Tags allow user to filter functions to find those that matches their needs.

   2. Each page should be assigned multiple tags.

   3. Both developers and users should be able to create tags and add tags to any page.

   4. There should be “tag administrators”, who control the tagging behaviors and also promotes the tagging. Administrators themselves should commit in active tagging.

3. Back-links to literature

   1. In general, papers that uses image processing and analysis mention the name of the package and function that they used. This is so to say, a forward link to the tools from papers.

   2. Users often wants to know examples of usages. For this reason, having back-links to literature / pubmed abstract page / websites using the function / tool is desirable so that users could be directed to actual example usages.

4. Comments from users

   1. A comment section should be added to each page so that any discussions / claims / questions could be viewed by other users.

   2. There could be further added with the aggregation of mailing list discussions (text scrapings).

   3. Access permissions (need more opinions on this issue):

      1. Similar to ‘Trip advisor’ (maybe hard to actualize), each function could feature a users’ and developers’ opinion chart together with the comments, about the various implementations of a function in different software packages or about the effectiveness of a function for a certain goal/analysis. So this is similar to a point developed above, but here the question is to discuss and decide whether to include a door for users to comment on the functions and their ease-of-use. Without an interactive access by users, the Wiki would lose the ‘wiki property’ which we look forward to developing, and could quickly be seen as a restricted portal where only a handful of developers can emit judgements. Obviously the comments page could be moderated by the developer and by other users with voting (‘like it’ / ‘don’t like it’).

5. sample datasets

   1. Links to sample datasets should be added to each page, so that user can try out the function and get a a feeling about the output to expect. As it is often difficult to know the limit of the functionality of tools, sample images will be a good reference.

   2. If possible, data storage and uploading features could be added. Then the sample data could be directly uploaded by taggers for users to test, evaluate and compare.

   3. When applicable ‘ground truth’ (expected) results of the function should ideally be added with each sample dataset.

A large part of the web tool should be edited manually. We propose a “taggathon” once the web tool proposed here becomes available. In this event, developers, analysts and users gather in one place and concentrate on tagging pages, back linking literature and adding documentation to each page.

    Meetings

Meeting will be a place to collectively spread and absorb image processing and analysis activities. In terms of increasing the software packages / tools accessibility, three different types of meetings should be organized with clearly defined target groups (developers, analysts and users) and directed flow of information between these groups. As a byproduct meetings strengthen human networks that trigger individual communication to be smoother and more informal, which allows specific solutions to problems by connecting developers, analysts and users. We include teaching oriented activities, or courses, as meetings since although the format differs, we think that the functionality is common in terms of increasing the accessibility to software packages.

    “Show Case” meetings (Developers and Analysts)

Software packages upgrade on daily basis and it is quite an effort to follow changes and new functions. An annual meeting with presentations explaining upgrades given by a developer from each software packages would be a great benefit for analysts to be updated with the latest changes. We call this a  “Show Case” meeting. In the same meeting, analysis would provide feed-backs by showing their usages, explaining merits and demerits of the software package and also to request missing functionalities. This meeting also invites prominent developers who are creating cutting edge algorithms so that the progress in the front line of image processing could also be known to developers and to analysts.

    Image Analysis Courses (Analysts teaching Users)

In image analysis courses, analysts teach users on how to combine various tools to tackle practical problems, in order to narrow  the gap between software packages and user’s demands by increasing the image analysis literacy of users. The BIAS 2013 course could be a template for such courses.

Several outcomes will be expected from this activity. The first is that users become more fluent with image analysis, which heightens their ability to choose and assemble appropriate tools. The second is that analysts learn from other analysts how they solved some specific problems and also possibly get aware of new problems they might be expected to solve in the future. The third is that by working together the community of analysts becomes strengthened, leading to an increase in lateral communications.

Courses could target two different types of user group: the first group is graduate students, postdocs and research scientists. The teaching aims that they could reach a level to do basic analysis on their own. The second group is microscope facility staffs. As analysts are still missing in many places, microscope facility staffs are taking the role of analysts beside the maintenance of microscopes. For this group of people the course teaches more advanced contents and also provides and assists teaching in their own institutes (Meta-teaching).

    General Assembly (Developers, Analysts, Users)

A general assembly is a gathering of all developers, analysts and users. During this gathering, hackathon, presentations and courses happen in parallel. This is because there are difference in interests among three different groups, but information flow between these groups could be efficiently increased by gathering at the same place. Analysts could teach users, and users could present their work and show how developers products are used, developers could report updates on their tools and libraries. In parallel the developers and analysts could also sit together in a hackathon to extend the tools. Analysts form the most capable group of people to feedback the developers with usages. More details on the merits and demerits of the general assembly could be further discussed.

• Developers sometimes go out from hackathon and give talks about their works. Discuss with analysts.

  • Hackathons are in many cases locally funded or in worst cases developers pay themselves. There should be more official support.

• Analysts teach and also take a part in the Hackathon (when they are not teaching). Discuss with developers on the usages.

• Users acquire a deep knowledge on usage of tools from the developer talks. Also being taught  practical strategies from analysts. Users present their work.

    Open Textbooks for BioImage Analysis

A significant problem of image analysis in biology is the lack of textbooks. For image processing, there are many textbooks written by computer scientists. These textbooks are extremely valuable as they explain the users the theory behind image processing algorithms and how they are working. However, these textbooks cover only a part of the task of image analysis in biology. In addition to image processing algorithms, bioimage analysis requires knowledge on what could be measured and how to measure biological images, but this part does not exist as textbook. This aspect of bioimage analysis is supposed to fulfill in biology a role similar to that of analytical chemistry in chemistry. As it has been missing, it turned out to be the fundamental reason for this growing gap between image processing software and user’s demands.

To fill this gap, analysts are at work interactively to bridge biologist’s demands and the image processing world, but their work should be organized as textbooks for efficient and systematic propagation of knowledge and techniques. As a start-up BIAS 2013 course prepared original textbooks to cover the gaps and to solve the fundamental problem in the accessibility to the image processing and analysis infrastructure. A special edition of the course is offered to image analysts working in European imaging core facilities after the community meeting. The writing of these textbooks could be standardized and the textbooks published as open textbooks to provide valuable and systematic information to biologists. At the same time, the publishing of the textbooks gives a firm scientific credit to analysts, secure their activity and pave the newly appearing career path, which may further attract more people to commit in this direction.

    Further Actions to be considered

Following is a list of actions not explained in the previous text but which will be considered in future.

1. For interoperability, define a standard platform (could be ImageJ, Python, Icy or any other). The platform does not have to be unique but it would be good that these platforms support multiple language bindings “from scratch” (such as Python) and that the pool of functions (plugins) that is written can easily be included to any of the platforms.

2. As a roadmap, a list of algorithms “to be implemented” could be prepared based on their relevance.

3. Set up a framework for algorithm evaluation with ground truth images, these datasets could also be used as example datasets.