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
Slower performance of JP2KAK in comparison with JP2OpenJPEG. #6976
Comments
What kind of JPEG2000 images you have as source? You probably have kdu_show, what does File - Properties show? Is you image fast to view with kdu_show? |
You should try to isolate things a bit. For example just try with gdal_translate. That said, I've indeed seen (rare) situations where openjpeg can be faster than Kakadu. It all depends on the exact JPEG2000 formulation. |
hmmm it seems like kdu_show is missing ;/ |
Perhaps kdu_show is only for Windows? The name of "kdu_jp2info" feels promising, have you tried it? Alternatively, can you share/make test data? |
btw. |
Hmm it have a problem with lack of libkdu_v83.so shared libraries but it's clear that it's located in a lib directory :/
I guess Gdal is aware of this because:
EDIT:
|
So nothing special in the image. Lossless 8-bit RGB, LRCP progression, with 1024x1024 tiles and includes precincts. Image is fast to use with kdu_show and with QGIS (JP2OpenJPEG). But I noticed now that you are reading JPEG2000 images directly from the cloud through /vsis3/. |
Yup, it is just as you said:
I was kind of hoping that Kakadu would allow me to work with JP2 in a COG way (extracting only a sub-element of the overview, so I wouldn't have to download all of the data). I guess it's just not possible then? |
You are using JPEG2000 in a way that the format is not designed for. If OpenJPEG is faster I would use that. Remote access was planned to happen through the JPIP protocol. But if you have enough interest you may try to reach David Taubman and ask what he thinks about your use case. A long time ago there used to be a user group in Yahoo but all that I found about the community support now is this:
Who knows if JPEG2000 folks will recognize the need for cloud friendly access and develop a new variant for that. They have already made htj2. |
I tried:
here kakadu seems to do better than JPEG @jratike80 @rouault Maybe someone tried before me to combine these? |
Sorry, my knowledge is very outdated. I have been running JPIP server myself when Kakadu had a different license and another JPIP server made by Kodak when the company still had a space division. It was awfully long time ago, I believe that Kodak sold the division in 2004. |
Expected behavior and actual behavior.
I compiled GDAL with the Kakadu library to be able to use JP2KAK for reading my jp2 files. However, contrary to expectations, the JP2KAK driver is slower than OpenJPEG. JP2KAK advantages include the absence of the need to load the entire jp2 file when loading all pixels corresponding to the area of interest and 2x fewer requests (for the same config settings in the mapfile).
Steps to reproduce the problem.
I compiled Kakadu with GDAL as described in this ticket:
OSGeo/gdal#8417
Then, I compiled MapServer with GDAL using:
Afterwards, I deployed MapServer on Kubernetes and created two mapfiles differing in one element: CONFIG "GDAL_SKIP" "JP2KAK". After each request, I deleted the pod and created a new one so that GDAL would not ignore the jp2kak driver in the next request and to be able to read the full log.
Here are the logs:
pod_open.log
pod_kak.log
And here is the mapfile I'm using:
JP2OpenJPEG
[warn] [pid 16] mod_fcgid: stderr: awMap() total time: 4.333s
JP2KAK
[warn] [pid 15] mod_fcgid: stderr: awMap() total time: 9.017s
Operating system / MapServer version and installation method
Docker MapServer version 8.0.1 PROJ version 9.4 GDAL version 3.9 kakadu 8_3
The text was updated successfully, but these errors were encountered: