Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #12642 (accepted)

Opened 5 years ago

Last modified 3 years ago

BUG: Export as OME-TIFF broken

Reported by: pwalczysko Owned by: jburel
Priority: blocker Milestone: OME-Files
Component: Export Version: 5.1.0-m1
Keywords: n.a. Cc: ux@…, bf@…
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

On the sample image

https://github.com/qidane/bioformats/blob/3b610d810f966749ddc751ad16a5e8ab44178dff/components/specification/samples/develop/6x4y1z1t1c8b-swatch-instrument-units-none.ome

the Export as OME-TIFF gives wrong result (compare with the original on the screenshot and the "Save as Tiff" result)

Happens the same both in Web and Insight

Attachments (2)

Screen Shot 2014-11-17 at 18.25.36.png (176.8 KB) - added by pwalczysko 5 years ago.
jmarie.ome.tiff (17.6 KB) - added by pwalczysko 5 years ago.

Download all attachments as: .zip

Change History (26)

Changed 5 years ago by pwalczysko

comment:1 Changed 5 years ago by pwalczysko

  • Cc mlinkert added

comment:2 Changed 5 years ago by pwalczysko

Further investigation with ajpatterson revealed that:

  • there is a flaw in the writing of OME-TIFF when exporting these from clients
  • the flaw / discrepancy with the original image is apparent (at least) in the top left corner
  • the writing of the OME-TIFF is different from case to case (difference spotted between 2 downloaded images in 2 consecutive days from the same original)
  • a mock image created in Photoshop, which has a homogeneous gradient of intensities from left to right was created by Andrew and imported to OMERO
  • this image clearly shows the flaw (see trout/merge, user-4 group read-write, dataset Andrew test, ID 24759)
  • ajpatterson suggested to get mlinkert into the loop

comment:3 Changed 5 years ago by pwalczysko

  • Owner changed from web-team@… to mlinkert

comment:4 Changed 5 years ago by pwalczysko

Changed the ownership to mlinkert - sorry if this is not the right course of action, but I understand we need at least your opinion at this stage.

comment:5 Changed 5 years ago by pwalczysko

  • Component changed from Web to Export

Note that the problem happens in Insight as well as Web.

comment:6 Changed 5 years ago by jamoore

  • Resolution set to invalid
  • Status changed from new to closed

comment:7 Changed 5 years ago by pwalczysko

Note that similar noise problems with our readers were reported for SCN files http://lists.openmicroscopy.org.uk/pipermail/ome-users/2014-December/004938.html

comment:8 Changed 5 years ago by pwalczysko

@jamoore : Not sure what is happening here. The ticket was closed on the strength of it being replaced by the Trello. Then the Trello card was archived on the strenght of not being relevant to the board. ????

comment:9 Changed 5 years ago by pwalczysko

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:10 Changed 5 years ago by jburel

  • Owner changed from mlinkert to jburel
  • Status changed from reopened to accepted

It is b/c it was not related to units.
I will have a look
it could be related to the RE

comment:11 Changed 5 years ago by jamoore

Thanks for catching that, Petr!

comment:12 Changed 5 years ago by jamoore

  • Milestone changed from 5.1.0-m2 to 5.1.0

comment:13 Changed 5 years ago by pwalczysko

The important thing is that the image must be small

  • create in Fiji an image "New -> Imege"
  • use size 10 x 10 and use "Ramp"
  • then, still in Fiji, save the newly created image as tiff (do not use Bio-Formats)
  • import the image to OMERO (looks as expected)
  • export it from OMERO using the latest schema
  • view the image using the default Preview program on Mac - it is completely scrambled
  • reimport the scrambled .ome.tiff into OMERO
  • the image looks okay
  • examine the oritinally created .tiff using tiffinfo - the info says
Subfile Type: (0 = 0x0)
  Image Width: 10 Image Length: 10
  • examine the exported .ome.tiff using tiffinfo
  Image Width: 10 Image Length: 10
  Tile Width: 128 Tile Length: 128
  • obviously a Bio-Formats problem

See user-3, ID 26356, trout merge.

Changed 5 years ago by pwalczysko

comment:14 Changed 5 years ago by pwalczysko

  • Milestone changed from 5.1.0 to 5.1.1

comment:15 Changed 5 years ago by jburel

  • Milestone changed from 5.1.1 to 5.1.3

OME-TIFF work scheduled for 5.1.3. Moving to 5.1.3.

comment:16 Changed 4 years ago by jburel

  • Milestone changed from 5.1.3 to 5.1.4

comment:17 Changed 4 years ago by jamoore

  • Milestone changed from 5.1.4 to OMERO-5.1.4

Splitting 5.1.4 due to milestone decoupling

comment:18 Changed 4 years ago by jburel

  • Milestone changed from OMERO-5.1.4 to 5.x

The work on export has been pushed

comment:19 Changed 4 years ago by jamoore

  • Milestone changed from 5.x to OMERO-5.2.1

Bumping for review.

comment:20 Changed 4 years ago by jburel

  • Milestone changed from OMERO-5.2.1 to OMERO-5.2.2

Milestone OMERO-5.2.1 deleted

comment:21 Changed 4 years ago by jburel

  • Milestone changed from OMERO-5.2.2 to OMERO-5.2.1

Milestone OMERO-5.2.2 deleted

comment:22 Changed 4 years ago by jburel

  • Milestone changed from OMERO-5.2.2 to Metadata

comment:23 Changed 4 years ago by jburel

  • Milestone changed from Metadata to OME-Files

comment:24 Changed 3 years ago by mtbcarroll

  • Cc bf@… added; ajpatterson mlinkert removed

There has been work lately on the OME-TIFF reading and writing I think. I don't quite know what's been done nor what's planned but it might be appropriate to include this ticket if there is work on those anyway. Are we sure it's a Bio-Formats problem; maybe a workflow with bfconvert or somesuch also evinces the bug? Is it incorrect to have a tile size larger than image size?

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.380979 sec.)

We're Hiring!