walkero
/
openjpeg
1
0
Fork 0
Code Issues Pull Requests Projects Releases 1 Wiki Activity

post update

This commit is contained in:
Antonin Descampe 2017-10-05 00:09:31 -03:00
parent 7d473a059c
commit 620e54e5f0
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
_posts/2017-10-04-OpenJPEG-2.3.0-released.md
View File

@ -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.
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.
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 single-thread 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 there are many variables that can influence the results: so if you are an OpenJPEG user, please download and try this new release within your workflow ... 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:
- [Wellcome Library](https://wellcomelibrary.org/)
@ -31,6 +31,8 @@ Enjoy,
Antonin
More info:
[News](https://github.com/uclouvain/openjpeg/blob/v2.2.0/NEWS.md)
[Changelog](https://github.com/uclouvain/openjpeg/blob/v2.2.0/CHANGELOG.md)