[ome-devel] camera crop region into ome-xml

[Grabmayr, Heinrich]

> >> On 24/09/15 20:23, Grabmayr, Heinrich wrote:
> >>> I would like to write the ROI I read out from the camera into the
> >> metadata. I had thought there might be an attribute for that in
> >> OME\Instrument\Detector, but I didn't find anything of the sort there
> >> in the
> >> 2015-01 schema. Does anyone save their ROI in the metadata? What is
> >> the best way? Should I add a Structured Annotation for it?
> >>
> >> Dear Heinrich,
> >>
> >> We don't currently have any formal attribute for this in the data
> >> model, however we can consider adding such an attribute if there will
> >> be general need for such a feature.
> >>
> >> For modelling purposes, it would be useful to know some more details
> >> about how this works and what it's used for.  What is the make and
> >> model of the CCD?  Are the regions rectangular or can they be other
> >> shapes, or are there restrictions on sizes and placement?  Is this
> >> simply limiting the CCD readout to the specified region?  Is this
> >> feature common to other models of CCD; for the model we need to be
> able to generalise this to support other types.
> >
> > I am using a PCO.edge 4.2 sCMOS camera, but cropping and binning is
> common for most CCD, EMCCD, and (s)CMOS cameras. Probably, people
> don't often need to store this information because the excitation intensity
> distribution doesn't remain constant from session to session, or they don't
> care as much about comparing positions with respect to the excitation
> intensity. So it would be interesting to see whether adding this would be of
> interest to the larger community.
> > In general, these are rectangular shapes with edges parallel to the chip,
> and you are right, it simply specifies which pixels are read out and
> transmitted to the computer. Another related feature that I don't use but
> that can be done with most cameras as well, is binning, which means that
> the camera treats every n pixels as one and adds their charges together.
> This can have different n for the two detector dimensions and results in an
> image with pixel size W/nx times H/ny.
> 
> OK, that all makes sense.  We already have support for binning in the model,
> though it's currently an enumeration rather than allowing arbitrary values.
> The only minor detail I can see is whether the region is using the real pixels
> or binned pixels when describing the size and position.  What does your CCD
> do here?

I just checked: with my camera size and position are described for binned pixels, however I believe that camera software I have used in the past described it using the real pixels. I am not quite sure about that, though.

> 
> >> You certainly can use a Structured Annotation to attach the metadata
> >> to the Detector object.  You can use any annotation type you see fit here.
> >>    One possibility would be to use the MapAnnotation to store the
> >> region data.  An example:
> >>
> >>          <SA:MapAnnotation ID="Annotation:1"
> >> Namespace="uk.ac.dundee.lifesci:ccd-roi">
> >>                  <SA:Description>CCD Region</SA:Description>
> >>                  <SA:Value>
> >>                          <M K="X">64</M>
> >>                          <M K="Y">64</M>
> >>                          <M K="W">256</M>
> >>                          <M K="H">256</M>
> >>                  </SA:Value>
> >>          </SA:MapAnnotation>
> >>
> >> You can then reference this in the Detector:
> >>
> >>          <Detector Gain="nn" Voltage="mm" Offset="oo" Zoom="0"
> >> AmplificationGain="0" ID="Detector:1" Type="CCD">
> >>                  <SA:AnnotationRef ID="Annotation:1"/>
> >>          </Detector>
> >>
> >> This currently needs setting directly on the Detector element; it's
> >> not possible to annotate DetectorSettings--this is something which we
> >> can review for the next model revision.
> >
> > Great, thanks! I'll try to implement that. As for the namespace, it doesn't
> have to point to any real server location, right?
> 
> No, this is completely arbitrary, it just needs to be unique for your purposes;
> we typically use a java-style namespace to make it unique for the person or
> organisation, but it's entirely up to you!

OK, cool. 

Thanks!
   Heinrich