Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using grok instead of openjp2 with cantaloupe #703

Closed
jonathangreen opened this issue Aug 22, 2017 · 3 comments
Closed

Consider using grok instead of openjp2 with cantaloupe #703

jonathangreen opened this issue Aug 22, 2017 · 3 comments
Assignees

Comments

@jonathangreen
Copy link
Contributor

Idea

Grok is a fork of OpenJP2 that is focusing on performance. I compiled it and it seems to work as a drop in replacement for OpenJP2 as far as Cantaloupe is concerned. I also saw a huge speed improvement using Grok vs OpenJP2 with a 40Mb JP2 file.

Since its not in Ubuntu package management its a little harder to install, but I think we should consider shipping it with our vagrant config because it will make large jp2 with cantaloupe much easier to work with.

Thoughts?

Compile instructions

$ apt install cmake libpng16-dev libtiff-dev liblcms2-dev
$ git clone -b v2.3.0 https://github.com/GrokImageCompression/grok.git
$ cd grok
$ mkdir build
$ cd build
$ cmake ../.
$ make && make install
@DiegoPino
Copy link
Contributor

DiegoPino commented Aug 22, 2017

@jonathangreen and image quality/standard compliance (weird tags, color space incompatibilities, etc)? Do you have some images around to compare? Sounds like a good plan, open version is sloooooow 👍

@jonathangreen
Copy link
Contributor Author

jonathangreen commented Aug 22, 2017

Here are some test results Diego. Thanks for the prod to get some numbers behind this. Turns out my initial tests had caching enabled, so sometimes the image was coming out of the cache. After disabling all caching, the numbers don't look as good, but Grok is a still faster. I don't see any quality difference at all in the output images produced.

It seems to get most of its advantage when:

  • there are multiple cores available
  • we are working with a tile rather then the full image

JP2 I tested with was 40mb, 6851x5601. My output format was jpeg.

OpenJP2

  • Single core
    • full image: 30702 msec
  • Two cores
    • full image: 28912 msec
    • 100x100 tile: 20641 msec
    • 512x512 tile: 20405 msec

Grok

  • Single core
    • full image: 28971 msec
  • Two cores
    • full image: 18852 msec
    • 100x100 tile: 441 msec
    • 512x512 tile: 713 msec

Kakadu

  • Single core
    • full image: 13120 msec
  • Two cores
    • full image: 8914 msec
    • 100x100 tile: 15 msec
    • 512x512 tile: 78 msec

@jonathangreen
Copy link
Contributor Author

Resolved with:
Islandora-Devops/islandora-playbook#2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants