Quantcast

[gdal-dev] Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3
Hi List,
I'm investigating on some GeoTIFF data being produced with GDAL 1.11.3.
Basically, when setting COMPRESS=JPEG, the generated GTIFF has the 0th IFD offset set to some KB.

these are the first 16 bytes of a GeoTIFF being generated like that:
49 49 2A 00 88 44 00 00 10 00 00 01 03 00 01 

so:
49 49 is the endianness
00 2A is the magic number
00 00 44 88 is the offset of the 0th IFD = (17544 bytes)
Then there are several TAGs (baseline, extended and so on).
However, I think that any TIFF reader will jump to the 00 00 44 88 offset.
Moreover, the offset 00 00 00 08 (referring to the red bolded byte in my previous sample) seems not referred by any other referencing IFD.

So it seems like that GeoTIFF has some useless bytes right after the first 8s.

I have then tried to use GDAL 2.2.1 and GDAL 2.1.0 and with that version I see that the GeoTIFF being produced using same exact command is smaller and the 0th IFD offset is 8 with these recent versions.
(This information is confirmed by AsTIFFTagViewer and TiffInfo too).

When activating CPL_DEBUG on all versions I see this output on GDAL 1.11.3/1.11.4 whilst I don't see it on GDAL 2.x

GTiff: directory moved during flush in FlushDirectory()

I have quickly checked some reference in the issue tracker but I was unable to find anything, especially due to the fact that when searching for "IFD" it returns hundreds of results related to "IFDefined" :-)

Do you have any feedback or comment on this?
Is it related to any bug in old code or some version update? (is a different libtiff version somehow involved?)

Please, let me know.
Best Regards,
Daniele




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Even Rouault-2

On mercredi 14 décembre 2016 15:01:51 CET Daniele Romagnoli wrote:

> Hi List,

> I'm investigating on some GeoTIFF data being produced with GDAL 1.11.3.

> Basically, when setting COMPRESS=JPEG, the generated GTIFF has the 0th IFD

> offset set to some KB.

>

> these are the first 16 bytes of a GeoTIFF being generated like that:

> 49 49 2A 00 88 44 00 00 *10* 00 00 01 03 00 01

>

> so:

> 49 49 is the endianness

> 00 2A is the magic number

> 00 00 44 88 is the offset of the 0th IFD = (17544 bytes)

> Then there are several TAGs (baseline, extended and so on).

> However, I think that any TIFF reader will jump to the 00 00 44 88 offset.

> Moreover, the offset 00 00 00 08 (referring to the red bolded byte in my

> previous sample) seems not referred by any other referencing IFD.

>

> So it seems like that GeoTIFF has some useless bytes right after the first

> 8s.

>

> I have then tried to use GDAL 2.2.1 and GDAL 2.1.0 and with that version I

> see that the GeoTIFF being produced using same exact command is smaller and

> the 0th IFD offset is 8 with these recent versions.

> (This information is confirmed by AsTIFFTagViewer and TiffInfo too).

>

> When activating CPL_DEBUG on all versions I see this output on GDAL

> 1.11.3/1.11.4 whilst I don't see it on GDAL 2.x

>

> *GTiff: directory moved during flush in FlushDirectory()*

>

> I have quickly checked some reference in the issue tracker but I was unable

> to find anything, especially due to the fact that when searching for "IFD"

> it returns hundreds of results related to "IFDefined" :-)

>

> Do you have any feedback or comment on this?

> Is it related to any bug in old code or some version update? (is a

> different libtiff version somehow involved?)

 

Yes this is an enhancement I did during 2.0 cycle.

 

I think it is linked to this NEWS item (although it is clearly not obvious), which brings other space enhancements:

* for JPEG-compressed TIFF, avoid quantization tables to be emitted in each strip/tile and use optimized Huffman coding by default

 

Previously we indeed lost space since the IFD was written twice. The handling of JPEG quantization tables in libtiff is quite tricky, since they are emitted only when the first pixel is encoded, but at that time, you have already had to write a first version of the IFD without the tables. So the trick is to generate a in-memory very small JPEG-compressed TIFF with the same settings as the real image, extract the JpegTables tag from it, and apply it right away to the real IFD. Obvious, isn't it ;-) ?

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3
Hi Even,
thanks for the feedback! 

Since I'm here, I'm bothering you again with another question.
I have regenerated that GeoTIFF using GDAL 2.1.2.
Right now there isn't a useless IFD at the beginning anymore, due to the improvement you was talking about.
While still checking the data bytes (with an Hex editor and a calculator, ... doh!) I have noticed that there is an unused bytes section between the last data tile of the main page and the first byte of the second page (it's a GeoTIFF with overviews).

Here below, some numbers to make you lost :-) You can skip them and go to the "--------" section.

So the latest TileOffsets of page1 is 0x6BF9, the latest TileByteCounts is 0x095D resulting into last byte for Page1 is 0x7555.
The next referred IFD is 0xBBF0 which for the TileOffsets refer back the 0x7A64 byte.
Checking IFD, TAGs and what else, there is some useless bytes in the range 0x7556-0x7A63.
Going to 0x7556 I have found 13 TAG Definitions (some of them are also TileOffsets/TileByteCounts Tag referring to an address containing nothing).
----------
Wondering if when generating overviews we still have a problem similar to the one you have fixed in 2.0 or some data-updating issue.

These are my hypothesis on what is going on.
A simple translate with no overviews makes the file ending at 0x7555 with offset of next IFD saying 0x0000.
When you add overviews, it writes a new IFD at 0x7556 with TAG entries, then it encodes something and then it writes a new IFD.
At the end, it goes back updating the offset of the 1st overview IFD (0xBBF0) making the one at 0x7556 being not referred anymore.
Does it make sense?

Please let me know and sorry for all these numbers.
Daniele 
 



 

On Wed, Dec 14, 2016 at 3:23 PM, Even Rouault <[hidden email]> wrote:

On mercredi 14 décembre 2016 15:01:51 CET Daniele Romagnoli wrote:

> Hi List,

> I'm investigating on some GeoTIFF data being produced with GDAL 1.11.3.

> Basically, when setting COMPRESS=JPEG, the generated GTIFF has the 0th IFD

> offset set to some KB.

>

> these are the first 16 bytes of a GeoTIFF being generated like that:

> 49 49 2A 00 88 44 00 00 *10* 00 00 01 03 00 01

>

> so:

> 49 49 is the endianness

> 00 2A is the magic number

> 00 00 44 88 is the offset of the 0th IFD = (17544 bytes)

> Then there are several TAGs (baseline, extended and so on).

> However, I think that any TIFF reader will jump to the 00 00 44 88 offset.

> Moreover, the offset 00 00 00 08 (referring to the red bolded byte in my

> previous sample) seems not referred by any other referencing IFD.

>

> So it seems like that GeoTIFF has some useless bytes right after the first

> 8s.

>

> I have then tried to use GDAL 2.2.1 and GDAL 2.1.0 and with that version I

> see that the GeoTIFF being produced using same exact command is smaller and

> the 0th IFD offset is 8 with these recent versions.

> (This information is confirmed by AsTIFFTagViewer and TiffInfo too).

>

> When activating CPL_DEBUG on all versions I see this output on GDAL

> 1.11.3/1.11.4 whilst I don't see it on GDAL 2.x

>

> *GTiff: directory moved during flush in FlushDirectory()*

>

> I have quickly checked some reference in the issue tracker but I was unable

> to find anything, especially due to the fact that when searching for "IFD"

> it returns hundreds of results related to "IFDefined" :-)

>

> Do you have any feedback or comment on this?

> Is it related to any bug in old code or some version update? (is a

> different libtiff version somehow involved?)

 

Yes this is an enhancement I did during 2.0 cycle.

 

I think it is linked to this NEWS item (although it is clearly not obvious), which brings other space enhancements:

* for JPEG-compressed TIFF, avoid quantization tables to be emitted in each strip/tile and use optimized Huffman coding by default

 

Previously we indeed lost space since the IFD was written twice. The handling of JPEG quantization tables in libtiff is quite tricky, since they are emitted only when the first pixel is encoded, but at that time, you have already had to write a first version of the IFD without the tables. So the trick is to generate a in-memory very small JPEG-compressed TIFF with the same settings as the real image, extract the JpegTables tag from it, and apply it right away to the real IFD. Obvious, isn't it ;-) ?

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Even Rouault-2

 

> Wondering if when generating overviews we still have a problem similar to

> the one you have fixed in 2.0 or some data-updating issue.

>

> These are my hypothesis on what is going on.

> A simple translate with no overviews makes the file ending at 0x7555 with

> offset of next IFD saying 0x0000.

> When you add overviews, it writes a new IFD at 0x7556 with TAG entries,

> then it encodes something and then it writes a new IFD.

> At the end, it goes back updating the offset of the 1st overview IFD

> (0xBBF0) making the one at 0x7556 being not referred anymore.

> Does it make sense?

>

 

With JPEG compression right ? I do reproduce something similar to your findings in 2.1 indeed. This no longer happens in trunk due to related improvements (https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in the last couple of weeks (using the same trick of creating a in-memory TIFF file to get the JPEG tables and set them direcly on the overview IFD at creation time).

 

Even

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3


On Fri, Dec 16, 2016 at 1:52 PM, Even Rouault <[hidden email]> wrote:

 

> Wondering if when generating overviews we still have a problem similar to

> the one you have fixed in 2.0 or some data-updating issue.

>

> These are my hypothesis on what is going on.

> A simple translate with no overviews makes the file ending at 0x7555 with

> offset of next IFD saying 0x0000.

> When you add overviews, it writes a new IFD at 0x7556 with TAG entries,

> then it encodes something and then it writes a new IFD.

> At the end, it goes back updating the offset of the 1st overview IFD

> (0xBBF0) making the one at 0x7556 being not referred anymore.

> Does it make sense?

>

 

With JPEG compression right ?

Right,
Indeed, before sending my previous email I have also tried with:
gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config PHOTOMETRIC_OVERVIEW RGB
to understand if it was related to JPEG only but, even with these options, the output overviews were jpeg compressed (I assume there is some kind of coherency check in gdaladdo).

 

I do reproduce something similar to your findings in 2.1 indeed. This no longer happens in trunk due to related improvements (https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in the last couple of weeks (using the same trick of creating a in-memory TIFF file to get the JPEG tables and set them direcly on the overview IFD at creation time).

 

Do you think this will be available in other series or does it introduce new API/major changes which makes it available on 2.2.x only?
Thanks again for your precious feedbacks.

Cheers,
Daniele
 

Even

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Even Rouault-2

 

> Right,

> Indeed, before sending my previous email I have also tried with:

> *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config

> PHOTOMETRIC_OVERVIEW RGB*

> to understand if it was related to JPEG only but, even with these options,

> the output overviews were jpeg compressed (I assume there is some kind of

> coherency check in gdaladdo).

 

With internal overviews, the _OVERVIEW configuration options are ignored. Their value is deduced from the settings of the main IFD. I don't think there's a strong technical reason for that. Mostly a side effect of the fact that there are slightly different code paths to handle creation of internal and external overviews, and the reading of _OVERVIEW config options is done only in the external overview code path.

 

>

> > I do reproduce something similar to your findings in 2.1 indeed. This no

> > longer happens in trunk due to related improvements (

> > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in the

> > last couple of weeks (using the same trick of creating a in-memory TIFF

> > file to get the JPEG tables and set them direcly on the overview IFD at

> > creation time).

>

> Do you think this will be available in other series or does it introduce

> new API/major changes which makes it available on 2.2.x only?

 

No API change, but this is in the improvement category rather than bugfixing, and my first changeset resulted in some corrupted images in some situations, which was unnoticed for a few weeks, so that's a sign that it is a somewhat risky change (the GeoTIFF driver is a complex beast), not worth the trouble of breaking stable branches.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3


On Fri, Dec 16, 2016 at 2:48 PM, Even Rouault <[hidden email]> wrote:

 

> Right,

> Indeed, before sending my previous email I have also tried with:

> *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config

> PHOTOMETRIC_OVERVIEW RGB*

> to understand if it was related to JPEG only but, even with these options,

> the output overviews were jpeg compressed (I assume there is some kind of

> coherency check in gdaladdo).

 

With internal overviews, the _OVERVIEW configuration options are ignored. Their value is deduced from the settings of the main IFD.

It makes sense, indeed.
 

I don't think there's a strong technical reason for that. Mostly a side effect of the fact that there are slightly different code paths to handle creation of internal and external overviews, and the reading of _OVERVIEW config options is done only in the external overview code path.

 

>

> > I do reproduce something similar to your findings in 2.1 indeed. This no

> > longer happens in trunk due to related improvements (

> > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in the

> > last couple of weeks (using the same trick of creating a in-memory TIFF

> > file to get the JPEG tables and set them direcly on the overview IFD at

> > creation time).

>

> Do you think this will be available in other series or does it introduce

> new API/major changes which makes it available on 2.2.x only?

 

No API change, but this is in the improvement category rather than bugfixing, and my first changeset resulted in some corrupted images in some situations, which was unnoticed for a few weeks, so that's a sign that it is a somewhat risky change (the GeoTIFF driver is a complex beast), not worth the trouble of breaking stable branches.

Understood. thanks for the feedback.
Cheers,
Daniele
 

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3
Hi Even.
I'm back to the topic :)
Do you have any timeframe for the 2.2.x release?

Best Regards,
Daniele



On Fri, Dec 16, 2016 at 2:56 PM, Daniele Romagnoli <[hidden email]> wrote:


On Fri, Dec 16, 2016 at 2:48 PM, Even Rouault <[hidden email]> wrote:

 

> Right,

> Indeed, before sending my previous email I have also tried with:

> *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config

> PHOTOMETRIC_OVERVIEW RGB*

> to understand if it was related to JPEG only but, even with these options,

> the output overviews were jpeg compressed (I assume there is some kind of

> coherency check in gdaladdo).

 

With internal overviews, the _OVERVIEW configuration options are ignored. Their value is deduced from the settings of the main IFD.

It makes sense, indeed.
 

I don't think there's a strong technical reason for that. Mostly a side effect of the fact that there are slightly different code paths to handle creation of internal and external overviews, and the reading of _OVERVIEW config options is done only in the external overview code path.

 

>

> > I do reproduce something similar to your findings in 2.1 indeed. This no

> > longer happens in trunk due to related improvements (

> > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in the

> > last couple of weeks (using the same trick of creating a in-memory TIFF

> > file to get the JPEG tables and set them direcly on the overview IFD at

> > creation time).

>

> Do you think this will be available in other series or does it introduce

> new API/major changes which makes it available on 2.2.x only?

 

No API change, but this is in the improvement category rather than bugfixing, and my first changeset resulted in some corrupted images in some situations, which was unnoticed for a few weeks, so that's a sign that it is a somewhat risky change (the GeoTIFF driver is a complex beast), not worth the trouble of breaking stable branches.

Understood. thanks for the feedback.
Cheers,
Daniele
 

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax:      <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.





--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Even Rouault-2

On mardi 10 janvier 2017 11:00:19 CET Daniele Romagnoli wrote:

> Hi Even.

> I'm back to the topic :)

> Do you have any timeframe for the 2.2.x release?

 

April/May likely, to fit with the yearly release tradition.

 

>

> Best Regards,

> Daniele

>

>

>

> On Fri, Dec 16, 2016 at 2:56 PM, Daniele Romagnoli <

>

> [hidden email]> wrote:

> > On Fri, Dec 16, 2016 at 2:48 PM, Even Rouault <[hidden email]>

> >

> > wrote:

> >> > Right,

> >> >

> >> > Indeed, before sending my previous email I have also tried with:

> >> >

> >> > *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config

> >> >

> >> > PHOTOMETRIC_OVERVIEW RGB*

> >> >

> >> > to understand if it was related to JPEG only but, even with these

> >>

> >> options,

> >>

> >> > the output overviews were jpeg compressed (I assume there is some kind

> >>

> >> of

> >>

> >> > coherency check in gdaladdo).

> >>

> >> With internal overviews, the _OVERVIEW configuration options are ignored.

> >> Their value is deduced from the settings of the main IFD.

> >

> > It makes sense, indeed.

> >

> >> I don't think there's a strong technical reason for that. Mostly a side

> >> effect of the fact that there are slightly different code paths to handle

> >> creation of internal and external overviews, and the reading of _OVERVIEW

> >> config options is done only in the external overview code path.

> >>

> >> > > I do reproduce something similar to your findings in 2.1 indeed. This

> >>

> >> no

> >>

> >> > > longer happens in trunk due to related improvements (

> >> > >

> >> > > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in

> >>

> >> the

> >>

> >> > > last couple of weeks (using the same trick of creating a in-memory

> >>

> >> TIFF

> >>

> >> > > file to get the JPEG tables and set them direcly on the overview IFD

> >>

> >> at

> >>

> >> > > creation time).

> >> >

> >> > Do you think this will be available in other series or does it

> >> > introduce

> >> >

> >> > new API/major changes which makes it available on 2.2.x only?

> >>

> >> No API change, but this is in the improvement category rather than

> >> bugfixing, and my first changeset resulted in some corrupted images in

> >> some

> >> situations, which was unnoticed for a few weeks, so that's a sign that it

> >> is a somewhat risky change (the GeoTIFF driver is a complex beast), not

> >> worth the trouble of breaking stable branches.

> >

> > Understood. thanks for the feedback.

> > Cheers,

> > Daniele

> >

> >> Even

> >>

> >>

> >>

> >> --

> >>

> >> Spatialys - Geospatial professional services

> >>

> >> http://www.spatialys.com

> >

> > --

> > ==

> > GeoServer Professional Services from the experts! Visit

> > http://goo.gl/it488V for more information.

> > ==

> >

> > Ing. Daniele Romagnoli

> > Senior Software Engineer

> >

> > GeoSolutions S.A.S.

> > Via di Montramito 3/A

> > 55054 Massarosa (LU)

> > Italy

> > phone: +39 0584 962313 <+39%200584%20962313>

> > fax: +39 0584 1660272 <+39%200584%20166%200272>

> >

> > http://www.geo-solutions.it

> > http://twitter.com/geosolutions_it

> >

> > -------------------------------------------------------

> >

> > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

> >

> > Le informazioni contenute in questo messaggio di posta elettronica e/o

> > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il

> > loro utilizzo è consentito esclusivamente al destinatario del messaggio,

> > per le finalità indicate nel messaggio stesso. Qualora riceviate questo

> > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di

> > darcene notizia via e-mail e di procedere alla distruzione del messaggio

> > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,

> > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od

> > utilizzarlo per finalità diverse, costituisce comportamento contrario ai

> > principi dettati dal D.Lgs. 196/2003.

> >

> >

> >

> > The information in this message and/or attachments, is intended solely for

> > the attention and use of the named addressee(s) and may be confidential or

> > proprietary in nature or covered by the provisions of privacy act

> > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection

> > Code).Any use not in accord with its purpose, any disclosure,

> > reproduction,

> > copying, distribution, or either dissemination, either whole or partial,

> > is

> > strictly forbidden except previous formal approval of the named

> > addressee(s). If you are not the intended recipient, please contact

> > immediately the sender by telephone, fax or e-mail and delete the

> > information in this message that has been received in error. The sender

> > does not give any warranty or accept liability as the content, accuracy or

> > completeness of sent messages and accepts no responsibility for changes

> > made after they were sent or for other risks which arise as a result of

> > e-mail transmission, viruses, etc.

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3
In reply to this post by Daniele Romagnoli-3
Hi Even,
I'm back to this topic and I have a couple of questions.
- Is it there any libtiff specific version involvement on that?
- Are all these improvements self contained in GDAL code itself or do them require some specific libtiff version?

Cheers,
Daniele

On Fri, Dec 16, 2016 at 2:56 PM, Daniele Romagnoli <[hidden email]> wrote:


On Fri, Dec 16, 2016 at 2:48 PM, Even Rouault <[hidden email]> wrote:

 

> Right,

> Indeed, before sending my previous email I have also tried with:

> *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config

> PHOTOMETRIC_OVERVIEW RGB*

> to understand if it was related to JPEG only but, even with these options,

> the output overviews were jpeg compressed (I assume there is some kind of

> coherency check in gdaladdo).

 

With internal overviews, the _OVERVIEW configuration options are ignored. Their value is deduced from the settings of the main IFD.

It makes sense, indeed.
 

I don't think there's a strong technical reason for that. Mostly a side effect of the fact that there are slightly different code paths to handle creation of internal and external overviews, and the reading of _OVERVIEW config options is done only in the external overview code path.

 

>

> > I do reproduce something similar to your findings in 2.1 indeed. This no

> > longer happens in trunk due to related improvements (

> > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in the

> > last couple of weeks (using the same trick of creating a in-memory TIFF

> > file to get the JPEG tables and set them direcly on the overview IFD at

> > creation time).

>

> Do you think this will be available in other series or does it introduce

> new API/major changes which makes it available on 2.2.x only?

 

No API change, but this is in the improvement category rather than bugfixing, and my first changeset resulted in some corrupted images in some situations, which was unnoticed for a few weeks, so that's a sign that it is a somewhat risky change (the GeoTIFF driver is a complex beast), not worth the trouble of breaking stable branches.

Understood. thanks for the feedback.
Cheers,
Daniele
 

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax:      <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.





--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Even Rouault-2

On mardi 31 janvier 2017 18:29:48 CET Daniele Romagnoli wrote:

> Hi Even,

> I'm back to this topic and I have a couple of questions.

> - Is it there any libtiff specific version involvement on that?

> - Are all these improvements self contained in GDAL code itself or do them

> require some specific libtiff version?

 

Should probably work with any libtiff 4.0.X version

 

>

> Cheers,

> Daniele

>

> On Fri, Dec 16, 2016 at 2:56 PM, Daniele Romagnoli <

>

> [hidden email]> wrote:

> > On Fri, Dec 16, 2016 at 2:48 PM, Even Rouault <[hidden email]>

> >

> > wrote:

> >> > Right,

> >> >

> >> > Indeed, before sending my previous email I have also tried with:

> >> >

> >> > *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config

> >> >

> >> > PHOTOMETRIC_OVERVIEW RGB*

> >> >

> >> > to understand if it was related to JPEG only but, even with these

> >>

> >> options,

> >>

> >> > the output overviews were jpeg compressed (I assume there is some kind

> >>

> >> of

> >>

> >> > coherency check in gdaladdo).

> >>

> >> With internal overviews, the _OVERVIEW configuration options are ignored.

> >> Their value is deduced from the settings of the main IFD.

> >

> > It makes sense, indeed.

> >

> >> I don't think there's a strong technical reason for that. Mostly a side

> >> effect of the fact that there are slightly different code paths to handle

> >> creation of internal and external overviews, and the reading of _OVERVIEW

> >> config options is done only in the external overview code path.

> >>

> >> > > I do reproduce something similar to your findings in 2.1 indeed. This

> >>

> >> no

> >>

> >> > > longer happens in trunk due to related improvements (

> >> > >

> >> > > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in

> >>

> >> the

> >>

> >> > > last couple of weeks (using the same trick of creating a in-memory

> >>

> >> TIFF

> >>

> >> > > file to get the JPEG tables and set them direcly on the overview IFD

> >>

> >> at

> >>

> >> > > creation time).

> >> >

> >> > Do you think this will be available in other series or does it

> >> > introduce

> >> >

> >> > new API/major changes which makes it available on 2.2.x only?

> >>

> >> No API change, but this is in the improvement category rather than

> >> bugfixing, and my first changeset resulted in some corrupted images in

> >> some

> >> situations, which was unnoticed for a few weeks, so that's a sign that it

> >> is a somewhat risky change (the GeoTIFF driver is a complex beast), not

> >> worth the trouble of breaking stable branches.

> >

> > Understood. thanks for the feedback.

> > Cheers,

> > Daniele

> >

> >> Even

> >>

> >>

> >>

> >> --

> >>

> >> Spatialys - Geospatial professional services

> >>

> >> http://www.spatialys.com

> >

> > --

> > ==

> > GeoServer Professional Services from the experts! Visit

> > http://goo.gl/it488V for more information.

> > ==

> >

> > Ing. Daniele Romagnoli

> > Senior Software Engineer

> >

> > GeoSolutions S.A.S.

> > Via di Montramito 3/A

> > 55054 Massarosa (LU)

> > Italy

> > phone: +39 0584 962313 <+39%200584%20962313>

> > fax: +39 0584 1660272 <+39%200584%20166%200272>

> >

> > http://www.geo-solutions.it

> > http://twitter.com/geosolutions_it

> >

> > -------------------------------------------------------

> >

> > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

> >

> > Le informazioni contenute in questo messaggio di posta elettronica e/o

> > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il

> > loro utilizzo è consentito esclusivamente al destinatario del messaggio,

> > per le finalità indicate nel messaggio stesso. Qualora riceviate questo

> > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di

> > darcene notizia via e-mail e di procedere alla distruzione del messaggio

> > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,

> > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od

> > utilizzarlo per finalità diverse, costituisce comportamento contrario ai

> > principi dettati dal D.Lgs. 196/2003.

> >

> >

> >

> > The information in this message and/or attachments, is intended solely for

> > the attention and use of the named addressee(s) and may be confidential or

> > proprietary in nature or covered by the provisions of privacy act

> > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection

> > Code).Any use not in accord with its purpose, any disclosure,

> > reproduction,

> > copying, distribution, or either dissemination, either whole or partial,

> > is

> > strictly forbidden except previous formal approval of the named

> > addressee(s). If you are not the intended recipient, please contact

> > immediately the sender by telephone, fax or e-mail and delete the

> > information in this message that has been received in error. The sender

> > does not give any warranty or accept liability as the content, accuracy or

> > completeness of sent messages and accepts no responsibility for changes

> > made after they were sent or for other risks which arise as a result of

> > e-mail transmission, viruses, etc.

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3
Hi Even, another question.

What about the internal libtiff implementation?
There will be any difference in building against a system (released) libtiff version with respect to the internal version?

Cheers,
Daniele


On Tue, Jan 31, 2017 at 6:34 PM, Even Rouault <[hidden email]> wrote:

On mardi 31 janvier 2017 18:29:48 CET Daniele Romagnoli wrote:

> Hi Even,

> I'm back to this topic and I have a couple of questions.

> - Is it there any libtiff specific version involvement on that?

> - Are all these improvements self contained in GDAL code itself or do them

> require some specific libtiff version?

 

Should probably work with any libtiff 4.0.X version

 

>

> Cheers,

> Daniele

>

> On Fri, Dec 16, 2016 at 2:56 PM, Daniele Romagnoli <

>

> [hidden email]> wrote:

> > On Fri, Dec 16, 2016 at 2:48 PM, Even Rouault <[hidden email]>

> >

> > wrote:

> >> > Right,

> >> >

> >> > Indeed, before sending my previous email I have also tried with:

> >> >

> >> > *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config

> >> >

> >> > PHOTOMETRIC_OVERVIEW RGB*

> >> >

> >> > to understand if it was related to JPEG only but, even with these

> >>

> >> options,

> >>

> >> > the output overviews were jpeg compressed (I assume there is some kind

> >>

> >> of

> >>

> >> > coherency check in gdaladdo).

> >>

> >> With internal overviews, the _OVERVIEW configuration options are ignored.

> >> Their value is deduced from the settings of the main IFD.

> >

> > It makes sense, indeed.

> >

> >> I don't think there's a strong technical reason for that. Mostly a side

> >> effect of the fact that there are slightly different code paths to handle

> >> creation of internal and external overviews, and the reading of _OVERVIEW

> >> config options is done only in the external overview code path.

> >>

> >> > > I do reproduce something similar to your findings in 2.1 indeed. This

> >>

> >> no

> >>

> >> > > longer happens in trunk due to related improvements (

> >> > >

> >> > > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in

> >>

> >> the

> >>

> >> > > last couple of weeks (using the same trick of creating a in-memory

> >>

> >> TIFF

> >>

> >> > > file to get the JPEG tables and set them direcly on the overview IFD

> >>

> >> at

> >>

> >> > > creation time).

> >> >

> >> > Do you think this will be available in other series or does it

> >> > introduce

> >> >

> >> > new API/major changes which makes it available on 2.2.x only?

> >>

> >> No API change, but this is in the improvement category rather than

> >> bugfixing, and my first changeset resulted in some corrupted images in

> >> some

> >> situations, which was unnoticed for a few weeks, so that's a sign that it

> >> is a somewhat risky change (the GeoTIFF driver is a complex beast), not

> >> worth the trouble of breaking stable branches.

> >

> > Understood. thanks for the feedback.

> > Cheers,

> > Daniele

> >

> >> Even

> >>

> >>

> >>

> >> --

> >>

> >> Spatialys - Geospatial professional services

> >>

> >> http://www.spatialys.com

> >

> > --

> > ==

> > GeoServer Professional Services from the experts! Visit

> > http://goo.gl/it488V for more information.

> > ==

> >

> > Ing. Daniele Romagnoli

> > Senior Software Engineer

> >

> > GeoSolutions S.A.S.

> > Via di Montramito 3/A

> > 55054 Massarosa (LU)

> > Italy

> > phone: <a href="tel:+39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313 <+39%200584%20962313>

> > fax: <a href="tel:+39%200584%20166%200272" value="+3905841660272" target="_blank">+39 0584 1660272 <+39%200584%20166%200272>

> >

> > http://www.geo-solutions.it

> > http://twitter.com/geosolutions_it

> >

> > -------------------------------------------------------

> >

> > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

> >

> > Le informazioni contenute in questo messaggio di posta elettronica e/o

> > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il

> > loro utilizzo è consentito esclusivamente al destinatario del messaggio,

> > per le finalità indicate nel messaggio stesso. Qualora riceviate questo

> > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di

> > darcene notizia via e-mail e di procedere alla distruzione del messaggio

> > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,

> > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od

> > utilizzarlo per finalità diverse, costituisce comportamento contrario ai

> > principi dettati dal D.Lgs. 196/2003.

> >

> >

> >

> > The information in this message and/or attachments, is intended solely for

> > the attention and use of the named addressee(s) and may be confidential or

> > proprietary in nature or covered by the provisions of privacy act

> > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection

> > Code).Any use not in accord with its purpose, any disclosure,

> > reproduction,

> > copying, distribution, or either dissemination, either whole or partial,

> > is

> > strictly forbidden except previous formal approval of the named

> > addressee(s). If you are not the intended recipient, please contact

> > immediately the sender by telephone, fax or e-mail and delete the

> > information in this message that has been received in error. The sender

> > does not give any warranty or accept liability as the content, accuracy or

> > completeness of sent messages and accepts no responsibility for changes

> > made after they were sent or for other risks which arise as a result of

> > e-mail transmission, viruses, etc.

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Even Rouault-2

On mercredi 1 février 2017 13:04:03 CET Daniele Romagnoli wrote:

> Hi Even, another question.

>

> What about the internal libtiff implementation?

> There will be any difference in building against a system (released)

> libtiff version with respect to the internal version?

 

The internal libtiff implementation is just libtiff CVS HEAD, so currently 4.0.8dev

So it has generally a few more fixes than the last released version, but for the subject discussed here, using it or an external libtiff will not make a difference.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

Daniele Romagnoli-3
Hi Even,
Thanks for your feedback, as usual.

Cheers,
Daniele

On Fri, Feb 3, 2017 at 10:28 AM, Even Rouault <[hidden email]> wrote:

On mercredi 1 février 2017 13:04:03 CET Daniele Romagnoli wrote:

> Hi Even, another question.

>

> What about the internal libtiff implementation?

> There will be any difference in building against a system (released)

> libtiff version with respect to the internal version?

 

The internal libtiff implementation is just libtiff CVS HEAD, so currently 4.0.8dev

So it has generally a few more fixes than the last released version, but for the subject discussed here, using it or an external libtiff will not make a difference.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev



--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Loading...