Task #4167 (new)
Opened 13 years ago
Last modified 8 years ago
Writers do not support overwriting metadata
| Reported by: | mlinkert | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | Unscheduled |
| Component: | Bio-Formats | Version: | OMERO-5.2.0 |
| Keywords: | export | Cc: | simon.blanchoud@… |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | n.a. |
Description
See attached test case. In summary, writing some subset of planes using one MetadataRetrieve? then closing the writer, re-initializing with a different MetadataRetrieve?, and writing the remaining planes does not have the desired effect.
Attachments (1)
Change History (5)
comment:1 Changed 13 years ago by jmoore
comment:2 Changed 12 years ago by mlinkert
- Milestone changed from OMERO-Beta4.4 to Unscheduled
comment:3 Changed 11 years ago by mlinkert
- Keywords export added
Changed 8 years ago by mlinkert
comment:4 Changed 8 years ago by mlinkert
- Owner mlinkert deleted
- Version set to OMERO-5.2.0
Re-attached original test code, which is old enough that it likely needs to be updated before being usable.
I think it's still up for debate whether this can reliably be resolved at the writer level; what we've been telling people to do for OME-XML/OME-TIFF is effectively this:
I'd be OK with this being closed if any combination of the following are done:
1) the post-processing solution in FileWriteSPW is more obviously documented as the correct way to do this
2) a limited set of post-setId metadata changes are allowed (e.g. SizeZ, SizeC, SizeT), possibly for OME-TIFF only
3) an example is written up detailing how we expect writing OME-TIFF at acquisition time to be done
imported from bio-formats:#591