Hi,
gdal_translate -of gtiff -co compress=jpeg p4433h.tif -co
NUM_THREADS=ALL_CPUS comp.tif
Time: 4.7 seconds (with GDAL 3.3.0 gisinternals build)
Time: 11.5 seconds (with GDAL 3.1.4 OSGeo4W build)
-Jukka-
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
__
gdal_translate -of gtiff -co compress=jpeg p4433h.tif comp.tif
for the gdal_translate to JPEG compressed TIFF, adding -co
NUM_THREADS=ALL_CPUS should help to keep the comparison fair, and if you
use gisinternal builds, I'm not completely sure they use libjpeg-turbo,
which would bring anoth
Hi Even,
You are right, Kakadu 8.x supports HTJ2K. I just had a try with the
kdu_compress demo utility from KDU805 demo apps. The speed was good,
actually amazing. As a test image I used a 12000x12000 RGB image. The
kdu_compress command I took from this high qualite white-paper
https://htj2k.com/
>
>
> did you bench timings using GDAL API & utilities (typically with
> gdal_translate) ? The ones indicated in the PR use the utilities that come
> which each library, but the integration within a GDAL driver might have
> some influence on the timings.
>
Yes, the timings will definitely be lower
Aaron,
did you bench timings using GDAL API & utilities (typically with
gdal_translate) ? The ones indicated in the PR use the utilities that
come which each library, but the integration within a GDAL driver might
have some influence on the timings.
What about single threaded usage ?
Even
Hi Sean and Even,
Correct, the current JP2Grok does not support the generation of Part 15
code streams.
It's trivial to add, as it just involves adding a new encoding mode, but I
was waiting for a merge
before looking into new driver features.
Also, yes, OpenJPH is being used for the new entropy e
Sean,
my quick look at the JP2Grok driver code is that it doesn't generate the
HTJ2K / Part 15 variant of JPEG2000, at least there's nothing suggesting
that (didn't try running it). I guess that there would be a need for a
dedicated creation option in the driver for that to happen, so there
s
Hi Aaron, and everyone,
It seems like interoperability could be harmed if we release GDAL with a
JP2 driver that writes JPEG 2000 files that the main open source JP2 driver
can't read. Would it make sense to add compatibility to OpenJPEG before the
PR gets merged? Or are we already in a state of
Hi Jean-Roc,
Good question - unfortunately OpenJPEG doesn't currently support HTJ2K,
it only supports JPEG 2000 Part 1. I am sure that this will eventually be
integrated,
but it isn't there at the moment.
Cheers,
Aaron
On Mon, May 3, 2021 at 12:05 PM Jean-Roc Morreale (ml) <
jrmorreale...@enoreth.
Hi Aaron,
Is the HTJ2K's output still readable by a regular GDAL/OpenJPEG ?
Regards,
Jean-Roc Morreale
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi Folks,
I would like to draw people's attention once again to the pending JPEG 2000
driver PR
https://github.com/OSGeo/gdal/pull/3449
which was opened 3 months ago. Since I last posted, the driver now has an
autotest script courtesy of Frank Warmerdam, and all tests are passing.
In a nutshell,
11 matches
Mail list logo
