[ome-devel] Prairie View XML changes for upcoming v5.2 Release

[Fong, Jimmy]

Thanks Curtis, Andrew and others,

In the next service update to our version 5.2 software, we will set the SamplesPerPixel field in the OME metadata to 1 for all our acquisitions.  Going forward starting with version 5.3 of Prairie View, this will also be the case.  We appreciate all your help and effort.

Regards,
Jimmy


Jimmy Fong
Software Engineer

Bruker Nano Surfaces Division                      Jimmy.Fong at bruker-nano.com
3030 Laura Lane, Suite 140                               www.bruker.com/nano
Middleton, WI 53562-0677
Phone: +1 608-662-0022 x163
________________________________
We are now Bruker!
Same great products.  Same great technology.
Same great people.  New great name.


________________________________________
From: Andrew Patterson [ajpatterson at lifesci.dundee.ac.uk]
Sent: Tuesday, October 14, 2014 11:15 AM
To: Curtis Rueden; Fong, Jimmy
Cc: Wussow, Mike; Jason Swedlow; OME Development List; Staniszewski, Kevin; Melissa Linkert
Subject: Re: [ome-devel] Prairie View XML changes for upcoming v5.2 Release

Hello Curtis, Jimmy,

On 10 Oct 2014, at 22:53, Curtis Rueden <ctrueden at wisc.edu> wrote:
> == SamplesPerPixel vs. Integration ==
>
> Jimmy wrote:
> > we often average 3 raw samples together to form 1 pixel value, and
> > only write the single pixel value to Tiff.  We would like our Prairie
> > XML file to still reflect SamplesPerPixel = 3 so users could go back
> > and reference that value.
>
> The term "SamplesPerPixel" has a very technical meaning in TIFF and OME-XML: it is the number of sample values actually recorded in the file. Since there is only one sample value recorded per pixel, SamplesPerPixel must equal 1 for this data.
>
> Conversely, what you describe is, I think, what the OME schema refers to as "integration" [1]. It's not exactly "frame" averaging, but seems conceptually equivalent. Andrew, would you agree?

The SamplesPerPixel value is a little odd for historic reasons. It comes from having a specific value for it some years ago when we had separate LogicalChannel and ChannelComponent elements in the model. These were merged to form the current Channel element in September 2009. The value was on LogicalChannel and was the count of ChannelComponent elements (each with their own set of pixels) that the LogicalChannel contained. It was moved to Channel and retained for consistency but it can also be calculated from the structure of other data in the file.
Even if several measurements were taken, if there is only one computed pixel value stored in the file then SamplesPerPixel should equal 1.

>From the description of your data I think setting Integration in DetectorSettings is the best fit.

Hope this helps,

Andrew