Task #6747 (new)
Opened 13 years ago
Last modified 8 years ago
RFE: Tracking changes
Reported by: | jburel | Owned by: | jburel |
---|---|---|---|
Priority: | major | Milestone: | Unscheduled |
Component: | Insight | Version: | n.a. |
Keywords: | n.a. | Cc: | lem@…, saloynton |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | 0.25d |
Sprint: | n.a. |
Description
"If I understand correctly what you say, you would like to have the ability to see the adjusted image in the main viewer and on the right-hand side (for example next to rendering control) the original/unmodified image so you can compare."
Yes...this is a feature I think a lot of users would be interested in. By original, I do mean as originally displayed in insight. I just want to be able to keep track of changes made to the original data.
See https://www.openmicroscopy.org/community/viewtopic.php?f=13&t=817
Change History (9)
comment:1 Changed 13 years ago by jburel
comment:2 Changed 13 years ago by jburel
- Milestone changed from Unscheduled to OME-5.0
comment:3 Changed 12 years ago by jburel
- Cc saloynton added; saloyton removed
- Remaining Time set to 0.25
- Sprint set to 2011-11-24 (3)
comment:4 Changed 12 years ago by jburel
- Milestone changed from OMERO-Beta4.4 to 3.0-M2
- Sprint changed from 2011-11-29 (3) to 2011-12-27 (5)
comment:5 Changed 12 years ago by jburel
- Sprint 2012-01-03 (5) deleted
Other tickets had to be implemented first, pushing to later date
comment:6 Changed 12 years ago by jburel
- Milestone changed from 3.0-M2 to OMERO-Beta4.4
comment:7 Changed 12 years ago by jburel
- Milestone changed from OMERO-Beta4.4 to Future
Unfortunately, I had to put that work on hold.
comment:8 Changed 11 years ago by rkferguson
An implementation of change tracking as suggested would be basically like the history system such as Photoshop and other apps have - with some additional visualisation abilities - like ability to see each step in the full viewer/browse as thumbnails. The way this would be visualised in the UI would take quite a bit of thought.
This also raises a couple of issues off the top of my head:
- it would then have to be decided if this will allow rollbacks and if so what the implications are for data integrity - e.g. someone rolls back changes to data that has been used for a publication and effectively destroys the published data
- would such a track-back persist beyond a session
Also need to consider:
- what changes to the data the users want recorded
- should it be possible for the user to disable the tracking of changes if desired (implications of this choice!!)
- who else should be able to see the history
- is the history of the changes retained after the session even if not displayed in the UI
Two related issues occur to me:
- there would appear to be a lot of similarity to the changes required to allow "cloning" of images - i.e. totally separate database entries pointing to to the same raw pixel data - it might be that you would effectively be "cloning" the image every time you make a change
- this ties in with users wanting to link images as well - so that any image taken out and manipulated outside OMERO and then imported again has a link to the original image so it's provenance is apparent.
comment:9 Changed 8 years ago by jamoore
- Milestone changed from Future to Unscheduled
We've been talking about this a lot because it pertains to the original data source. Let's say a PI exports an image from OMERO, makes it pretty in Imaris or Image J, and then imports back into OMERO. They need an easy way to link back to the original .lsm (or whatever) file if they publish this image.