Re: [gdal-dev] Long Term Prognosis for JPEG 2000

[Brad Hards]

I agree that JP2 usage is likely to continue for a long time. One of the key 
differentiators is the ability to support higher bit depth. 

 

However I don’t see it being as popular for new applications in the same way. 
It feels like there is a push / shift to “something newer”, and that (to me) 
looks like HEIF with AV1. There are definitely options on both the file format 
side – a newer GeoTIFF / COG or MXF could also be candidates; and on the codec 
side (especially for HEVC aka H.265). That movement is likely 5+ years though, 
unless something disruptive happens in sensing.

 

For “non-display” purposes, where the primary use is analysis rather than 
visualisation, I think there will be increasing desire to keep the source 
values (potentially floating point) – maybe a point cloud of LIDAR, or data 
cube of hyperspectral imagery.  That looks like HDF5 at the moment, although 
maybe the back-end format and compression matters less than the access approach.

Difficult to see advanced codecs making much progress here. 

 

Brad

 

From: gdal-dev  On Behalf Of Kurt Schwehr
Sent: Wednesday, 31 March 2021 3:12 AM
To: Aaron Boxer 
Cc: gdal dev 
Subject: Re: [gdal-dev] Long Term Prognosis for JPEG 2000

 

Jp2k is likely to continue with heavy use for a long time to come.  There are 
lots of hardware encoders in our solar system and the existing base of data in 
that format is massive.  And with the improvements in Openjpeg, it's support 
seems viable.  It's not the first choice for most, but that's okay.

 

On Mon, Mar 29, 2021, 7:22 AM Aaron Boxer mailto:boxe...@gmail.com> > wrote:

Hello There,

I'm curious what folks here think about the future of JPEG 2000 in geospatial?

I was having a little discussion about this over here:

https://github.com/USGS-Astrogeology/ISIS3/issues/4237

 

To me, the features that made JP2 unique amongst the many codecs were:

 

0. royalty free

1. support for lossy and lossless compression in a single framework

2. support for TB images

3. fast on-the-fly random access into large images

4. decoder can determine what sort of progression it uses at decode time: 
resolution,

quality, component or spatial.

5. precise rate control

6. error and re-compression resilience

7. JPIP protocol for progressive transmission over low-bandwidth networks

 

The cons to JP2 were:

 

0. computational complexity i.e. dog slow

1. (until recently) buggy and slow OSS implementations

2. patent questions (largely resolved)

3. poor support from HW and browsers

 

Do you think there is currently a viable alternative which covers enough of the 
advantages while lacking enough of the negatives that plague JP2 ?  I'm curious 
because I have been devoting quite a bit of time to addressing some of those 
negatives, as discussed at length previously,

The standard remains essential in digital cinema, medical imaging and in the 
archive community. But, those last two fields may also be ripe for change.

 

In digital cinema, precise rate control is a must, so I think it is here to 
stay in the area.

 

Thanks,

Aaron

 

 

 

___
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] More info on gdalwarp resampling methods?

[Matt.Wilkie]

Hi folks,

I'm seeking more information on the various gdalwarp resampling methods, the 
scenarios where they are most usefully applied, and the converse: where they 
should not be used. It would be especially helpful if there were also visuals. 
For example I know what min/max/median are when working with a list of numbers 
but my understanding of what they do when applied to rasters of various types 
is quite hazy.


Background: I'm getting error messages when trying to use some of the methods 
with 16bit imagery and I don't know if I'm seeing a gdal bug, a data bug, or 
just "you can't use that method with this raster type".

ERROR 1: Failed to acquire WarpMutex in WarpRegion().

Thanks!

Matt Wilkie
Geomatics Analyst
Environment | Technology, Innovation and Mapping
T 867-667-8133 | Yukon.ca
Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.

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

Re: [gdal-dev] gdalbuildvrt and band descriptions

[Matt.Wilkie]

Done!

Enable gdalbuildvrt to retain metadata such as band description
https://github.com/OSGeo/gdal/issues/3627

-Matt

From: Even Rouault 
Sent: March 26, 2021 5:09 PM
To: Matt.Wilkie ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] gdalbuildvrt and band descriptions

Matt,

copying over band description (and other band metadata) in the -separate case 
would make sense. Please file an enhancement ticket about that

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

Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in data loss.

[Hays Barrett]

Will do. 
Thanks! 


From: "Even Rouault"  
To: "Rahkonen Jukka (MML)" , "hays" 
 
Cc: gdal-dev@lists.osgeo.org 
Sent: Tuesday, March 30, 2021 11:12:38 AM 
Subject: Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result 
in data loss. 



Jukka' suggestion is a good one. Using -tps solver or affine approximation 
-order 1 fixes the issue. The default behaviour with GCPs when there are 6 or 
more of them is to use the second order polynomial adjustment. The issue here 
is when computing output bounds. We actually compute two 2nd order polynomial 
adjustments: one from source image coordinates to georeferenced ones, and one 
from georeferenced ones to source image. The former one is used to compute the 
output bounds, but the second one is used to do warping. The issue with 2nd 
order polynomial is that those two transformers are generally not the inverse 
of each other... We should likely compute the source image coordinates -> 
georeferenced coordinates as an iterative inversion of the other one, so they 
are invertible. The first order polynomial / affine transformation hasn't that 
issue due to how affine transformation works. The TPS one isn't likely 
perfectly invertible but TPS transformation is guaranteed to be exact at GCPs, 
so that diminishes the effect. But 2nd order polynomial has overshoots 
particularities that can cause the issue observed. 

Another workaround is to specify the desired output bounds with -te 


Anyway, Hays, could you file an issue about that in [ 
https://github.com/OSGeo/gdal/issues | https://github.com/OSGeo/gdal/issues ] , 
ideally copying over your web page (or pointing to it if it can remain stable), 
and pasting my above comment. 

Even 
Le 30/03/2021 à 18:51, Rahkonen Jukka (MML) a écrit : 





Hi, 



I did not have a close look into your ground control points but perhaps they 
are not very well distributed and therefore the default warping algorithm eats 
one corner of the image. Have a try with thin plate splin (-tps) instead. There 
may be some bug, it does not feel right that some source data are lost with 
default algorithm. 



-Jukka Rahkonen- 






Lähettäjä: Hays Barrett [ mailto:hays.barr...@gmail.com | 
 ] 
Lähetetty: tiistai 30. maaliskuuta 2021 19.32 
Vastaanottaja: Rahkonen Jukka (MML) [ 
mailto:jukka.rahko...@maanmittauslaitos.fi | 
 ] 
Kopio: [ mailto:gdal-dev@lists.osgeo.org | gdal-dev@lists.osgeo.org ] 
Aihe: Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in 
data loss. 





I put together a page that better explains the issue and used one of the actual 
images from our project. 


[ https://haysbarrett.com/gdal_translate/ | 
https://haysbarrett.com/gdal_translate/ ] 


Thanks for looking into this for me. 


-Hays 





On Fri, Mar 26, 2021 at 2:59 PM jratike80 < [ 
mailto:jukka.rahko...@maanmittauslaitos.fi | 
jukka.rahko...@maanmittauslaitos.fi ] > wrote: 

BQ_BEGIN


Hi, 

Please give an exact example. Preferably with a raster that can be created 
from command line with gdal_create followed by other required commands. Or 
alternatively Python code that re-produces the issue. 

-Jukka Rahkonen- 



Hays Barrett wrote 
> If the gcps stretch the image beyond the dimensions of the original raster 
> it appears to clip the data that sits outside of the original raster 
> dimensions rather than increase the raster dimensions to fit the stretched 
> data . 
> Is this the expected behavior? 
> If so is there a way to increase the dimensions of a raster so there is no 
> data loss? 
> Thanks, 
> -Hays 
> 
> ___ 
> gdal-dev mailing list 

> [ mailto:gdal-dev@.osgeo | gdal-dev@.osgeo ] 

> [ https://lists.osgeo.org/mailman/listinfo/gdal-dev | 
> https://lists.osgeo.org/mailman/listinfo/gdal-dev ] 





-- 
Sent from: [ http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html | 
http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ] 
___ 
gdal-dev mailing list 
[ mailto:gdal-dev@lists.osgeo.org | gdal-dev@lists.osgeo.org ] 
[ https://lists.osgeo.org/mailman/listinfo/gdal-dev | 
https://lists.osgeo.org/mailman/listinfo/gdal-dev ] 



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

BQ_END

-- [ http://www.spatialys.com/ | http://www.spatialys.com ] My software is 
free, but my time generally not. 

___ 
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] Adding gcps to a raster using gdal_translate can result in data loss.

[Even Rouault]

Jukka' suggestion is a good one. Using -tps solver or affine 
approximation -order 1 fixes the issue. The default behaviour with GCPs 
when there are 6 or more of them is to use the second order polynomial 
adjustment. The issue here is when computing output bounds. We actually 
compute two 2nd order polynomial adjustments: one from source image 
coordinates to georeferenced ones, and one from georeferenced ones to 
source image. The former one is used to compute the output bounds, but 
the second one is used to do warping. The issue with 2nd order 
polynomial is that those two transformers are generally not the inverse 
of each other... We should likely compute the source image coordinates 
-> georeferenced coordinates as an iterative inversion of the other one, 
so they are invertible. The first order polynomial / affine 
transformation hasn't that issue due to how affine transformation works. 
The TPS one isn't likely perfectly invertible but TPS transformation is  
guaranteed to be exact at GCPs, so that diminishes the effect. But 2nd 
order polynomial has overshoots particularities that can cause the issue 
observed.


Another workaround is to specify the desired output bounds with -te

Anyway, Hays, could you file an issue about that in 
https://github.com/OSGeo/gdal/issues, ideally copying over your web page 
(or pointing to it if it can remain stable), and pasting my above comment.


Even

Le 30/03/2021 à 18:51, Rahkonen Jukka (MML) a écrit :


Hi,

I did not have a close look into your ground control points but 
perhaps they are not very well distributed and therefore the default 
warping algorithm eats one corner of the image. Have a try with thin 
plate splin (-tps) instead.  There may be some bug, it does not feel 
right that some source data are lost with default algorithm.


-Jukka Rahkonen-

*Lähettäjä:*Hays Barrett 
*Lähetetty:* tiistai 30. maaliskuuta 2021 19.32
*Vastaanottaja:* Rahkonen Jukka (MML) 


*Kopio:* gdal-dev@lists.osgeo.org
*Aihe:* Re: [gdal-dev] Adding gcps to a raster using gdal_translate 
can result in data loss.


I put together a page that better explains the issue and used one 
of the actual images from our project.


https://haysbarrett.com/gdal_translate/ 



Thanks for looking into this for me.

-Hays

On Fri, Mar 26, 2021 at 2:59 PM jratike80 
> wrote:


Hi,

Please give an exact example. Preferably with a raster that can be
created
from command line with gdal_create followed by other required
commands. Or
alternatively Python code that re-produces the issue.

-Jukka Rahkonen-



Hays Barrett wrote
> If the gcps stretch the image beyond the dimensions of the
original raster
> it appears to clip the data that sits outside of the original raster
> dimensions rather than increase the raster dimensions to fit the
stretched
> data .
> Is this the expected behavior?
> If so is there a way to increase the dimensions of a raster so
there is no
> data loss?
> Thanks,
> -Hays
>
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo 

> https://lists.osgeo.org/mailman/listinfo/gdal-dev






--
Sent from:
http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html

___
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


--
http://www.spatialys.com
My software is free, but my time generally not.

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

Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in data loss.

[Rahkonen Jukka (MML)]

Hi,

I did not have a close look into your ground control points but perhaps they 
are not very well distributed and therefore the default warping algorithm eats 
one corner of the image. Have a try with thin plate splin (-tps) instead.  
There may be some bug, it does not feel right that some source data are lost 
with default algorithm.

-Jukka Rahkonen-


Lähettäjä: Hays Barrett 
Lähetetty: tiistai 30. maaliskuuta 2021 19.32
Vastaanottaja: Rahkonen Jukka (MML) 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in 
data loss.

I put together a page that better explains the issue and used one of the actual 
images from our project.
https://haysbarrett.com/gdal_translate/
Thanks for looking into this for me.
-Hays

On Fri, Mar 26, 2021 at 2:59 PM jratike80 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Please give an exact example. Preferably with a raster that can be created
from command line with gdal_create followed by other required commands. Or
alternatively Python code that re-produces the issue.

-Jukka Rahkonen-



Hays Barrett wrote
> If the gcps stretch the image beyond the dimensions of the original raster
> it appears to clip the data that sits outside of the original raster
> dimensions rather than increase the raster dimensions to fit the stretched
> data .
> Is this the expected behavior?
> If so is there a way to increase the dimensions of a raster so there is no
> data loss?
> Thanks,
> -Hays
>
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
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] Adding gcps to a raster using gdal_translate can result in data loss.

[Hays Barrett]

I put together a page that better explains the issue and used one of the actual 
images from our project.
https://haysbarrett.com/gdal_translate/
Thanks for looking into this for me.
-Hays

- Original Message -
From: "jratike80" 
To: gdal-dev@lists.osgeo.org
Sent: Friday, March 26, 2021 2:59:36 PM
Subject: Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result 
in data loss.

Hi,

Please give an exact example. Preferably with a raster that can be created
from command line with gdal_create followed by other required commands. Or
alternatively Python code that re-produces the issue.

-Jukka Rahkonen-



Hays Barrett wrote
> If the gcps stretch the image beyond the dimensions of the original raster
> it appears to clip the data that sits outside of the original raster
> dimensions rather than increase the raster dimensions to fit the stretched
> data . 
> Is this the expected behavior? 
> If so is there a way to increase the dimensions of a raster so there is no
> data loss? 
> Thanks, 
> -Hays 
> 
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
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] Long Term Prognosis for JPEG 2000

[Kurt Schwehr]

One downside in the jpeg2000 ecosystem that I have to call out:

Kakadu doesn't come with any tests unit tests.  I tried to donate some
simple starter tests, but no luck getting traction.  :(

On Tue, Mar 30, 2021, 9:11 AM Kurt Schwehr  wrote:

> Jp2k is likely to continue with heavy use for a long time to come.  There
> are lots of hardware encoders in our solar system and the existing base of
> data in that format is massive.  And with the improvements in Openjpeg,
> it's support seems viable.  It's not the first choice for most, but that's
> okay.
>
> On Mon, Mar 29, 2021, 7:22 AM Aaron Boxer  wrote:
>
>> Hello There,
>> I'm curious what folks here think about the future of JPEG 2000 in
>> geospatial?
>> I was having a little discussion about this over here:
>> https://github.com/USGS-Astrogeology/ISIS3/issues/4237
>>
>> To me, the features that made JP2 unique amongst the many codecs were:
>>
>> 0. royalty free
>> 1. support for lossy and lossless compression in a single framework
>> 2. support for TB images
>> 3. fast on-the-fly random access into large images
>> 4. decoder can determine what sort of progression it uses at decode time:
>> resolution,
>> quality, component or spatial.
>> 5. precise rate control
>> 6. error and re-compression resilience
>> 7. JPIP protocol for progressive transmission over low-bandwidth networks
>>
>> The cons to JP2 were:
>>
>> 0. computational complexity i.e. dog slow
>> 1. (until recently) buggy and slow OSS implementations
>> 2. patent questions (largely resolved)
>> 3. poor support from HW and browsers
>>
>> Do you think there is currently a viable alternative which covers enough
>> of the advantages while lacking enough of the negatives that plague JP2 ?
>> I'm curious because I have been devoting quite a bit of time to addressing
>> some of those negatives, as discussed at length previously,
>> The standard remains essential in digital cinema, medical imaging and in
>> the archive community. But, those last two fields may also be ripe for
>> change.
>>
>> In digital cinema, precise rate control is a must, so I think it is here
>> to stay in the area.
>>
>> Thanks,
>> Aaron
>>
>>
>>
>> ___
>> 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] Long Term Prognosis for JPEG 2000

[Kurt Schwehr]

Jp2k is likely to continue with heavy use for a long time to come.  There
are lots of hardware encoders in our solar system and the existing base of
data in that format is massive.  And with the improvements in Openjpeg,
it's support seems viable.  It's not the first choice for most, but that's
okay.

On Mon, Mar 29, 2021, 7:22 AM Aaron Boxer  wrote:

> Hello There,
> I'm curious what folks here think about the future of JPEG 2000 in
> geospatial?
> I was having a little discussion about this over here:
> https://github.com/USGS-Astrogeology/ISIS3/issues/4237
>
> To me, the features that made JP2 unique amongst the many codecs were:
>
> 0. royalty free
> 1. support for lossy and lossless compression in a single framework
> 2. support for TB images
> 3. fast on-the-fly random access into large images
> 4. decoder can determine what sort of progression it uses at decode time:
> resolution,
> quality, component or spatial.
> 5. precise rate control
> 6. error and re-compression resilience
> 7. JPIP protocol for progressive transmission over low-bandwidth networks
>
> The cons to JP2 were:
>
> 0. computational complexity i.e. dog slow
> 1. (until recently) buggy and slow OSS implementations
> 2. patent questions (largely resolved)
> 3. poor support from HW and browsers
>
> Do you think there is currently a viable alternative which covers enough
> of the advantages while lacking enough of the negatives that plague JP2 ?
> I'm curious because I have been devoting quite a bit of time to addressing
> some of those negatives, as discussed at length previously,
> The standard remains essential in digital cinema, medical imaging and in
> the archive community. But, those last two fields may also be ripe for
> change.
>
> In digital cinema, precise rate control is a must, so I think it is here
> to stay in the area.
>
> Thanks,
> Aaron
>
>
>
> ___
> 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] Long Term Prognosis for JPEG 2000

[Marty J. Sullivan]

I’m not sure I’ve run into an issue with 16383x16383 yet other than when I was 
just experimenting with WEBP. As Jeremy mentioned, we are using COG in 
practice, where tiles are generally very small (512x512). I haven’t noticed any 
artifacts in the COGs I’ve created on the tile boundaries. I generally use 
level 95 for lossy compression so maybe if I used higher compression I could 
potentially start to see that.

With such small tiles, and several overviews, decoding COG is generally not an 
issue and you can quickly pull out as small or as large of an area as you like 
with GDAL.

It seems like if you’re using a traditional image in a desktop application, 
using JP2 might have a few advantages, but for network optimized access and 
web/browser support, WEBP is the clear winner for me.

Marty

From: Aaron Boxer 
Date: Monday, March 29, 2021 at 1:59 PM
To: "Marty J. Sullivan" 
Cc: gdal dev 
Subject: Re: [gdal-dev] Long Term Prognosis for JPEG 2000

On Mon, Mar 29, 2021 at 12:12 PM Marty J. Sullivan 
mailto:marty.sulli...@cornell.edu>> wrote:
Just my two cents, I have very little personal use of JP2 although I’ve 
experimented with it in the past.

I personally have switched to using WEBP and have not run into any issues 
(other than wide support). I think the one place JP2 beats WEBP is that JP2 
supports virtually unlimited image dimensions whereas WEBP is limited to 16383 
x 16383. Then again, with GeoTIFF tiling, this is pretty much a non-issue.

16383 x 16383 sounds a bit limited. Even if you use tiling, if your compression 
is lossy then you will see artifacts at the tile boundaries.


AVIF is also up and coming and superior to WEBP, so I’d imagine we’ll see 
support for that someday in GDAL as well. It supports larger image dimensions 
than WEBP (65536x65536)

With that in mind, I personally would never choose to use JP2 at this point, 
but maybe there are other use-cases I’m unaware of.

The problem with larger dimensions  in WebP is the impossibility of decoding a 
sub window in the image. You are forced to do
a complete decode each time you view it.



Marty

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> on 
behalf of Aaron Boxer mailto:boxe...@gmail.com>>
Date: Monday, March 29, 2021 at 10:22 AM
To: gdal dev mailto:gdal-dev@lists.osgeo.org>>
Subject: [gdal-dev] Long Term Prognosis for JPEG 2000

Hello There,
I'm curious what folks here think about the future of JPEG 2000 in geospatial?
I was having a little discussion about this over here:
https://github.com/USGS-Astrogeology/ISIS3/issues/4237

To me, the features that made JP2 unique amongst the many codecs were:

0. royalty free
1. support for lossy and lossless compression in a single framework
2. support for TB images
3. fast on-the-fly random access into large images
4. decoder can determine what sort of progression it uses at decode time: 
resolution,
quality, component or spatial.
5. precise rate control
6. error and re-compression resilience
7. JPIP protocol for progressive transmission over low-bandwidth networks

The cons to JP2 were:

0. computational complexity i.e. dog slow
1. (until recently) buggy and slow OSS implementations
2. patent questions (largely resolved)
3. poor support from HW and browsers

Do you think there is currently a viable alternative which covers enough of the 
advantages while lacking enough of the negatives that plague JP2 ?  I'm curious 
because I have been devoting quite a bit of time to addressing some of those 
negatives, as discussed at length previously,
The standard remains essential in digital cinema, medical imaging and in the 
archive community. But, those last two fields may also be ripe for change.

In digital cinema, precise rate control is a must, so I think it is here to 
stay in the area.

Thanks,
Aaron



___
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] Gdal Java

[Jürgen E . Fischer]

Hi Paul,

On Tue, 30. Mar 2021 at 06:45:14 +, paul.m...@lfv.se wrote:
> C:\>gdalinfo --version
> ERROR 1: Can't load requested DLL: C:\Program 
> Files\Gdal_321\bin\gdal\plugins\gdal_GEOR.dll
> 126: It is not possible to find the specified module.
> 
> ERROR 1: Can't load requested DLL: C:\Program 
> Files\Gdal_321\bin\gdal\plugins\gdal_GEOR.dll
> 126: It is not possible to find the specified module.
> 
> ERROR 1: Can't load requested DLL: C:\Program 
> Files\Gdal_321\bin\gdal\plugins\ogr_OCI.dll
> 126: It is not possible to find the specified module.
> 
> ERROR 1: Can't load requested DLL: C:\Program 
> Files\Gdal_321\bin\gdal\plugins\ogr_OCI.dll
> 126: It is not possible to find the specified module.

Those plugins depend on Oracle DLLs.  You can remove them if you don't need
Oracle.


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden  https://www.norbit.de


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

[gdal-dev] Gdal Java

[paul.malm]

Hi stefan,
I have not come any further...
I have copied gdalalljni.dll to C:\Program 
Files\OpenJDK\jdk-8.0.262.10-hotspot\jre\bin
And I have set the following environment variables:
GDAL_DATA=C:\Program Files\Gdal_321\bin\gdal-data
GDAL_DRIVER_PATH=C:\Program Files\Gdal_321\bin\gdal\plugins
JAVA_HOME=C:\Program Files\OpenJDK\jdk-8.0.262.10-hotspot\
Path=...C:\Program Files\OpenJDK\jdk-8.0.262.10-hotspot\jre\bin;
  C:\Program Files\Gdal_321\bin\gdal\java;
  C:\Program Files\Gdal_321\bin;
  C:\Program Files\Gdal_321;
  C:\Program Files\Gdal_321\bin\gdal\apps;

And when I run gdalinfo - version, I get the following messages:
C:\>gdalinfo --version
ERROR 1: Can't load requested DLL: C:\Program 
Files\Gdal_321\bin\gdal\plugins\gdal_GEOR.dll
126: It is not possible to find the specified module.

ERROR 1: Can't load requested DLL: C:\Program 
Files\Gdal_321\bin\gdal\plugins\gdal_GEOR.dll
126: It is not possible to find the specified module.

ERROR 1: Can't load requested DLL: C:\Program 
Files\Gdal_321\bin\gdal\plugins\ogr_OCI.dll
126: It is not possible to find the specified module.

ERROR 1: Can't load requested DLL: C:\Program 
Files\Gdal_321\bin\gdal\plugins\ogr_OCI.dll
126: It is not possible to find the specified module.

GDAL 3.2.1, released 2020/12/29

Any ideas?
Kind regards,
Paul

Från: Malm, Paul (Operations AIM)
Skickat: den 25 mars 2021 10:38
Till: 'Stefan Moebius' ; gdal-dev@lists.osgeo.org
Ämne: SV: Gdal Java

Hi Stefan,
Thanks for responding on my guestion for help!

-I've downloaded release-1928-x64-gdal-3-2-1-mapserver-7-6-2.zip
and unzipped it to C:\Program Files\Gdal_321.
-Then I added to the system path:
C:\Program Files\Gdal_321\bin\gdal\java and C:\Program Files\Gdal_321\bin.
-Restarted the computer.
Entered Eclipse.
-Set the Class-path to C:\Program Files\Gdal_321\bin\gdal\java\gdal.jar
-Run a simple java program with the commands:
gdalJNI jni= new gdalJNI();
if(jni.HasThreadSupport())
...

The error code I get is:
Native library load failed.
java.lang.UnsatisfiedLinkError: no gdalalljni in java.library.path
Exception in thread "main" java.lang.UnsatisfiedLinkError: 
org.gdal.gdal.gdalJNI.HasThreadSupport()I
at org.gdal.gdal.gdalJNI.HasThreadSupport(Native Method)
at 
org.geotools.jdbcconnection.raster.TransformRaster.(TransformRaster.java:64)
at 
org.geotools.jdbcconnection.raster.TransformRaster.main(TransformRaster.java:51)


Then I copy the gdalalljni.dll to C:\Program 
Files\OpenJDK\jdk-8.0.262.10-hotspot\jre\bin\
And gets the following error code:
Native library load failed.
java.lang.UnsatisfiedLinkError: C:\Program 
Files\OpenJDK\jdk-8.0.262.10-hotspot\jre\bin\gdalalljni.dll: Det går inte att 
hitta den angivna proceduren
Exception in thread "main" java.lang.UnsatisfiedLinkError: 
org.gdal.gdal.gdalJNI.HasThreadSupport()I
at org.gdal.gdal.gdalJNI.HasThreadSupport(Native Method)


Both GDAL and Java are windows x64.
I would be more then grateful for further help.
/Paul

Från: gdal-dev  För Stefan Moebius via 
gdal-dev
Skickat: den 24 mars 2021 09:42
Till: gdal-dev@lists.osgeo.org
Ämne: Re: [gdal-dev] Gdal Java


Klicka bara på länkar och öppna bilagor om du litar på avsändaren och vet att 
innehållet är säkert.
Hi Paul,
I find the binaries provided at 
https://url11.mailanyone.net/v1/?m=1lOzCg-0001ww-4L=57e1b682=9fNL_OAF8vCIgrjZs9aaEB2UNNImM6gI8GCzoqAnKNimVVkylHGA07tBJv6IOWRHGmUKKXljttalb7-9fSKoJRXHVHgZZReNymWKG_G2PNsxEfzkrdsDLJ5OCUF6GOAknKU4asXym3XgQgeOGIjYq6tb5x-KYwQMeTZwonVcJUyaCE6P24h0b-tnGHxFOYo8tTg_FMbjprD8DaPQsY7871SA4Agmh43T_JQ3BjKFdtcr_ELXZdLivAPNafJvPSW6
 the easiest to use. If you click on one build, e.g. 
release-1928-x64-gdal-3-2-1-mapserver-7-6-2, you get a number of download 
options, including several installers. If you use the first one (Compiled 
binaries in a single .zip package), you get an archive which you need to 
extract, and which contains a folder bin\gdal\java. In there you find gdal.jar 
and gdalalljni.dll. Now in order to use this, you need to have

  *   Gdal.jar in your Java Classpath
  *   The extracted bin\gdal\java and bin folders in your Path (in Eclipse: Run 
Configuration -> Environment -> Select -> Path, then edit the value, or set in 
the system)
If that doesn't work, you'll need to provide some more detailed description of 
what issue you are facing.

--
Stefan

From: gdal-dev  On Behalf Of paul.m...@lfv.se
Sent: Dienstag, 23. März 2021 08:26
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Gdal Java

Hi list,
is there someone out there who has succeeded in installing Gdal Javabindings in 
Windows?
I've tried for some weeks now :( and I can't find very much information how to 
do it I Windows.
gdalalljni.dll is not found for starters (Gdal 3.2.0) but it is there, as 
installed by the installation process.
I've been asking around on internet, but without any luck.
If these is someone who knows how to do it in Windows with Eclipse, it would be 
much