Re: [gdal-dev] JPEG2000 via range request

2022-09-12 Thread Martin
Thank you all for your answers. As andy already pointed out, this 
behavior is due to the fact that

openjpeg is not utilizing markers yet when reading JPEG2000 files.
This issue seems to confirm that: 
https://github.com/uclouvain/openjpeg/issues/944


So I tried the JP2ECW-ERDAS driver again with a current ECW version 5.5 
(3.x does not seem to utilize TLMs either), which led to the desired result.
This way, the number of requests can be significantly reduced (~6 for 
one tile).

Still a lot but sufficient for my use case.

I actually wanted to give kakadu a try too but unfortunately the source 
code is needed to build it with gdal (which is not included in the demo).


- Martin

On 26.08.22 18:44, Norman Barker wrote:
I wrote the original jpipkak driver years ago and it a driver I would 
suggest for deprecation but I am no longer involved in j2k development 
to know how much it is being used.


You will need a jpip server to use the jpip client. Wavelets are 
different to cogs and you will get the benefits of progressive display.


Norman


On Fri, Aug 26, 2022, 5:12 PM Kurt Schwehr  wrote:

It costs, but you could try this:

https://gdal.org/drivers/raster/jpipkak.html

I have kakadu, but I have never tried the jpip functionality so I
can't say how well it works.

On Fri, Aug 26, 2022, 5:03 AM Martin
 wrote:

Hi,

I want to process JP2 data via vsicurl. Which works so far.
Unfortunately hundreds of requests are sent, even if only the
data of one tile is required.
I understand that due to the structure of a JP2 file multiple
requests are necessary. But it looks like GDAL is searching
every single tile (resulting in ~120 requests).

Is there a way to reduce the number of requests?

I have already tried the JP2ECW-ERDAS driver, same result.

Do I have to configure GDAL in a certain way?

cmd for request:

    #!/bin/bash

    export GDAL_DISABLE_READDIR_ON_OPEN="YES"
    export CPL_VSIL_CURL_ALLOWED_EXTENSIONS="jp2"
    export CPL_CURL_VERBOSE="YES"
    export GDAL_HTTP_MERGE_CONSECUTIVE_RANGES="YES"

    gdal_translate --debug ON -srcwin 0 0 256 256
/vsicurl/http://localhost:8083/T33UWP_20220515T100031_TCI_10m_J2Lmin.jp2
./out_subWin.tif

What options do I need to specify when creating the JP2 file
to support GDAL?

Currently I use the following options:

#!/bin/bash

    gdal_translate \
        -of JP2OpenJPEG \
    -co QUALITY=100 \
        -co TLM=YES \
    -co PLT=YES \
        -co PROGRESSION=LRCP \
    -co WRITE_METADATA=YES \
../test_data/T33UWP_20220515T100031_TCI_10m.tif \
./T33UWP_20220515T100031_TCI_10m_J2Lmin.jp2

Some logs:

[gdal degug output](https://pastebin.com/vTf7tjLJ)
[nginx logs](https://pastebin.com/8bWW15Tp)
[gdalinfo](https://pastebin.com/HWSmypEQ)
[opj_dump](https://pastebin.com/rdYbHEnY)
[kdu_jp2info](https://pastebin.com/atVUfeVx)

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] JPEG2000 via range request

2022-08-26 Thread Norman Barker
I wrote the original jpipkak driver years ago and it a driver I would
suggest for deprecation but I am no longer involved in j2k development to
know how much it is being used.

You will need a jpip server to use the jpip client. Wavelets are different
to cogs and you will get the benefits of progressive display.

Norman


On Fri, Aug 26, 2022, 5:12 PM Kurt Schwehr  wrote:

> It costs, but you could try this:
>
> https://gdal.org/drivers/raster/jpipkak.html
>
> I have kakadu, but I have never tried the jpip functionality so I can't
> say how well it works.
>
> On Fri, Aug 26, 2022, 5:03 AM Martin 
> wrote:
>
>> Hi,
>>
>> I want to process JP2 data via vsicurl. Which works so far.
>> Unfortunately hundreds of requests are sent, even if only the data of one
>> tile is required.
>> I understand that due to the structure of a JP2 file multiple requests
>> are necessary. But it looks like GDAL is searching every single tile
>> (resulting in ~120 requests).
>>
>> Is there a way to reduce the number of requests?
>>
>> I have already tried the JP2ECW-ERDAS driver, same result.
>>
>> Do I have to configure GDAL in a certain way?
>>
>> cmd for request:
>>
>> #!/bin/bash
>>
>> export GDAL_DISABLE_READDIR_ON_OPEN="YES"
>> export CPL_VSIL_CURL_ALLOWED_EXTENSIONS="jp2"
>> export CPL_CURL_VERBOSE="YES"
>> export GDAL_HTTP_MERGE_CONSECUTIVE_RANGES="YES"
>>
>> gdal_translate --debug ON -srcwin 0 0 256 256 /vsicurl/
>> http://localhost:8083/T33UWP_20220515T100031_TCI_10m_J2Lmin.jp2
>> ./out_subWin.tif
>>
>> What options do I need to specify when creating the JP2 file to support
>> GDAL?
>>
>> Currently I use the following options:
>>
>> #!/bin/bash
>>
>> gdal_translate \
>> -of JP2OpenJPEG \
>> -co QUALITY=100 \
>> -co TLM=YES \
>> -co PLT=YES \
>> -co PROGRESSION=LRCP \
>> -co WRITE_METADATA=YES \
>> ../test_data/T33UWP_20220515T100031_TCI_10m.tif \
>> ./T33UWP_20220515T100031_TCI_10m_J2Lmin.jp2
>>
>> Some logs:
>>
>> [gdal degug output](https://pastebin.com/vTf7tjLJ)
>> [nginx logs](https://pastebin.com/8bWW15Tp)
>> [gdalinfo](https://pastebin.com/HWSmypEQ)
>> [opj_dump](https://pastebin.com/rdYbHEnY)
>> [kdu_jp2info](https://pastebin.com/atVUfeVx)
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] JPEG2000 via range request

2022-08-26 Thread Kurt Schwehr
It costs, but you could try this:

https://gdal.org/drivers/raster/jpipkak.html

I have kakadu, but I have never tried the jpip functionality so I can't say
how well it works.

On Fri, Aug 26, 2022, 5:03 AM Martin  wrote:

> Hi,
>
> I want to process JP2 data via vsicurl. Which works so far.
> Unfortunately hundreds of requests are sent, even if only the data of one
> tile is required.
> I understand that due to the structure of a JP2 file multiple requests are
> necessary. But it looks like GDAL is searching every single tile
> (resulting in ~120 requests).
>
> Is there a way to reduce the number of requests?
>
> I have already tried the JP2ECW-ERDAS driver, same result.
>
> Do I have to configure GDAL in a certain way?
>
> cmd for request:
>
> #!/bin/bash
>
> export GDAL_DISABLE_READDIR_ON_OPEN="YES"
> export CPL_VSIL_CURL_ALLOWED_EXTENSIONS="jp2"
> export CPL_CURL_VERBOSE="YES"
> export GDAL_HTTP_MERGE_CONSECUTIVE_RANGES="YES"
>
> gdal_translate --debug ON -srcwin 0 0 256 256 /vsicurl/
> http://localhost:8083/T33UWP_20220515T100031_TCI_10m_J2Lmin.jp2
> ./out_subWin.tif
>
> What options do I need to specify when creating the JP2 file to support
> GDAL?
>
> Currently I use the following options:
>
> #!/bin/bash
>
> gdal_translate \
> -of JP2OpenJPEG \
> -co QUALITY=100 \
> -co TLM=YES \
> -co PLT=YES \
> -co PROGRESSION=LRCP \
> -co WRITE_METADATA=YES \
> ../test_data/T33UWP_20220515T100031_TCI_10m.tif \
> ./T33UWP_20220515T100031_TCI_10m_J2Lmin.jp2
>
> Some logs:
>
> [gdal degug output](https://pastebin.com/vTf7tjLJ)
> [nginx logs](https://pastebin.com/8bWW15Tp)
> [gdalinfo](https://pastebin.com/HWSmypEQ)
> [opj_dump](https://pastebin.com/rdYbHEnY)
> [kdu_jp2info](https://pastebin.com/atVUfeVx)
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev