search

ome / design

OME Design proposals
http://ome.github.io/design/
1 stars 15 forks source link

OME005: Add additional writer implementation details #98

Closed rleigh-codelibre closed 6 years ago

rleigh-codelibre commented 6 years ago

Update the proposal with detailed steps for implementing OME-TIFF pyramid writing, including references to work in progress so far.

rleigh-codelibre commented 6 years ago

@mtbc All your comments should have fixes now, with the exception of the question mark, because I already see one!

sbesson commented 6 years ago

Thanks very much for documenting the current status of the implementation and the next proposed steps. Pushed a commit for the two obvious typos listed above.

Some of the questions raised by @melissalinkert are important to address while we define the boundaries of this extension. In order to deliver a working writing implementation in the upcoming weeks, we might need to make some decisions about the range of behaviors and layouts we will commit to support e.g. enforcing some constraints on the downsampling factor between resolutions sounds to be in agreement with existing pyramid formats but also a restriction we could decide to lift in the future if we wished so.

Merging this to update the state of the public design. The next step will be to turn it into a branch against the model with the formal specification extension.

rleigh-codelibre commented 6 years ago

@sbesson When it does come to considering the writer API design, do bear in mind http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2018-June/004260.html where the C# wrapper already added support for direct conversion of CoreMetadata to OMEXMLMetadata. This round-tripping is what's needed here as well, and the fact that it's been independently done without any input from ourselves highlights its utility and necessity. Whether it's setCoreMetadata in addition to setMetadataRetrieve or adding utility methods to achieve the same conversion in MetadataTools, round-tripping from one to the other is essential, and that will require proper subchannel sizes in CoreMetadata to round trip from Channel in the data model.

However, CoreMetadata is not something we really want to expose unless strictly necessary. Having the writer support the whole set of setXXX methods might be worthwhile for direct support for image acquisition, as opposed to conversion. Conversion is as simple as copying the metadata store or the core metadata list. But acquisition may require more direct interactivity, and we should consider this also. Specifying every series and dimension size up front is too restrictive, and relaxing this is primarily blocked by the initialized array in FormatWriter which should be pretty simple to adjust. You can only write the series in order, so it could be dynamically set per series. Interactive adjustment to add extra timepoints should be as simple as setSizeT(n).