Task #5092 (new)
Opened 13 years ago
Last modified 11 years ago
Support .ndpi files with width or height > 65500 — at Version 7
| Reported by: | mlinkert | Owned by: | mlinkert |
|---|---|---|---|
| Priority: | critical | Milestone: | Unscheduled |
| Component: | Bio-Formats | Version: | n.a. |
| Keywords: | n.a. | Cc: | philippe.mailly@…, smithd@…, taewooko@…, andreas.dander@…, Richard.Ingram@…, qn.trinh-xuan@…, kim.linton@…, anitha.kannan@… |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | 5.0d |
| Sprint: | n.a. |
Description (last modified by mlinkert)
Many .ndpi files contain JPEG streams that have a width and/or height larger than 65500 (the maximum size supported by Java's JPEG decoder. The maximum size allowed in the JPEG specification is 65535, and it is not uncommon to have .ndpi files that contain much larger images.
After some investigation, it looks like Hamamatsu has written their very own JPEG encoder/decoder to work around the limitations in the JPEG specification, as no other decoder that I can find actually supports this.
A lot of investigation has already gone into this ticket, and given the scope of work required I don't see it happening for 4.3.
When we finally do have time to sort this out, the plan is roughly:
1) See if there is a way to strip off the dimension information and just read all of the tiles using Java's built-in JPEG support. We can then re-pack the tiles using the dimension information stored in the .ndpi file.
2) Failing (1), see if we can write our own Java interface to the JPEG native libraries included with the JRE that would accomplish the same thing as (1).
3) If neither (1) nor (2) work, we'll need to write our own baseline JPEG decoder that allows the image dimensions to be overridden.
Change History (7)
comment:1 Changed 13 years ago by Melissa Linkert <melissa@…>
comment:2 Changed 13 years ago by Melissa Linkert <melissa@…>
(In [de977aa84dffe5a14583689bfbd5d57703192290/bioformats.git]) Prevent errors for .ndpi files that use a DNL marker.
See #5092. The problem now is what to do about images which have a
width or height > 65535 (the maximum width and height allowed in a JPEG
stream).
comment:3 Changed 13 years ago by Melissa Linkert <melissa@…>
(In [de977aa84dffe5a14583689bfbd5d57703192290/bioformats.git]) Prevent errors for .ndpi files that use a DNL marker.
See #5092. The problem now is what to do about images which have a
width or height > 65535 (the maximum width and height allowed in a JPEG
stream).
comment:4 Changed 13 years ago by mlinkert
- Cc philippe.mailly@… added
- Description modified (diff)
- Sprint changed from 2011-05-05 (11) to 2011-05-19 (12)
- Summary changed from Update JIMI service to handle JPEG streams with DNL markers to Update tile-based JPEG decoder to handle images that are too large
comment:5 Changed 13 years ago by mlinkert
- Cc smithd@… added
comment:6 Changed 13 years ago by mlinkert
- Summary changed from Update tile-based JPEG decoder to handle images that are too large to BUG: Update tile-based JPEG decoder to handle images that are too large
comment:7 Changed 13 years ago by mlinkert
- Description modified (diff)
- Milestone changed from OMERO-Beta4.3 to Unscheduled
- Remaining Time changed from 1 to 5
- Sprint 2011-05-19 (12) deleted
- Summary changed from BUG: Update tile-based JPEG decoder to handle images that are too large to Support .ndpi files with width or height > 65500
(In [4d346e2b279677ec57d6d443833762f6abeb4fe7/bioformats.git]) Prevent errors for .ndpi files that use a DNL marker.
See #5092. The problem now is what to do about images which have a
width or height > 65535 (the maximum width and height allowed in a JPEG
stream).