[ome-devel] [ome-nitpick] ROI types

[Roger Leigh]

Moving this to -devel as recommended.

I've attached a copy of some simple figures to illustrate what I was
trying to articulate below.  This takes some relatively simple
measurements, and breaks them down into the four different contexts.

Thinking about this a little more, in many cases it will be possible
to omit some contexts and infer them from the others. For example, if I
have a simple line I will store a line in the result context.  The
measurement context is the same two points, and so we may simply use the
result context points in its place.  Likewise, if the measurement is a
simple one, the visual context may be omitted and inferred from the
result context also.  The different contexts really only come into play
when we want a more sophisticated visual representation (for example
with overlaid textual representations of the measurement value or to
visualise the measurement in a more complex manner than the result
context alone can provide).  And they are essential when using more
complex compound ROIs as the last example attached shows.

In the last example, all the information is provided to allow the user
to edit the object in a UI.  For example, they can adjust the end points
of the baseline, and the start points of the lines in the measurement
context can be retriangulated from the end points and baseline.  The
measurement context can be inferred from the endpoints of the lines in
the result context.  And the endpoints can also be adjusted
independently.  Following any adjustment, the updated baseline can be
stored in the editing context, the measurement lines in the measurement
context, and the visual representation in the visual context.  The
visual context is shown here to include end markers on the distance
lines, and text labels with the measured values.  But these could be
toggled on or off and the settings stored in an annotation specific for
this measurement type--there's really no limit to the "extra stuff" you
can add here, but the basic measurement remains the same in the result
context.

(In this example, the baseline could actually be in the measurement
context, since it's part of the measurement; the first example is a
better illustration of the editing context.)

The important point is that anyone should be able to open the file and
display the visual representation without any knowledge of the specifics
of the ROI type or measurements being made.  Likewise they can also look
at the measured distances in the results context and use them without
any knowledge of how they were measured.  Only a UI which supports the
ROI type in question will need to use the editing and/or measurements
context, and they will know how to regenerate the other contexts when
editing.


Regards,
Roger

On 27/04/2012 15:03, Roger Leigh wrote:
> On 25/04/2012 12:12, Roger Leigh wrote:
> I've been thinking about how we might store and interact with more
> complex compound ROI types. This is just some thoughts on that;
> comments (and/or abuse) welcome!
>
>
> Storing and manipulating complex compound objects
> =================================================
>
> With these measurements, one thing perhaps worth considering is that
> there are up to four types of object here:
> 1) Result context. The object(s) representing the physical measurement.
> This is what we currently store in the model.
> 2) Measurement context: line along radius of circle, points along
> circumference of circle etc. This is "how the measurement was made"
> 3) Visual context: such as visual cues such as construction lines. This
> is the visual presentation of the measurement to the viewer.
> 4) Editing context: values which control the placement of the above.
> Information for generation of UI manipulation handles, and of the other
> contexts while editing.
>
> We can represent the actual measurements in most cases using the
> existing ROI types. However, if we store the additional types, it's no
> longer possible to distinguish between the measurement and the
> additional context.
>
> If it was possible to distinguish between these in the model, it would
> be possible for the objects to be displayed without any advanced
> knowledge of how an object should be edited. It would also be possible
> to extract the primitive measurement values. However, the measurement
> context would provide additional information to editors for manupulation
> of the object, which would then be able to update all three contexts
> appropriately.
>
> Doing this would provide a simple but effective means for additional ROI
> types to be added without requiring support in all programs
> displaying/modifying ROIs. This does not of course replace the need for
> namespaces to identify ROI categories, but it does supplement it by
> allowing programs to selectively display different contexts without any
> knowledge of the underlying type.
>
> As an example, using this length measurement:
>
> |******OBJECT*******|
> | |
> |<----------------->|
> 50 µm
>
>
> 1) Result context
>
> #******OBJECT*******#
>
> (where the #s are the start and end points of a Line at either end
> of the object. This is the value of the physical measurement.)
>
> 2) Measurement context
>
> No additional information needed in this case.
>
> 3) Visual context
>
> | |
> | |
> |<----------------->|
> 50 µm
>
> Three lines, one with arrow end markers, plus text label.
> This is the visual representation of the measurement.
>
> 4) Editing context
>
> #******OBJECT*******
> #
> #
>
> (where the #s represent a distance between the measured line and the
> drawn line in the visual context. This information is used to generate
> the visual context from the measurement context.)
>
>
> I hope the above doesn't sound too way out. But the current system is
> limited to storing only the first of these four contexts, which loses
> information. While it's possible to delegate all of the presentation
> and editing to the viewer, the reality is that this is stuff people
> want. If I'm annotating an image for a paper, I want the annotations to
> appear exactly the same as I see them if I send them to someone else.
> And if I'm doing physical measurements, I want the specifics of how I
> made the measurement to be recorded. All we are doing here is providing
> additional information to the viewer/editor that it is free to use
> and/or ignore as it chooses.
>
>
> Regards,
> Roger
>
> The University of Dundee is a registered Scottish Charity, No: SC015096
>
> _______________________________________________
> ome-nitpick mailing list
> ome-nitpick at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-nitpick
>


The University of Dundee is a registered Scottish Charity, No: SC015096
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roi-contexts.pdf
Type: application/pdf
Size: 881914 bytes
Desc: not available
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20120427/a177a1bf/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roi-contexts.svg
Type: image/svg+xml
Size: 94179 bytes
Desc: not available
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20120427/a177a1bf/attachment-0001.svg>