Dear all,

I would like to ask your help in interpreting OME TIFF metadata:
Could you tell me please if it would be correct to assume that PhysicalSizeX/Y/Z are equal to 1.0, in case these properties are absent in OME TIFF metadata?

This is a sample OME TIFF where these properties are absent:
https://downloads.openmicroscopy.org/images/OME-TIFF/2016-06/bioformats-artificial/z-series.ome.tif

Thank you for any input,
Best regards,
Aliaksei

Transmission electron microscope can produce diffraction image often called SAED. These would be in “1/nm” units since they are from the conjugated plane. When we open such a file (*.dm4) in Fiji with Bio-Format, the following warning is displayed:
[WARN] Not adjusting for unknown units: 1/nm
If we go in “scale bar”, the unit was simply replaced with microns, which is misleading and should not be used. I suggest that the 1/nm unit could simply be included as a valid unit in Bio-Format. It's often presented with parenthesis to avoid confusion "(1/nm)".

Here's an exemple of how an analysis of these images could be done. Briefly, length are kept in reciprocal (1/nm) units, then the user would invert them to obtain the d-spacing which is the wanted value is those analysis.

In my case, the camera used to produce the images is a Gatan OneView, filetype is dm4,
Fiji/ImageJ 2.14.0/1.54f; Java 1.8.0_322 [64-bit]; Windows 10

Just a note that the three previous URLs looking to be working now.

Originally posted by @joshmoore in #155 (comment)

Due to changes in the language, the vendored Genshi dependency will require an update. Support is currently being developed upstream, and a new release is expected reasonably soon.

[ERROR] Rule failure while trying to close staging repository with ID "orgopenmicroscopy-1047".
[ERROR]
[ERROR] Nexus Staging Rules Failure Report
[ERROR] ==================================
[ERROR]
[ERROR] Repository "orgopenmicroscopy-1047" failures
[ERROR]   Rule "javadoc-staging" failures
[ERROR]     * Missing: no javadoc jar found in folder '/org/openmicroscopy/specification/5.6.3'
[ERROR]     * Missing: no javadoc jar found in folder '/org/openmicroscopy/ome-xml/5.6.3'
[ERROR]
[ERROR]
[ERROR] Cleaning up local stage directory after a Rule failure during close of staging repositories: [orgopenmicroscopy-1047]
[ERROR]  * Deleting context 226f0ceed4c8d6.properties
[ERROR] Cleaning up remote stage repositories after a Rule failure during close of staging repositories: [orgopenmicroscopy-1047]
[ERROR]  * Dropping failed staging repository with ID "orgopenmicroscopy-1047" (Rule failure during close of staging repositories: [orgopenmicroscopy-1047]).

similar to ome/ome-stubs#4

Hi @bioformats,

Just a small enhancement request. Could you add GaAsP-PMT' to the DetectorType list? The relevent error is below.

WARN l.enums.handlers.DetectorTypeEnumHandler - Unknown DetectorType value 'GaAsP-PMT' will be stored as "Other"

-J

Regarding CI, I think the current approach is testing a lot of different combinations, but is not as effective as it could be in testing what is important. For example, the important part for the code generation is ensuring that the generated code doesn't differ between python versions (for consistency) and compared with the previous commit (to highlight generated source changes for review). But neither are tested. If you check both of these separately, and fail if there are changes between Python versions, and warn if there is a change compared with the previous commit, then you can build with a single Python version since you know that the code you are building is identical, and you'll be notified there is something additional to review if there are changes against the previous commit.

The above would reduce the job count to n Python jobs and m Java jobs which will test effectively, rather than n × m combinations which aren't giving the same coverage. (Not including the Python module, which is already tested separately.)

You could copy the approach taken here with the script_unix_java_gensrc block, and the diffsrc block below, and do that for each supported Python version. Here it's done with Gradle, but the Maven approach is the same. Now you're on GitHub Actions this probably becomes easier than it was with Travis!

Originally posted by @rleigh-codelibre in #127 (comment)

The docs at https://docs.openmicroscopy.org/ome-model/5.6.1/ome-tiff/data.html#d-datasets state that Each plane is labeled according to its dimensional position for easy testing, but it seems that there are no plane elements in the metadata for the 5D artificial datasets. There is plane-like cross section information keyed by the "IFD" attribute:

         <TiffData FirstC="0" FirstT="0" FirstZ="0" IFD="0" PlaneCount="1">
            <UUID FileName="multi-channel-time-series.ome.tif">
               urn:uuid:8bce8751-8546-4a77-9d60-2f7c391e2d16
            </UUID>
         </TiffData>
         <TiffData FirstC="1" FirstT="0" FirstZ="0" IFD="1" PlaneCount="1">
            <UUID FileName="multi-channel-time-series.ome.tif">
               urn:uuid:8bce8751-8546-4a77-9d60-2f7c391e2d16
            </UUID>

but no plane elements themselves. It might be nice to have such data to test plane related metadata access.

For each of the generated EnumHandler classes, the types are evaluated in the wrong order. None of the Positive(Integer|Long|Float) types will be used because they are extending the NonNegative(Integer|Long|Float) types and these are checked first, and will match the Positive cases too.

Should be fixable by changing the ordering.

Issue is a follow up to image.sc thread https://forum.image.sc/t/bio-formats-returns-all-metadata-except-ome-meta-data/52295/2

Using the sample file provided in the thread and correcting validation errors shows that the original metadata (stored in 2003-FC spec) gets lost when going through the transform update process. The particular transform the issue occurs with is
2008-09-to-2009-09.xsl

The data that gets lost is stored using the OriginalMetadata tag such as below (adding the CA namespace didn't resolve the issue):

<CustomAttributes>
<OriginalMetadata ID="OriginalMetadata:3" Name="Acquisition Parameters/Channel 2" Value="Fluorescence"/>
</CustomAttributes>

In the transform this should be handled by the following, transforming the metadata to an XMLAnnotation:

  <xsl:template match="CA:*">
    <xsl:element name="{name()}" namespace="{$newCANS}">
      <xsl:apply-templates select="@*|node()"/>
    </xsl:element>
  </xsl:template>

  <!-- Transform the CustomAttributes into XMLAnnotation -->
  <xsl:template match="CA:CustomAttributes">
    <xsl:if test="count(@*|node()) &gt; 0">
      <xsl:element name="StructuredAnnotations" namespace="{$newSANS}">
        <xsl:element name="XMLAnnotation" namespace="{$newSANS}">
          <xsl:attribute name="ID">Annotation:1</xsl:attribute>
          <xsl:element name="Value" namespace="{$newSANS}">
            <xsl:apply-templates select="@*|node()"/>
          </xsl:element>
        </xsl:element>
      </xsl:element>
    </xsl:if>
  </xsl:template>

The Java MetadataConverter does not appear to be handing WellAnnotationRef correctly. wellAnnotationRefCount is never assigned any value other than 0. Fix appears straightforward.

Impact: All WellAnnotationRefs are silently dropped during this conversion.

The OME-Files C++ converter does not contain this defect.

On this page, the link online API documentation refers to a wrong BioFormats page, which does not contain ome.xml.* packages as described in the page.

Dear all,

I would like to ask your help in interpreting OME TIFF metadata:
Could you tell me please what is the difference between DimOrder BF, DimOrder BF Array, and DimOrder?

Thank you for any input,
Best regards,
Aliaksei

	<xsd:element name="MetadataOnly"> <!-- top level definition -->
		<xsd:annotation>
			<xsd:documentation>
				This place holder means there is on pixel data in this file.
			</xsd:documentation>
		</xsd:annotation>
	</xsd:element>
	<xsd:element name="TiffData"> <!-- top level definition -->
		<xsd:annotation>
			<xsd:documentation>
				This described the location of the pixel data in a tiff file.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>

Should be there is no pixel data and describes the location

Initially reported by and discussed with @ngladitz over IRC

The generated OME model classes have currently only partial support for the OME.Creator attribute of the OME 2016-06 schema. More precisely

• the low-level model classes have the correct getters and setters - see ome.xml.model.OME.getCreator() and ome.xml.model.OME.getCreator(String)
• the metadata classes lack such getters/setters - see ome.xml.meta.MetadataRetrieve

From the Bio-Formats consumer perspective, this means that the Creator metadata is currently lost while running MetadataConverter.

Unless there is a clear rationale for excluding the Creator attribute, it feels like we want to (re)add support in the metadata classes. Assuming the top-level OME element is not completely handled by the code generation, a starting point would be to add methods to the list of manual definitions e.g. https://github.com/ome/ome-model/blob/v6.0.1/xsd-fu/templates-java/MetadataRetrieve.template#L348. As an additional technical point, it would be very useful to find a way and make such additions amenable to a minor release increment (backwards-compatible API addition) rather than a major release increment (breaking API).

The Immersion enum does not have a value for silicone immersion. I'm using 'OTHER' at the moment, but I guess that Silicone could be have its own value. I found this missing while adding more ids for ome/bioformats#2656

Hi All,

We were wondering whether the current ome.xml (or the new version) would be flexible enough to represent our "adaptive feedback microscopy" datasets.

A typical example is:

• Multi-well
  • Multi-position
    • At each position:
      • One low resolution "pre-scan" overview image
      • Several zoomed-in high-resolution time-series "re-scan" datasets, whose positions are somewhere within the low resolution pre-scan image.

The ome-model repository still contains all of the code generation infrastructure and templates as well as source code for C++. Do you want to retain it here, given that it's currently untested, or are you happy for it to live over in https://gitlab.com/codelibre/ome/ome-model where it's actively tested on multiple platforms?

If you don't want it here, because any changes which affect the C++ code or templates can't be effectively tested, I'll be happy to make a PR which removes the templates and/or the code.

Introduction

Following the presentation of the Riken Metadatabase at the 2018 OME Users meeting, @norikoba has been driving the translation of the OME xsd schema into OWL ontology. The current version is available as an incubator project at https://gitlab.com/openmicroscopy/incubator/ome-owl/. As discussed recently during the OME team visit in Kobe, this work is now reaching production level.

The ome-model repository was created and consumed starting from Bio-Formats 5.2.0 and OME-Files 0.3.0. It is composed of two components:

• the specification component contains the XSD schemas, the XSLT transforms and the OME-XML samples for all releases of the OME data model as well as some utility Java classes for creating objects
• the ome-xml component contains Java and C++ code-generated classes for working with the model

This issue discusses how to integrate of the OWL ontologies as part of the specification component. None of the changes below are formally breaking the specification itself or any of the API although the new file layout would require a few changes discussed in each section.

Specifications

Each release of the data model is versioned using a calendar format of type YYYY-MM and the corresponding XSD schemas are stored under a YYYY-MM folder under specification/src/main/resources/released-schema/.

It was agreed that the OWL ontology should use the same versioning strategy YYYY-MM for consistency. We could simply introduce another top-level folder under specification/src/main/resources/. While doing so, it might be worth cleaning up the released- suffix.

Proposal

• rename the XSD schemas folder as specification/src/main/resources/schemas/YYYY-MM/
• update all code in specification, OME-XML Java and C++ classes as well as downstream components classes to consume the new schemas location
• create specification/src/main/resources/ontologies/2016-06/ and move the 2016-06 ontology alongside the XSD schema

Transforms

XSLT transforms are currently located under specification/src/main/resources/transforms/. The way ttl files will be transformed between different versions of the ontology is still not clear to me. Discussions seemed to indicate a process consuming the new ontology as well as the inference engine. No action needed at the moment although transform files could be added to this folder if necessary.

Samples

For each release of the XSD schema, representative samples are created (or upgraded) under the form of OME-XML files under a specification/samples/YYYY-MM folder. @norikoba starting working on a
corresponding set of Turtle (ttl) samples for the OWL ontology.

Having a representation of each sample both in xml and ttl is valuable. Next action here is probably to look into some tooling to batch convert all XML samples into TTL. In terms of organization, having both samples under the same umbrella would be the most sensible. Primary question is whether both types of samples should be under the same folder or under separate subfolder like the specifications.

Additinoally, migrating the samples under specification/src/main/resources/ would increase consistency and simplofy the bundling of these samples if we wished so.

Proposal

• migrate the OME-XML samples under specification/src/main/resources/samples
• generate a set of TTL samples (maybe.ome.ttl) and add them to the same directory
• depending on the outcome, split samples per type

Publication

Most of the OME data model resources are available online. The XSD schemas are served under https://www.openmicroscopy.org/Schemas/ e.g. https://www.openmicroscopy.org/Schemas/OME/2016-06/ome.xsd for the latest OME Data model schema. For OWL ontologies, discussion tended to go towards https://www.openmicroscopy.org/Ontologies.

In terms of process, the HTML pages above are created by the publish script at the moment which aggregates all the xsd resources and create a set of navigation HTML pages. These pages are then served statically and proxied from the main https://www.openmicroscopy.org/ website (https://github.com/openmicroscopy/prod-playbooks/blob/master/www/www-deploy.yml#L30). This primarily comes from the migration of the www.openmicroscopy.org website in Summer'18 rather than architectural design.

As we will want to create new online resources, we might want to review the publication process. One option here will be to move these pages to Jekyll. Advantages of this approach is that it unifies the process with the other front-facing resources and facilitates the integration with the OME website. In terms of deployment and review, this means we should also be able to use the GitHub pages service to deploy and review staging specification pages.

https://github.com/ome/ome-model/blob/fbe39c099b4b3ab02ccfa93c0af6bcf84515a564/specification/src/main/resources/released-schema/2016-06/ome.xsd#L3186C15-L3186C15 points to http://www.openmicroscopy.org/site/support/file-formats/working-with-ome-xml/id-and-lsid which no longer resolves

Hi there!

I read https://docs.openmicroscopy.org/ome-model/6.0.0/specifications/minimum.html and read about a "" element. That sounds to me like it would be allowed to put an OME-XML file next to some tiff files to describe them? I am not sure whether I got that right, sorry for the newbie question.

Would be great if you could help me out here. :) Thanks!

Dear all,

I would like to ask your help in interpreting OME TIFF metadata:
Could you tell me please how to determine the units of time based on metadata?

Thank you for any input,
Best regards,
Aliaksei

I was told, there is a field missing for storing what color the background(?) has. How could such a field be added to the specification?