fix the release post
This commit is contained in:
parent
712a73913d
commit
213e731fb2
|
@ -12,9 +12,9 @@ This new release finalizes the work made by Even Rouault and funded by several a
|
||||||
|
|
||||||
In addition to what has been done in v2.2.0 (multithreading at decoding, speed optimizations, memory consumption reduction, etc, see [this post](http://www.openjpeg.org/2017/08/10/OpenJPEG-2.2.0-released) for details), this release adds improvement to sub-tile decoding. Now when you handle a huge single tile image and only wants to decode a small part of it, only the window of interest is actually processed: sounds quite natural but I can ensure it wasn't that easy to implement. This leads to drastic speed and memory improvements as they only depend now on the size of the window and not on the original image size. This release also adds the ability to decode only a subset of components.
|
In addition to what has been done in v2.2.0 (multithreading at decoding, speed optimizations, memory consumption reduction, etc, see [this post](http://www.openjpeg.org/2017/08/10/OpenJPEG-2.2.0-released) for details), this release adds improvement to sub-tile decoding. Now when you handle a huge single tile image and only wants to decode a small part of it, only the window of interest is actually processed: sounds quite natural but I can ensure it wasn't that easy to implement. This leads to drastic speed and memory improvements as they only depend now on the size of the window and not on the original image size. This release also adds the ability to decode only a subset of components.
|
||||||
|
|
||||||
Overall, if we compare performances of OpenJPEG before all Even's optimizations (v2.1.2) and the ones reached by the new v2.3.0 release, we observe a **55-60% speed improvement** on whole image decoding (even more on big images like 10000x10000). Memory consumption is also drastically reduced on mega-image decoding: for example, for a full decoding of a single tile 8000x120000 image, it is reduced from 2 to 1.3 GB RAM. But more importantly, OpenJPEG is now a workable solution for workflows involving partial decoding.
|
Overall, if we compare performances of OpenJPEG before all Even's optimizations (v2.1.2) and the ones reached by the new v2.3.0 release, we observe a **55-60% speed improvement** on whole image decoding (even more on big images like 10000x10000). Memory consumption is also drastically reduced on mega-image decoding: for example, for a full decoding of a single tile 8000x12000 image, it is reduced from 2 to 1.3 GB RAM. But more importantly, OpenJPEG is now a workable solution for workflows involving partial decoding.
|
||||||
|
|
||||||
**Benchmarks are hard to compare as they are many variables that can influence the results: so if you are an OpenJPEG user, please download and try this new release within your workflows ... And share your feedback, that would be highly appreciated.**
|
Benchmarks are hard to compare as they are many variables that can influence the results: so if you are an OpenJPEG user, please download and try this new release within your workflows ... And share your feedback, that would be highly appreciated.
|
||||||
|
|
||||||
Last but not least, and as indicated above and described in a [previous post](http://www.openjpeg.org/2017/04/27/Faster-OpenJPEG-is-on-track), all this has been made possible thanks to a funding from academic institutions and archival organizations, namely:
|
Last but not least, and as indicated above and described in a [previous post](http://www.openjpeg.org/2017/04/27/Faster-OpenJPEG-is-on-track), all this has been made possible thanks to a funding from academic institutions and archival organizations, namely:
|
||||||
- [Wellcome Library](https://wellcomelibrary.org/)
|
- [Wellcome Library](https://wellcomelibrary.org/)
|
||||||
|
|
Loading…
Reference in New Issue