CONFOCALMICROSCOPY Archives

February 2009

CONFOCALMICROSCOPY@LISTS.UMN.EDU

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Confocal Microscopy List <[log in to unmask]>
Date:
Sun, 1 Feb 2009 15:25:01 -0500
Reply-To:
Confocal Microscopy List <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1
From:
Chris Tully <[log in to unmask]>
Parts/Attachments:
text/plain (113 lines)
Jason,

Having been involved in the FDA compliance issues for image processing
software, here are my suggestions:

1) Have a fairly granular set of controls for who can edit which
metadata.  I.e. the lab manager can but the user can't.  Or maybe in
the case of a manual microscope all users need to be able to edit
magnification but only the manager can edit acquisition time.
2) An optional audit database should have the option to only keep the
original metadata or keep it all.
3) Consider how changes are made and log the minimum set of changes to
reproduce the result.  For example, if I change the acquisition times
to reflect a 10 ms interval because the acquisition software failed to
record actual acquisition times, there is no need to record the change
for each frame of a sequence.  Instead just record the change as a
global instruction.

In my experience MOST people do not need the Audit features but for
those who do, they are a non-optional item - they MUST be there and be
granular and robust.

Chris

Chris Tully
Microscopy and Image Analysis Expert
[log in to unmask]
240-888-1021
http://www.linkedin.com/in/christully



On Sun, Feb 1, 2009 at 3:09 PM, Jason Swedlow <[log in to unmask]> wrote:
> Dear All-
>
> Apologies-- this is not a direct confocal question, but it does affect use
> and analysis of confocal data.  If you don't care about image metadata, then
> just ignore and delete.
>
> As the OME project moves towards release of OMERO-Beta4
> (http://trac.openmicroscopy.org.uk/omero/roadmap), we have a number of
> issues coming up we'd like feedback on.
>
> The first is metadata editability.  In Beta4, we've gone for something we
> call "metadata completion".  This means that, for a given image file format,
> we capture and find a home for all of the metadata in that format which fits
> into OMERO.  For some formats, that's easy, because there is so little
> metadata.  But many are quite rich, and this project has been a huge effort
> by the Bio-Formats (Melissa Linkert) and OMERO (Brian Loranger, Chris Allan,
> Jean-Marie Burel) teams.
>
> The result is that we will support 5 rich file formats in Beta4
> "completely".  Note that we have to make decision about what each piece of
> metadata means-- we certify that it has been imported into OMERO, although
> there are a few edge cases where we've had to make decisions about where
> each piece of metadata goes.
>
> This raises a critical question, that we have debated within OME for years,
> namely:
>
> What image metadata should be editable? Imagine that some value was either
> unset or wrongly set on the microscope, a user may want to correct the
> situation after import. Then, if we allow editing, how much info about that
> editing should we track?
>
> Some technical points:
>
> -- in OMERO, we store every write to the DB as an Event.  So we know every
> change, who did it and when.
>
> -- we really do NOT want to store every metadata change made.  Doing this
> properly means making multiple copies of every database entry every time one
> thing changes-- so things get bloated very rapidly.
>
> A compromise we are considering seriously-- keep only the last metadata
> value, but log all the changes.  If a user has changed any metadata that
> came with an image fille, we can add functionality to the client
> applications to let the user find this out.  You'll know that the data has
> changed, by whom, and when, you just wont know what the previous data was.
>
> If necessary, we could implement an audit database, which stores previous
> metadata versions, or maybe just the first version-- the one that was
> acquired with the original .  This would be optional-- if needed it could be
> turned on.  We won't get that done for the first Beta4.0 release, but if
> it's a priority, it could come later this year.
>
> Thanks for your ideas and comments.
>
> Cheers,
>
> Jason
>
>
> --
> **************************
> Wellcome Trust Centre for Gene Regulation & Expression
> College of Life Sciences
> MSI/WTB/JBC Complex
> University of Dundee
> Dow Street
> Dundee  DD1 5EH
> United Kingdom
>
> phone (01382) 385819
> Intl phone:  44 1382 385819
> FAX   (01382) 388072
> email: [log in to unmask]
>
> Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
> Open Microscopy Environment: http://openmicroscopy.org
> **************************
>

ATOM RSS1 RSS2