Summary: | opj_tcd_decode_tile() allocates wastefully compared to luratech. | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Julian Smith <julian.smith> |
Component: | JPX/JBIG2 encode/decode | Assignee: | Sebastian Rasmussen <sebastian.rasmussen> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | sebastian.rasmussen |
Priority: | P2 | ||
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Customer: | Word Size: | --- |
Description
Julian Smith
2020-02-05 17:59:56 UTC
*** Bug 702095 has been marked as a duplicate of this bug. *** *** Bug 702094 has been marked as a duplicate of this bug. *** *** Bug 702093 has been marked as a duplicate of this bug. *** *** Bug 702092 has been marked as a duplicate of this bug. *** *** Bug 702091 has been marked as a duplicate of this bug. *** Assigning to Henry to determine who should do this (and when), possibly after discussion at an engineering meeting. Why not request an enhancement upstream? For us to do this optimization would be a fair bit of work. I have reported this upstream, let's see what they say: https://github.com/uclouvain/openjpeg/issues/1252 > let's see what they say:
Their immediate response was as follows:
"Intermediate computation need more than 8 bits. Probably 16 bits is enough, but some research in JPEG2000 reference literature should be done to confirm it. And OpenJPEG supports also 16-bit images, which would thus needs 32 bits. Not to mention irreversible which use float32 intermediate computations. So we'd need to have two code paths, or use some templating code (switching to C++) to avoid hugly macros. That would be a really non trivial effort !"
Julian remarked that it is surprising that they don't think more than 32bpp intermediate results are necessary for 32bpp images.
|