Task #11256 (closed)
Opened 11 years ago
Closed 9 years ago
Bug: Insight rounding error displaying exposure time
| Reported by: | omero-qa | Owned by: | jburel |
|---|---|---|---|
| Priority: | minor | Milestone: | Unscheduled |
| Component: | Insight | Version: | 4.4.8 |
| Keywords: | n.a. | Cc: | m.porter@…, ux@… |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | n.a. |
Description (last modified by rleigh)
https://www.openmicroscopy.org/qa2/qa2/qa/feedback/7445/
Insight displays exposure time incorrectly: Value in .dv: 0.1s Value parsed by bioformats: 1.0000000474974513E-4 (this is wrong, but a separate ticket) Value displayed by insight: 1.1E-4s
There are two issues here:
1) The use of the E-4 notation when 0.00011 would be far more readable.
2) The introduction of a significant (10%) error in the display of the value.
Change History (4)
comment:1 Changed 11 years ago by rleigh
- Component changed from from QA to Insight
- Description modified (diff)
- Summary changed from Bug: Insight rounding error displaying exposure tm to Bug: Insight rounding error displaying exposure time
comment:2 Changed 11 years ago by rleigh
comment:3 Changed 10 years ago by jburel
- Cc ux@… added
comment:4 Changed 9 years ago by dlindner
- Resolution set to fixed
- Status changed from new to closed
Bioformats issue seems to be solved: Original metadata shows 0.1000s
Insight rounding issues fixed by: https://github.com/openmicroscopy/openmicroscopy/pull/4195 (now shows exposure time 100 ms)
Note: See
TracTickets for help on using
tickets.
You may also have a look at Agilo extensions to the ticket.
Note that 2.5000001187436283E-5 is also being rounded to 2.6E-5.
This appears to be done by org.openmicroscopy.shoola.agents.util.EditorUtil?.roundValue() and UIUtilities.roundTwoDecimals.
I don't think that this rounding is *at all* acceptable. The error introduced is significant, and this does not make *any* sense. I could understand rounding to e.g. 3 significant figures. But then you'd get 2.50E-5 or 0.0000250; both are within the floating point precision and don't add 0.1E-5 to the final value (or E-4 for the above example). The rounding function needs to be able to round correctly!
If we just want a fixed number of digits, can't java.text.DecimalFormat? be used directly to provide correctly-rounded and formatted decimal numbers? Alternatively, use of BigDecimal? can be used to correctly round the value to a specified number of significant digits.