[Geoserver-users] GeoTIFFs verus JP2

Jonathan_Moules2 · November 12, 2013, 8:27am

Hi List,
We’ve recently taken deliver of some aerial photography.

As lossless GeoTIFFs, the RedGreenBlue data is 278GB
As a compressed JP2 file the data is 26GB - the JP2 is almost as good as the GeoTIFFs and comes with pyramids built in.

But for speed purposes with GeoServer I’ve created an imageMosaic of 13 Jpeg compressed GeoTIFFs with overviews/tiles etc. This comes out at a massive 106GB and the quality is worse than the JP2 file despite being four times the size.

Can anyone advise how I can improve these files to make them smaller (ideally with better quality too)? I created each of the GeoTIFFs with the following two commands

Merge, tile, and compress all at once.

gdal_merge -q -o file_name.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=50 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt

Pyramids

gdaladdo -r average %THIS_DIR%.tif 2 4 8 16 32 64 128 256

Using JP2 with GDAL is tempting (though supposedly much slower) - but we’re likely to be putting up four band (RGB + Infrared) data, which I think we can use GeoServer to visualise (still to play with). JP2 can’t handle four bands.

Am I doing something wrong with the GeoTIFF creation?

Thoughts welcome.
Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Andrea_Aime4 · November 12, 2013, 8:43am

On Tue, Nov 12, 2013 at 9:27 AM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi List,
We've recently taken deliver of some aerial photography.

As lossless GeoTIFFs, the RedGreenBlue data is *278GB*
As a compressed JP2 file the data is *26GB* - the JP2 is almost as good
as the GeoTIFFs and comes with pyramids built in.

But for speed purposes with GeoServer I've created an imageMosaic of 13
Jpeg compressed GeoTIFFs with overviews/tiles etc. This comes out at a
massive *106GB* and the quality is worse than the JP2 file despite being
four times the size.

Try something like this instead:

gdal_translate out.tiff in.tiff -co TILED=YES -co blockxsize=512 -co
blockysize=512 -co COMPRESS=JPEG -co JPEG_QUALITY=85 -co PHOTOMETRIC=YCBCR
gdaladdo out.tiff -r average --config COMPRESS_OVERVIEW JPEG --config
JPEG_QUALITY_OVERVIEW 85 --config INTERLEAVE_OVERVIEW PIXEL --config
PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32

Should give you much better quality, and still, a relatively low size (not
as small as JP2, but faster)

Cheres
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

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

Simone_Giannecchini3 · November 12, 2013, 8:50am

Ciao Jonathan,
please read my comments inline below...

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

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

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

On Tue, Nov 12, 2013 at 9:27 AM, Jonathan Moules
<jonathanmoules@anonymised.com> wrote:

Hi List,
We've recently taken deliver of some aerial photography.

As lossless GeoTIFFs, the RedGreenBlue data is 278GB
As a compressed JP2 file the data is 26GB - the JP2 is almost as good as the
GeoTIFFs and comes with pyramids built in.

Unless you have an ECW or Kakadu license JP2 reading won't be as fast
as GeoTiff, I mean, nowhere near to it

But for speed purposes with GeoServer I've created an imageMosaic of 13 Jpeg
compressed GeoTIFFs with overviews/tiles etc. This comes out at a massive
106GB and the quality is worse than the JP2 file despite being four times
the size.

Can anyone advise how I can improve these files to make them smaller
(ideally with better quality too)? I created each of the GeoTIFFs with the
following two commands

Merge, tile, and compress all at once.

gdal_merge -q -o file_name.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co
COMPRESS=JPEG -co JPEG_QUALITY=50 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512
--optfile tiff_list.txt

I believe quality is too low. This makes the files smaller but also
makes the jpeg artifacts quite visibile. I would go with the default
which is 75%.
Moreover, you should use this switch PHOTOMETRIC= YCBCR to improve
JPEG compression.

Pyramids

gdaladdo -r average %THIS_DIR%.tif 2 4 8 16 32 64 128 256

This is correct but could be done better. Since the base level is
compressed I would compress overviews as well.
gdaladdo -r cubic -config COMPRESS_OVERVIEW JPEG --config
PHOTOMETRIC_OVERVIEW YCBCR %THIS_DIR%.tif 2 4 8 16 32 64 128 256

This should provide more quality but also relatively small size.

Using JP2 with GDAL is tempting (though supposedly much slower) - but we're
likely to be putting up four band (RGB + Infrared) data, which I think we
can use GeoServer to visualise (still to play with). JP2 can't handle four
bands.

Ehm, I am playing with 4 bands JP2 just these days, hence I am not so
sure this is true (which means I believe it is not )

I am doing some work to improve performance + quality of 16 bits 4
bands imagery, if you move on along the JP2 lines I could make good
use of a sample.

Am I doing something wrong with the GeoTIFF creation?

Thoughts welcome.
Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in error
please notify the sender immediately. All email traffic sent to or from us,
including without limitation all GCSX traffic, may be subject to recording
and/or monitoring in accordance with relevant legislation.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and
register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Jonathan_Moules2 · November 12, 2013, 9:20am

Hi Both,
Thanks for the quick and helpful replies. I’ll do some experimentation with these things. And there I was thinking I’d figured out GDAL. You might want to put some of this stuff in your “GeoServer on Steroids” presentation.

I’d thought that overviews were compressed - useful to know they’re not; that’ll be a saving of a couple of GB.

I could have sworn someone told me JP2 couldn’t do four bands. Hmmm. For now I’ll stick with GeoTIFFs - I don’t have any 4 band JP2’s and our vendor wasn’t able to create them (nor can FME), so I can’t provide a sample I’m afraid.

Will the PHOTOMETRIC= YCBCR work with a four band RGBI?

The GDALINFO for a source Geotiff is:

Driver: GTiff/GeoTIFF
Files: SP4044.tif
SP4044.tfw
Size is 8000, 8000
Coordinate System is:
PROJCS[“OSGB 1936 / British National Grid”,
GEOGCS[“OSGB 1936”,
DATUM[“OSGB_1936”,
SPHEROID[“Airy 1830”,6377563.396,299.3249753150316,
AUTHORITY[“EPSG”,“7001”]],
AUTHORITY[“EPSG”,“6277”]],
PRIMEM[“Greenwich”,0],
UNIT[“degree”,0.0174532925199433],
AUTHORITY[“EPSG”,“4277”]],
PROJECTION[“Transverse_Mercator”],
PARAMETER[“latitude_of_origin”,49],
PARAMETER[“central_meridian”,-2],
PARAMETER[“scale_factor”,0.9996012717],
PARAMETER[“false_easting”,400000],
PARAMETER[“false_northing”,-100000],
UNIT[“metre”,1,
AUTHORITY[“EPSG”,“9001”]],
AUTHORITY[“EPSG”,“27700”]]
Origin = (440000.000000000000000,245000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
TIFFTAG_XRESOLUTION=72
TIFFTAG_YRESOLUTION=72
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 440000.000, 245000.000) ( 1d24’57.45"W, 52d 6’5.31"N)
Lower Left ( 440000.000, 244000.000) ( 1d24’57.87"W, 52d 5’32.94"N)
Upper Right ( 441000.000, 245000.000) ( 1d24’4.89"W, 52d 6’5.04"N)
Lower Right ( 441000.000, 244000.000) ( 1d24’5.32"W, 52d 5’32.68"N)
Center ( 440500.000, 244500.000) ( 1d24’31.39"W, 52d 5’48.99"N)
Band 1 Block=8000x32 Type=Byte, ColorInterp=Red
Band 2 Block=8000x32 Type=Byte, ColorInterp=Green
Band 3 Block=8000x32 Type=Byte, ColorInterp=Blue
Band 4 Block=8000x32 Type=Byte, ColorInterp=Undefined

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

On 12 November 2013 08:50, Simone Giannecchini <simone.giannecchini@anonymised.com> wrote:

Ciao Jonathan,
please read my comments inline below…

Regards,
Simone Giannecchini

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

mob: +39 333 8128928

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

On Tue, Nov 12, 2013 at 9:27 AM, Jonathan Moules
<jonathanmoules@anonymised.com> wrote:

Hi List,
We’ve recently taken deliver of some aerial photography.

As lossless GeoTIFFs, the RedGreenBlue data is 278GB
As a compressed JP2 file the data is 26GB - the JP2 is almost as good as the
GeoTIFFs and comes with pyramids built in.

Unless you have an ECW or Kakadu license JP2 reading won’t be as fast
as GeoTiff, I mean, nowhere near to it

But for speed purposes with GeoServer I’ve created an imageMosaic of 13 Jpeg
compressed GeoTIFFs with overviews/tiles etc. This comes out at a massive
106GB and the quality is worse than the JP2 file despite being four times
the size.

Can anyone advise how I can improve these files to make them smaller
(ideally with better quality too)? I created each of the GeoTIFFs with the
following two commands

Merge, tile, and compress all at once.

gdal_merge -q -o file_name.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co
COMPRESS=JPEG -co JPEG_QUALITY=50 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512
–optfile tiff_list.txt

I believe quality is too low. This makes the files smaller but also
makes the jpeg artifacts quite visibile. I would go with the default
which is 75%.
Moreover, you should use this switch PHOTOMETRIC= YCBCR to improve
JPEG compression.

Pyramids

gdaladdo -r average %THIS_DIR%.tif 2 4 8 16 32 64 128 256

This is correct but could be done better. Since the base level is
compressed I would compress overviews as well.
gdaladdo -r cubic -config COMPRESS_OVERVIEW JPEG --config
PHOTOMETRIC_OVERVIEW YCBCR %THIS_DIR%.tif 2 4 8 16 32 64 128 256

This should provide more quality but also relatively small size.

Using JP2 with GDAL is tempting (though supposedly much slower) - but we’re
likely to be putting up four band (RGB + Infrared) data, which I think we
can use GeoServer to visualise (still to play with). JP2 can’t handle four
bands.

Ehm, I am playing with 4 bands JP2 just these days, hence I am not so
sure this is true (which means I believe it is not )

I am doing some work to improve performance + quality of 16 bits 4
bands imagery, if you move on along the JP2 lines I could make good
use of a sample.

Am I doing something wrong with the GeoTIFF creation?

Thoughts welcome.
Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in error
please notify the sender immediately. All email traffic sent to or from us,
including without limitation all GCSX traffic, may be subject to recording
and/or monitoring in accordance with relevant legislation.

November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and
register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Thanks again,
Jonathan

Simone_Giannecchini3 · November 12, 2013, 11:45am

Ciao Jonathan,
please, read below...

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

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

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

On Tue, Nov 12, 2013 at 10:20 AM, Jonathan Moules
<jonathanmoules@anonymised.com> wrote:

Hi Both,
Thanks for the quick and helpful replies. I'll do some experimentation with
these things. And there I was thinking I'd figured out GDAL. You might
want to put some of this stuff in your "GeoServer on Steroids" presentation.

actually that is a good idea, we have some more things coming down the pipe

I'd thought that overviews were compressed - useful to know they're not;
that'll be a saving of a couple of GB.

that's true on very large imagery

I could have sworn someone told me JP2 couldn't do four bands. Hmmm. For now
I'll stick with GeoTIFFs - I don't have any 4 band JP2's and our vendor
wasn't able to create them (nor can FME), so I can't provide a sample I'm
afraid.

Will the PHOTOMETRIC= YCBCR work with a four band RGBI?

It should not.

The GDALINFO for a source Geotiff is:

Driver: GTiff/GeoTIFF
Files: SP4044.tif
       SP4044.tfw
Size is 8000, 8000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
    GEOGCS["OSGB 1936",
        DATUM["OSGB_1936",
            SPHEROID["Airy 1830",6377563.396,299.3249753150316,
                AUTHORITY["EPSG","7001"]],
            AUTHORITY["EPSG","6277"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4277"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],
    PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",-100000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","27700"]]
Origin = (440000.000000000000000,245000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
  TIFFTAG_XRESOLUTION=72
  TIFFTAG_YRESOLUTION=72
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 440000.000, 245000.000) ( 1d24'57.45"W, 52d 6'5.31"N)
Lower Left ( 440000.000, 244000.000) ( 1d24'57.87"W, 52d 5'32.94"N)
Upper Right ( 441000.000, 245000.000) ( 1d24'4.89"W, 52d 6'5.04"N)
Lower Right ( 441000.000, 244000.000) ( 1d24'5.32"W, 52d 5'32.68"N)
Center ( 440500.000, 244500.000) ( 1d24'31.39"W, 52d 5'48.99"N)
Band 1 Block=8000x32 Type=Byte, ColorInterp=Red
Band 2 Block=8000x32 Type=Byte, ColorInterp=Green
Band 3 Block=8000x32 Type=Byte, ColorInterp=Blue
Band 4 Block=8000x32 Type=Byte, ColorInterp=Undefined

Thanks again,
Jonathan

On 12 November 2013 08:50, Simone Giannecchini
<simone.giannecchini@anonymised.com> wrote:

Ciao Jonathan,
please read my comments inline below...

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

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

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

On Tue, Nov 12, 2013 at 9:27 AM, Jonathan Moules
<jonathanmoules@anonymised.com> wrote:
> Hi List,
> We've recently taken deliver of some aerial photography.
>
> As lossless GeoTIFFs, the RedGreenBlue data is 278GB
> As a compressed JP2 file the data is 26GB - the JP2 is almost as good as
> the
> GeoTIFFs and comes with pyramids built in.

Unless you have an ECW or Kakadu license JP2 reading won't be as fast
as GeoTiff, I mean, nowhere near to it

>
> But for speed purposes with GeoServer I've created an imageMosaic of 13
> Jpeg
> compressed GeoTIFFs with overviews/tiles etc. This comes out at a
> massive
> 106GB and the quality is worse than the JP2 file despite being four
> times
> the size.
>
> Can anyone advise how I can improve these files to make them smaller
> (ideally with better quality too)? I created each of the GeoTIFFs with
> the
> following two commands
>
> Merge, tile, and compress all at once.
>>
>> gdal_merge -q -o file_name.tif -of GTiff -co TILED=YES -co BIGTIFF=YES
>> -co
>> COMPRESS=JPEG -co JPEG_QUALITY=50 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512
>> --optfile tiff_list.txt

I believe quality is too low. This makes the files smaller but also
makes the jpeg artifacts quite visibile. I would go with the default
which is 75%.
Moreover, you should use this switch PHOTOMETRIC= YCBCR to improve
JPEG compression.

>
>
> Pyramids
>>
>> gdaladdo -r average %THIS_DIR%.tif 2 4 8 16 32 64 128 256

This is correct but could be done better. Since the base level is
compressed I would compress overviews as well.
gdaladdo -r cubic -config COMPRESS_OVERVIEW JPEG --config
PHOTOMETRIC_OVERVIEW YCBCR %THIS_DIR%.tif 2 4 8 16 32 64 128 256

This should provide more quality but also relatively small size.

>
>
>
> Using JP2 with GDAL is tempting (though supposedly much slower) - but
> we're
> likely to be putting up four band (RGB + Infrared) data, which I think
> we
> can use GeoServer to visualise (still to play with). JP2 can't handle
> four
> bands.

Ehm, I am playing with 4 bands JP2 just these days, hence I am not so
sure this is true (which means I believe it is not )

I am doing some work to improve performance + quality of 16 bits 4
bands imagery, if you move on along the JP2 lines I could make good
use of a sample.

>
> Am I doing something wrong with the GeoTIFF creation?
>
> Thoughts welcome.
> Thanks,
> Jonathan
>
> This transmission is intended for the named addressee(s) only and may
> contain sensitive or protectively marked material up to RESTRICTED and
> should be handled accordingly. Unless you are the named addressee (or
> authorised to receive it for the addressee) you may not copy or use it,
> or
> disclose it to anyone else. If you have received this transmission in
> error
> please notify the sender immediately. All email traffic sent to or from
> us,
> including without limitation all GCSX traffic, may be subject to
> recording
> and/or monitoring in accordance with relevant legislation.
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the
> most
> from the latest Intel processors and coprocessors. See abstracts and
> register
>
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in error
please notify the sender immediately. All email traffic sent to or from us,
including without limitation all GCSX traffic, may be subject to recording
and/or monitoring in accordance with relevant legislation.

Andrea_Aime4 · November 12, 2013, 11:49am

On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini <
simone.giannecchini@anonymised.com> wrote:

>
> Will the PHOTOMETRIC= YCBCR work with a four band RGBI?
>

It should not.

Actually... JPEG itself is not defined on 4 bands images as far as I know?
Maybe GDAL is dropping the 4th band during the JPEG compression?

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

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

rouault · November 12, 2013, 1:45pm

Selon Andrea Aime <andrea.aime@anonymised.com>:

On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini <
simone.giannecchini@anonymised.com> wrote:

> >
> > Will the PHOTOMETRIC= YCBCR work with a four band RGBI?
> >
>
> It should not.
>

Actually... JPEG itself is not defined on 4 bands images as far as I know?
Maybe GDAL is dropping the 4th band during the JPEG compression?

The YCbCR JPEG profile of TIFF is indeed limited to 3 bands. So if you pass a 4
band image, gdal_translate should refuse to process it.
You can JPEG compress a 4 band image, but it will use a JPEG codestream for each
band independantly, so the resulting size will be bigger.
A possible option would be to generate 2 GeoTIFFs for each input file : one
YCbCR JPEG compressed with the RGB components, and one JPEG compressed with the
I component. But that might complicate the overall workflow.

Even

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
x.com

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

Jonathan_Moules2 · November 12, 2013, 2:24pm

HI All,
Many thanks for the all the responses. Interesting discussion; I’ve learnt a lot.

I think my next step is to do some testing; I’ve not tried the four band - RGBI imagery yet. When I do I’ll post back here with whatever seems to work best.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

Cheers,
Jonathan

On 12 November 2013 13:45, Even Rouault <even.rouault@anonymised.com4…> wrote:

Selon Andrea Aime <andrea.aime@anonymised.com>:

On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini <
simone.giannecchini@…1107…> wrote:

Will the PHOTOMETRIC= YCBCR work with a four band RGBI?

It should not.

Actually… JPEG itself is not defined on 4 bands images as far as I know?
Maybe GDAL is dropping the 4th band during the JPEG compression?

The YCbCR JPEG profile of TIFF is indeed limited to 3 bands. So if you pass a 4
band image, gdal_translate should refuse to process it.
You can JPEG compress a 4 band image, but it will use a JPEG codestream for each
band independantly, so the resulting size will be bigger.
A possible option would be to generate 2 GeoTIFFs for each input file : one
YCbCR JPEG compressed with the RGB components, and one JPEG compressed with the
I component. But that might complicate the overall workflow.

Even

Cheers
Andrea

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Jonathan_Moules2 · November 20, 2013, 5:21pm

Hi List,
One thing I’m noticing with PHOTOMETRIC=YCBCR - I’m losing a lot of sharpness.

In fact, a 50% without YCBCR looks better than a 85% that also has YCBCR enabled.

This is very noticeable at the native resolution, but once you’re about double it or further, it’s effectively invisible.

On the other hand, the YCBCR is about 25% the size of a equivalently compressed JPEG. I guess I’m going to have to choose which way to go.

···

On 12 November 2013 14:24, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

HI All,
Many thanks for the all the responses. Interesting discussion; I’ve learnt a lot.

I think my next step is to do some testing; I’ve not tried the four band - RGBI imagery yet. When I do I’ll post back here with whatever seems to work best.

Cheers,
Jonathan

On 12 November 2013 13:45, Even Rouault <even.rouault@anonymised.com> wrote:

Selon Andrea Aime <andrea.aime@anonymised.com>:

On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini <
simone.giannecchini@anonymised.com> wrote:

Will the PHOTOMETRIC= YCBCR work with a four band RGBI?

It should not.

Actually… JPEG itself is not defined on 4 bands images as far as I know?
Maybe GDAL is dropping the 4th band during the JPEG compression?

The YCbCR JPEG profile of TIFF is indeed limited to 3 bands. So if you pass a 4
band image, gdal_translate should refuse to process it.
You can JPEG compress a 4 band image, but it will use a JPEG codestream for each
band independantly, so the resulting size will be bigger.
A possible option would be to generate 2 GeoTIFFs for each input file : one
YCbCR JPEG compressed with the RGB components, and one JPEG compressed with the
I component. But that might complicate the overall workflow.

Even

Cheers
Andrea

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

rouault · November 20, 2013, 5:32pm

Le mercredi 20 novembre 2013 18:21:06, Jonathan Moules a écrit :

Hi List,
One thing I'm noticing with PHOTOMETRIC=YCBCR - I'm losing a lot of
sharpness.

In fact, a 50% without YCBCR looks better than a 85% that also has YCBCR
enabled.

This is very noticeable at the native resolution, but once you're about
double it or further, it's effectively invisible.

YCbCr comes with a oversampling by a factor of 2 of the Cb and Cr channels,
hence the extra compression and quality loss. Although than this oversampling
is done because the human eye is less sensible to chromatic than luminance.

On the other hand, the YCBCR is about 25% the size of
a equivalently compressed JPEG. I guess I'm going to have to choose which
way to go.

============

I've also been testing a lot of other variables and for some reason DEFLATE
compression seems to make the file *larger* in all circumstances. It
doesn't matter what the Z level is (even 9), or "predictor", in all
instances the resultant file is larger than an uncompressed version. That's
with four band data.
Anyone know why?

It is not completely surprising. If there are no repeateable patterns in the
uncompressed stream, deflate can result in (a bit) larger files. You might want
to try with -co INTERLEAVE=BAND added to see if it improves things. But
generally DEFLATE is not appropriate for aerial imagery.

Cheers,
Jonathan

On 12 November 2013 14:24, Jonathan Moules <

jonathanmoules@anonymised.com> wrote:
> HI All,
> Many thanks for the all the responses. Interesting discussion; I've
> learnt a lot.
>
> I think my next step is to do some testing; I've not tried the four band
> - RGBI imagery yet. When I do I'll post back here with whatever seems to
> work best.
>
> Cheers,
> Jonathan
>
> On 12 November 2013 13:45, Even Rouault <even.rouault@anonymised.com

paris.org>wrote:

>> Selon Andrea Aime <andrea.aime@anonymised.com>:
>> > On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini <
>> >
>> > simone.giannecchini@anonymised.com> wrote:
>> > > > Will the PHOTOMETRIC= YCBCR work with a four band RGBI?
>> > >
>> > > It should not.
>> >
>> > Actually... JPEG itself is not defined on 4 bands images as far as I
>>
>> know?
>>
>> > Maybe GDAL is dropping the 4th band during the JPEG compression?
>>
>> The YCbCR JPEG profile of TIFF is indeed limited to 3 bands. So if you
>> pass a 4
>> band image, gdal_translate should refuse to process it.
>> You can JPEG compress a 4 band image, but it will use a JPEG codestream
>> for each
>> band independantly, so the resulting size will be bigger.
>> A possible option would be to generate 2 GeoTIFFs for each input file :
>> one
>> YCbCR JPEG compressed with the RGB components, and one JPEG compressed
>> with the
>> I component. But that might complicate the overall workflow.
>>
>> Even
>>
>> > Cheers
>> > Andrea
>> >
>> > --
>> > ==
>> > Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>>
>> more
>>
>> > information.
>> > ==
>> >
>> > Ing. Andrea Aime
>> > @geowolf
>> > Technical Lead
>> >
>> > GeoSolutions S.A.S.
>> > Via Poggio alle Viti 1187
>> > 55054 Massarosa (LU)
>> > Italy
>> > phone: +39 0584 962313
>> > fax: +39 0584 1660272
>> > mob: +39 339 8844549
>> >
>> > http://www.geo-solutions.it
>> > x.com
>> >
>> > -------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>> ------ November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clk
>> trk _______________________________________________
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Geospatial professional services
http://even.rouault.free.fr/services.html

Simone_Giannecchini3 · November 20, 2013, 5:36pm

Ciao a tutti,
addign a bit to this, I would not use band interleaving as we have seen bad performance in the past wrt pixel interleaving.

Simone.

On Wednesday, November 20, 2013, Even Rouault wrote:

Le mercredi 20 novembre 2013 18:21:06, Jonathan Moules a écrit :

Hi List,
One thing I’m noticing with PHOTOMETRIC=YCBCR - I’m losing a lot of
sharpness.

In fact, a 50% without YCBCR looks better than a 85% that also has YCBCR
enabled.

This is very noticeable at the native resolution, but once you’re about
double it or further, it’s effectively invisible.

YCbCr comes with a oversampling by a factor of 2 of the Cb and Cr channels,
hence the extra compression and quality loss. Although than this oversampling
is done because the human eye is less sensible to chromatic than luminance.

On the other hand, the YCBCR is about 25% the size of
a equivalently compressed JPEG. I guess I’m going to have to choose which
way to go.

============

I’ve also been testing a lot of other variables and for some reason DEFLATE
compression seems to make the file larger in all circumstances. It
doesn’t matter what the Z level is (even 9), or “predictor”, in all
instances the resultant file is larger than an uncompressed version. That’s
with four band data.
Anyone know why?

It is not completely surprising. If there are no repeateable patterns in the
uncompressed stream, deflate can result in (a bit) larger files. You might want
to try with -co INTERLEAVE=BAND added to see if it improves things. But
generally DEFLATE is not appropriate for aerial imagery.

Cheers,
Jonathan

On 12 November 2013 14:24, Jonathan Moules <

jonathanmoules@anonymised.com> wrote:

HI All,
Many thanks for the all the responses. Interesting discussion; I’ve
learnt a lot.

I think my next step is to do some testing; I’ve not tried the four band

RGBI imagery yet. When I do I’ll post back here with whatever seems to
work best.

Cheers,
Jonathan

On 12 November 2013 13:45, Even Rouault <even.rouault@anonymised.com…
paris.org>wrote:

Selon Andrea Aime <andrea.aime@anonymised.com07…>:

On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini <

simone.giannecchini@anonymised.com7…> wrote:

Will the PHOTOMETRIC= YCBCR work with a four band RGBI?

It should not.

Actually… JPEG itself is not defined on 4 bands images as far as I

know?

Maybe GDAL is dropping the 4th band during the JPEG compression?

The YCbCR JPEG profile of TIFF is indeed limited to 3 bands. So if you
pass a 4
band image, gdal_translate should refuse to process it.
You can JPEG compress a 4 band image, but it will use a JPEG codestream
for each
band independantly, so the resulting size will be bigger.
A possible option would be to generate 2 GeoTIFFs for each input file :
one
YCbCR JPEG compressed with the RGB components, and one JPEG compressed
with the
I component. But that might complicate the overall workflow.

Even

Cheers
Andrea

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for

more

information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

------ November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models.
Explore
techniques for threading, error checking, porting, and tuning. Get the
most
from the latest Intel processors and coprocessors. See abstracts and
register

http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clk
trk _______________________________________________
Geoserver-users mailing list
Geoserver-users@anonymised.comurceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Geospatial professional services
http://even.rouault.free.fr/services.html

Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

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

Jonathan_Moules2 · November 20, 2013, 6:05pm

gdal_merge -q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

It is not completely surprising. If there are no repeateable patterns in the
uncompressed stream, deflate can result in (a bit) larger files. You might want
to try with -co INTERLEAVE=BAND added to see if it improves things. But
generally DEFLATE is not appropriate for aerial imagery.

The “bit” larger files are typically about double the size of the uncompressed one!

I know deflate isn’t as well suited, but I’m experimenting with a whole bunch of different settings to see what sticks.

======

I’m now trying to get the four band into GeoServer (regular GeoTIFF), but it’s not having it. I’ve created it the same way as the 3 band:
(low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is smaller (118MB) than the 3 band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF
Files: rgbi.tif
Size is 8000, 24000
Coordinate System is:
PROJCS[“OSGB 1936 / British National Grid”,
[brevity removed]
Origin = (419000.000000000000000,240000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=JPEG
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 419000.000, 240000.000) ( 1d43’22.27"W, 52d 3’27.49"N)
Lower Left ( 419000.000, 237000.000) ( 1d43’22.87"W, 52d 1’50.38"N)
Upper Right ( 420000.000, 240000.000) ( 1d42’29.76"W, 52d 3’27.37"N)
Lower Right ( 420000.000, 237000.000) ( 1d42’30.39"W, 52d 1’50.26"N)
Center ( 419500.000, 238500.000) ( 1d42’56.32"W, 52d 2’38.88"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
Mask Flags: PER_DATASET ALPHA
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
Mask Flags: PER_DATASET ALPHA
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
Mask Flags: PER_DATASET ALPHA
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

The GeoServer logs contain an error (WMS GetMap request):

2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image Type
at com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImage.java:706)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
…

Caused by: javax.imageio.IIOException: Unsupported Image Type
at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source)
at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source)
at it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TIFFJPEGDecompressor.java:278)

Ideally I’m looking to have one source file which can be symbolised as not just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I’m stumbling into new (for me) territory here.

Thanks,
Jonathan

Jukka_Rahkonen · November 21, 2013, 9:23pm

I would try if it makes difference to save result from gdal_merge first into uncompressed tiff and compress it with deflate in a separate run.

Jukka Rahkonen

···

Jonathan Moules wrote:

It is not completely surprising. If there are no repeateable patterns in the
uncompressed stream, deflate can result in (a bit) larger files. You might want
to try with -co INTERLEAVE=BAND added to see if it improves things. But
generally DEFLATE is not appropriate for aerial imagery.

The “bit” larger files are typically about double the size of the uncompressed one!

I know deflate isn’t as well suited, but I’m experimenting with a whole bunch of different settings to see what sticks.

======

I’m now trying to get the four band into GeoServer (regular GeoTIFF), but it’s not having it. I’ve created it the same way as the 3 band:

gdal_merge -q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt

(low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is smaller (118MB) than the 3 band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF

Files: rgbi.tif

Size is 8000, 24000

Coordinate System is:

PROJCS[“OSGB 1936 / British National Grid”,

[brevity removed]

Origin = (419000.000000000000000,240000.000000000000000)

Pixel Size = (0.125000000000000,-0.125000000000000)

Metadata:

AREA_OR_POINT=Area

Image Structure Metadata:

COMPRESSION=JPEG

INTERLEAVE=PIXEL

Corner Coordinates:

Upper Left ( 419000.000, 240000.000) ( 1d43’22.27"W, 52d 3’27.49"N)

Lower Left ( 419000.000, 237000.000) ( 1d43’22.87"W, 52d 1’50.38"N)

Upper Right ( 420000.000, 240000.000) ( 1d42’29.76"W, 52d 3’27.37"N)

Lower Right ( 420000.000, 237000.000) ( 1d42’30.39"W, 52d 1’50.26"N)

Center ( 419500.000, 238500.000) ( 1d42’56.32"W, 52d 2’38.88"N)

Band 1 Block=512x512 Type=Byte, ColorInterp=Red

Mask Flags: PER_DATASET ALPHA

Band 2 Block=512x512 Type=Byte, ColorInterp=Green

Mask Flags: PER_DATASET ALPHA

Band 3 Block=512x512 Type=Byte, ColorInterp=Blue

Mask Flags: PER_DATASET ALPHA

Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

The GeoServer logs contain an error (WMS GetMap request):

2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -

java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image Type

at com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImage.java:706)

at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)

at javax.media.jai.OpImage.getTile(OpImage.java:1129)

…

Caused by: javax.imageio.IIOException: Unsupported Image Type

at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source)

at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source)

at it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TIFFJPEGDecompressor.java:278)

Ideally I’m looking to have one source file which can be symbolised as not just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I’m stumbling into new (for me) territory here.

Thanks,

Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Jonathan_Moules2 · November 22, 2013, 12:52pm

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

I would try if it makes difference to save result from gdal_merge first into uncompressed tiff and compress it with deflate in a separate run.

Yep, that worked. Although that’s unfeasible for the full dataset; I don’t have enough diskspace for an uncompressed version.

Also, doing that (deflate, level 9), the tiled version was about 15% smaller than the untiled version.

Thanks!
Jonathan

Jukka Rahkonen

Jonathan Moules wrote:

It is not completely surprising. If there are no repeateable patterns in the
uncompressed stream, deflate can result in (a bit) larger files. You might want
to try with -co INTERLEAVE=BAND added to see if it improves things. But
generally DEFLATE is not appropriate for aerial imagery.

The “bit” larger files are typically about double the size of the uncompressed one!

I know deflate isn’t as well suited, but I’m experimenting with a whole bunch of different settings to see what sticks.

======

I’m now trying to get the four band into GeoServer (regular GeoTIFF), but it’s not having it. I’ve created it the same way as the 3 band:

gdal_merge -q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt

(low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is smaller (118MB) than the 3 band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF

Files: rgbi.tif

Size is 8000, 24000

Coordinate System is:

PROJCS[“OSGB 1936 / British National Grid”,

[brevity removed]

Origin = (419000.000000000000000,240000.000000000000000)

Pixel Size = (0.125000000000000,-0.125000000000000)

Metadata:

AREA_OR_POINT=Area

Image Structure Metadata:

COMPRESSION=JPEG

INTERLEAVE=PIXEL

Corner Coordinates:

Upper Left ( 419000.000, 240000.000) ( 1d43’22.27"W, 52d 3’27.49"N)

Lower Left ( 419000.000, 237000.000) ( 1d43’22.87"W, 52d 1’50.38"N)

Upper Right ( 420000.000, 240000.000) ( 1d42’29.76"W, 52d 3’27.37"N)

Lower Right ( 420000.000, 237000.000) ( 1d42’30.39"W, 52d 1’50.26"N)

Center ( 419500.000, 238500.000) ( 1d42’56.32"W, 52d 2’38.88"N)

Band 1 Block=512x512 Type=Byte, ColorInterp=Red

Mask Flags: PER_DATASET ALPHA

Band 2 Block=512x512 Type=Byte, ColorInterp=Green

Mask Flags: PER_DATASET ALPHA

Band 3 Block=512x512 Type=Byte, ColorInterp=Blue

Mask Flags: PER_DATASET ALPHA

Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

The GeoServer logs contain an error (WMS GetMap request):

2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -

java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image Type

at com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImage.java:706)

at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)

at javax.media.jai.OpImage.getTile(OpImage.java:1129)

…

Caused by: javax.imageio.IIOException: Unsupported Image Type

at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source)

at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source)

at it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TIFFJPEGDecompressor.java:278)

Ideally I’m looking to have one source file which can be symbolised as not just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I’m stumbling into new (for me) territory here.

Thanks,

Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Jukka_Rahkonen · November 22, 2013, 6:18pm

Hi,

I think that the reason is that is is hard/impossible to make an optimal deflate compressed tiff when gdal_merge goes through the circle "open file - add data - close file". There are other alternatives to test:
- You can use a non-optimal deflate compressed tiff as a temporary file - is is lossless and the final result will be identical.
- Use gdalbuildvrt for making an interim .VRT file and convert that to final product instead of using gdal_merge.py. Perhaps GDAL can make an optimal deflate compressed image from the VRT file with one run.

A hint: If you play with big datasets and deflate compressed images GDAL sometimes does not guess when it should jump into BigTIFF. Give the -co bigtiff=yes parameter manually if you feel that it could be needed.

If Even is still sneaking here he can say if the behaviour you see with gdal_merge.py is expected or a bug. Otherwise you can ask it from gdal-dev mailing list.

-Jukka-

________________________________
Jonathan Moules wrote:

On 21 November 2013 21:23, Rahkonen Jukka <jukka.rahkonen@anonymised.com<mailto:jukka.rahkonen@anonymised.com>> wrote:
I would try if it makes difference to save result from gdal_merge first into uncompressed tiff and compress it with deflate in a separate run.

Yep, that worked. Although that's unfeasible for the full dataset; I don't have enough diskspace for an uncompressed version.

Also, doing that (deflate, level 9), the tiled version was about 15% smaller than the untiled version.

Thanks!
Jonathan

Jukka Rahkonen

________________________________
Jonathan Moules<mailto:jonathanmoules@anonymised.com> wrote:

It is not completely surprising. If there are no repeateable patterns in the
uncompressed stream, deflate can result in (a bit) larger files. You might want
to try with -co INTERLEAVE=BAND added to see if it improves things. But
generally DEFLATE is not appropriate for aerial imagery.

The "bit" larger files are typically about double the size of the uncompressed one!

I know deflate isn't as well suited, but I'm experimenting with a whole bunch of different settings to see what sticks.

======

I'm now trying to get the four band into GeoServer (regular GeoTIFF), but it's not having it. I've created it the same way as the 3 band:
gdal_merge -q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt
(low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is *smaller* (118MB) than the 3 band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF
Files: rgbi.tif
Size is 8000, 24000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
[brevity removed]
Origin = (419000.000000000000000,240000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 419000.000, 240000.000) ( 1d43'22.27"W, 52d 3'27.49"N)
Lower Left ( 419000.000, 237000.000) ( 1d43'22.87"W, 52d 1'50.38"N)
Upper Right ( 420000.000, 240000.000) ( 1d42'29.76"W, 52d 3'27.37"N)
Lower Right ( 420000.000, 237000.000) ( 1d42'30.39"W, 52d 1'50.26"N)
Center ( 419500.000, 238500.000) ( 1d42'56.32"W, 52d 2'38.88"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

----

The GeoServer logs contain an error (WMS GetMap request):
2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image Type
at com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImage.java:706)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
....
Caused by: javax.imageio.IIOException: Unsupported Image Type
at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source)
at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source)
at it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TIFFJPEGDecompressor.java:278)

Ideally I'm looking to have one source file which can be symbolised as not just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I'm stumbling into new (for me) territory here.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@anonymised.comrge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Chris_Snider · November 22, 2013, 6:53pm

I have been doing a lot of merging recently with GDAL and I have been following this process
1. gdalwarp -multi -of GTiff -s_srs EPSG:32641 -t_srs EPSG:4326 -r cubic --config GDAL_CACHEMAX 600 -wm 600 -et 0 -srcnodata 0 -dstnodata 0 $SOURCE_FILE.sid $DEST_FILE.4326.tif
Repeat for each source file in the folder
2. ls -1 *.tif >> warpinput.txt
Create an input file from all the warped images
3. gdalbuildvrt -input_file_list warpinput.txt DEST_FILE.4326.vrt
4. time gdalwarp -of GTiff -multi -r cubic --config GDAL_CACHEMAX 600 -wm 600 -et 0 -srcnodata 0 -dstnodata 0 -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co BIGTIFF=YES -cutline <path to>library/one_degree_cells/4326/e074n37_onedegree.shp DEST_FILE.4326.vrt DEST_FILE.4326.merged.tif
5. gdaladdo -r gauss --config GDAL_CACHEMAX 4096 --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 85 --config INTERLEAVE_OVERVIEW PIXEL DEST_FILE.4326.merged.tif 2 4 8 16 32

This has worked fairly well for me so far, your mileage may vary.

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.

-----Original Message-----
From: Rahkonen Jukka [mailto:jukka.rahkonen@anonymised.com]
Sent: Friday, November 22, 2013 11:19 AM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] GeoTIFFs verus JP2

Hi,

I think that the reason is that is is hard/impossible to make an optimal deflate compressed tiff when gdal_merge goes through the circle "open file - add data - close file". There are other alternatives to test:
- You can use a non-optimal deflate compressed tiff as a temporary file - is is lossless and the final result will be identical.
- Use gdalbuildvrt for making an interim .VRT file and convert that to final product instead of using gdal_merge.py. Perhaps GDAL can make an optimal deflate compressed image from the VRT file with one run.

A hint: If you play with big datasets and deflate compressed images GDAL sometimes does not guess when it should jump into BigTIFF. Give the -co bigtiff=yes parameter manually if you feel that it could be needed.

If Even is still sneaking here he can say if the behaviour you see with gdal_merge.py is expected or a bug. Otherwise you can ask it from gdal-dev mailing list.

-Jukka-

________________________________
Jonathan Moules wrote:

On 21 November 2013 21:23, Rahkonen Jukka <jukka.rahkonen@anonymised.com<mailto:jukka.rahkonen@anonymised.com>> wrote:
I would try if it makes difference to save result from gdal_merge first into uncompressed tiff and compress it with deflate in a separate run.

Yep, that worked. Although that's unfeasible for the full dataset; I don't have enough diskspace for an uncompressed version.

Also, doing that (deflate, level 9), the tiled version was about 15% smaller than the untiled version.

Thanks!
Jonathan

Jukka Rahkonen

________________________________
Jonathan Moules<mailto:jonathanmoules@anonymised.com> wrote:

It is not completely surprising. If there are no repeateable patterns in the uncompressed stream, deflate can result in (a bit) larger files. You might want to try with -co INTERLEAVE=BAND added to see if it improves things. But generally DEFLATE is not appropriate for aerial imagery.

The "bit" larger files are typically about double the size of the uncompressed one!

I know deflate isn't as well suited, but I'm experimenting with a whole bunch of different settings to see what sticks.

======

I'm now trying to get the four band into GeoServer (regular GeoTIFF), but it's not having it. I've created it the same way as the 3 band:
gdal_merge -q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt (low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is *smaller* (118MB) than the 3 band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF
Files: rgbi.tif
Size is 8000, 24000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid", [brevity removed] Origin = (419000.000000000000000,240000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 419000.000, 240000.000) ( 1d43'22.27"W, 52d 3'27.49"N) Lower Left ( 419000.000, 237000.000) ( 1d43'22.87"W, 52d 1'50.38"N) Upper Right ( 420000.000, 240000.000) ( 1d42'29.76"W, 52d 3'27.37"N) Lower Right ( 420000.000, 237000.000) ( 1d42'30.39"W, 52d 1'50.26"N)
Center ( 419500.000, 238500.000) ( 1d42'56.32"W, 52d 2'38.88"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

----

The GeoServer logs contain an error (WMS GetMap request):
2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image Type at com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImage.java:706)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
....
Caused by: javax.imageio.IIOException: Unsupported Image Type at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source) at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source) at it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TIFFJPEGDecompressor.java:278)

Ideally I'm looking to have one source file which can be symbolised as not just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I'm stumbling into new (for me) territory here.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@anonymised.comrge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

rouault · November 22, 2013, 6:58pm

Le vendredi 22 novembre 2013 19:18:56, Rahkonen Jukka a écrit :

Hi,

I think that the reason is that is is hard/impossible to make an optimal
deflate compressed tiff when gdal_merge goes through the circle "open file
- add data - close file". There are other alternatives to test: - You can
use a non-optimal deflate compressed tiff as a temporary file - is is
lossless and the final result will be identical. - Use gdalbuildvrt for
making an interim .VRT file and convert that to final product instead of
using gdal_merge.py. Perhaps GDAL can make an optimal deflate compressed
image from the VRT file with one run.

A hint: If you play with big datasets and deflate compressed images GDAL
sometimes does not guess when it should jump into BigTIFF. Give the -co
bigtiff=yes parameter manually if you feel that it could be needed.

If Even is still sneaking here he can say if the behaviour you see with
gdal_merge.py is expected or a bug. Otherwise you can ask it from gdal-dev
mailing list.

I'm not sure which gdal_merge behaviour Jukka is refering too, but indeed it
might not be the appropriate tool to mosaic stuff into a compressed geotiff due
to the way it operates (it can have to do uncompression / recompression cycles
that will waste space in the geotiff). gdalbuildvrt to do the mosaicing
(without a disk footprint of only a few bytes) followed by gdal_translate to
compress will lead to the optimal file size.

-Jukka-

________________________________
Jonathan Moules wrote:

On 21 November 2013 21:23, Rahkonen Jukka
<jukka.rahkonen@anonymised.com<mailto:jukka.rahkonen@anonymised.com>> wrote: I
would try if it makes difference to save result from gdal_merge first into
uncompressed tiff and compress it with deflate in a separate run.

Yep, that worked. Although that's unfeasible for the full dataset; I don't
have enough diskspace for an uncompressed version.

Also, doing that (deflate, level 9), the tiled version was about 15%
smaller than the untiled version.

Thanks!
Jonathan

Jukka Rahkonen

________________________________
Jonathan Moules<mailto:jonathanmoules@anonymised.com> wrote:

It is not completely surprising. If there are no repeateable patterns in
the uncompressed stream, deflate can result in (a bit) larger files. You
might want to try with -co INTERLEAVE=BAND added to see if it improves
things. But generally DEFLATE is not appropriate for aerial imagery.

The "bit" larger files are typically about double the size of the
uncompressed one!

I know deflate isn't as well suited, but I'm experimenting with a whole
bunch of different settings to see what sticks.

======

I'm now trying to get the four band into GeoServer (regular GeoTIFF), but
it's not having it. I've created it the same way as the 3 band: gdal_merge
-q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG
-co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile
tiff_list.txt (low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is *smaller* (118MB) than the 3
band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF
Files: rgbi.tif
Size is 8000, 24000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
[brevity removed]
Origin = (419000.000000000000000,240000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 419000.000, 240000.000) ( 1d43'22.27"W, 52d 3'27.49"N)
Lower Left ( 419000.000, 237000.000) ( 1d43'22.87"W, 52d 1'50.38"N)
Upper Right ( 420000.000, 240000.000) ( 1d42'29.76"W, 52d 3'27.37"N)
Lower Right ( 420000.000, 237000.000) ( 1d42'30.39"W, 52d 1'50.26"N)
Center ( 419500.000, 238500.000) ( 1d42'56.32"W, 52d 2'38.88"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

----

The GeoServer logs contain an error (WMS GetMap request):
2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image
Type at
com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImag
e.java:706) at
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java
:904) at javax.media.jai.OpImage.getTile(OpImage.java:1129)
....
Caused by: javax.imageio.IIOException: Unsupported Image Type
at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown
Source) at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown
Source) at
it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TI
FFJPEGDecompressor.java:278)

Ideally I'm looking to have one source file which can be symbolised as not
just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I'm stumbling into new (for me) territory here.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

---------------------------------------------------------------------------
--- Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr
k _______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@anonymised.com
rge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

---------------------------------------------------------------------------
--- Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr
k _______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Geospatial professional services
http://even.rouault.free.fr/services.html

Jukka_Rahkonen · November 22, 2013, 7:25pm

Hi Even,

The gdal_merge.py behaviour I meant was exactly that the resulting directly created compressed tiff can waste space.

-Jukka-

________________________________________
Even Rouault wrote

Le vendredi 22 novembre 2013 19:18:56, Rahkonen Jukka a écrit :

Hi,

I think that the reason is that is is hard/impossible to make an optimal
deflate compressed tiff when gdal_merge goes through the circle "open file
- add data - close file". There are other alternatives to test: - You can
use a non-optimal deflate compressed tiff as a temporary file - is is
lossless and the final result will be identical. - Use gdalbuildvrt for
making an interim .VRT file and convert that to final product instead of
using gdal_merge.py. Perhaps GDAL can make an optimal deflate compressed
image from the VRT file with one run.

A hint: If you play with big datasets and deflate compressed images GDAL
sometimes does not guess when it should jump into BigTIFF. Give the -co
bigtiff=yes parameter manually if you feel that it could be needed.

If Even is still sneaking here he can say if the behaviour you see with
gdal_merge.py is expected or a bug. Otherwise you can ask it from gdal-dev
mailing list.

I'm not sure which gdal_merge behaviour Jukka is refering too, but indeed it
might not be the appropriate tool to mosaic stuff into a compressed geotiff due
to the way it operates (it can have to do uncompression / recompression cycles
that will waste space in the geotiff). gdalbuildvrt to do the mosaicing
(without a disk footprint of only a few bytes) followed by gdal_translate to
compress will lead to the optimal file size.

-Jukka-

________________________________
Jonathan Moules wrote:

On 21 November 2013 21:23, Rahkonen Jukka
<jukka.rahkonen@anonymised.com<mailto:jukka.rahkonen@anonymised.com>> wrote: I
would try if it makes difference to save result from gdal_merge first into
uncompressed tiff and compress it with deflate in a separate run.

Yep, that worked. Although that's unfeasible for the full dataset; I don't
have enough diskspace for an uncompressed version.

Also, doing that (deflate, level 9), the tiled version was about 15%
smaller than the untiled version.

Thanks!
Jonathan

Jukka Rahkonen

________________________________
Jonathan Moules<mailto:jonathanmoules@anonymised.com> wrote:

It is not completely surprising. If there are no repeateable patterns in
the uncompressed stream, deflate can result in (a bit) larger files. You
might want to try with -co INTERLEAVE=BAND added to see if it improves
things. But generally DEFLATE is not appropriate for aerial imagery.

The "bit" larger files are typically about double the size of the
uncompressed one!

I know deflate isn't as well suited, but I'm experimenting with a whole
bunch of different settings to see what sticks.

======

I'm now trying to get the four band into GeoServer (regular GeoTIFF), but
it's not having it. I've created it the same way as the 3 band: gdal_merge
-q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG
-co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile
tiff_list.txt (low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is *smaller* (118MB) than the 3
band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF
Files: rgbi.tif
Size is 8000, 24000
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
[brevity removed]
Origin = (419000.000000000000000,240000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 419000.000, 240000.000) ( 1d43'22.27"W, 52d 3'27.49"N)
Lower Left ( 419000.000, 237000.000) ( 1d43'22.87"W, 52d 1'50.38"N)
Upper Right ( 420000.000, 240000.000) ( 1d42'29.76"W, 52d 3'27.37"N)
Lower Right ( 420000.000, 237000.000) ( 1d42'30.39"W, 52d 1'50.26"N)
Center ( 419500.000, 238500.000) ( 1d42'56.32"W, 52d 2'38.88"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

----

The GeoServer logs contain an error (WMS GetMap request):
2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image
Type at
com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImag
e.java:706) at
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java
:904) at javax.media.jai.OpImage.getTile(OpImage.java:1129)
....
Caused by: javax.imageio.IIOException: Unsupported Image Type
at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown
Source) at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown
Source) at
it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TI
FFJPEGDecompressor.java:278)

Ideally I'm looking to have one source file which can be symbolised as not
just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I'm stumbling into new (for me) territory here.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

---------------------------------------------------------------------------
--- Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr
k _______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@anonymised.com
rge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

---------------------------------------------------------------------------
--- Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr
k _______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Geospatial professional services
http://even.rouault.free.fr/services.html

Jonathan_Moules2 · November 26, 2013, 10:52am

Thanks for the replies. My other problem is that I don’t have a good GDAL install (precompiled for windows). Every one I’ve tried has been buggy/non-functional in some critical way (typically environmental variable issues). I tried creating a nice little batch file to do everything at once in sequence for each raster, but alas that didn’t work out so its “do things manually”.
I’ll have to do some more testing.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

On 22 November 2013 18:58, Even Rouault <even.rouault@anonymised.com> wrote:

Le vendredi 22 novembre 2013 19:18:56, Rahkonen Jukka a écrit :

Hi,

I think that the reason is that is is hard/impossible to make an optimal
deflate compressed tiff when gdal_merge goes through the circle "open file

add data - close file". There are other alternatives to test: - You can
use a non-optimal deflate compressed tiff as a temporary file - is is
lossless and the final result will be identical. - Use gdalbuildvrt for
making an interim .VRT file and convert that to final product instead of
using gdal_merge.py. Perhaps GDAL can make an optimal deflate compressed
image from the VRT file with one run.

A hint: If you play with big datasets and deflate compressed images GDAL
sometimes does not guess when it should jump into BigTIFF. Give the -co
bigtiff=yes parameter manually if you feel that it could be needed.

If Even is still sneaking here he can say if the behaviour you see with
gdal_merge.py is expected or a bug. Otherwise you can ask it from gdal-dev
mailing list.

I’m not sure which gdal_merge behaviour Jukka is refering too, but indeed it
might not be the appropriate tool to mosaic stuff into a compressed geotiff due
to the way it operates (it can have to do uncompression / recompression cycles
that will waste space in the geotiff). gdalbuildvrt to do the mosaicing
(without a disk footprint of only a few bytes) followed by gdal_translate to
compress will lead to the optimal file size.

-Jukka-

Jonathan Moules wrote:

On 21 November 2013 21:23, Rahkonen Jukka
<jukka.rahkonen@anonymised.com…mailto:[jukka.rahkonen@anonymised.com](mailto:jukka.rahkonen@anonymised.com)> wrote: I
would try if it makes difference to save result from gdal_merge first into
uncompressed tiff and compress it with deflate in a separate run.

Yep, that worked. Although that’s unfeasible for the full dataset; I don’t
have enough diskspace for an uncompressed version.

Also, doing that (deflate, level 9), the tiled version was about 15%
smaller than the untiled version.

Thanks!
Jonathan

Jukka Rahkonen

Jonathan Moulesmailto:[jonathanmoules@anonymised.com](mailto:jonathanmoules@anonymised.com) wrote:

It is not completely surprising. If there are no repeateable patterns in
the uncompressed stream, deflate can result in (a bit) larger files. You
might want to try with -co INTERLEAVE=BAND added to see if it improves
things. But generally DEFLATE is not appropriate for aerial imagery.

The “bit” larger files are typically about double the size of the
uncompressed one!

I know deflate isn’t as well suited, but I’m experimenting with a whole
bunch of different settings to see what sticks.

======

I’m now trying to get the four band into GeoServer (regular GeoTIFF), but
it’s not having it. I’ve created it the same way as the 3 band: gdal_merge
-q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG
-co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile
tiff_list.txt (low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is smaller (118MB) than the 3
band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF
Files: rgbi.tif
Size is 8000, 24000
Coordinate System is:
PROJCS[“OSGB 1936 / British National Grid”,
[brevity removed]
Origin = (419000.000000000000000,240000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=JPEG
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 419000.000, 240000.000) ( 1d43’22.27"W, 52d 3’27.49"N)
Lower Left ( 419000.000, 237000.000) ( 1d43’22.87"W, 52d 1’50.38"N)
Upper Right ( 420000.000, 240000.000) ( 1d42’29.76"W, 52d 3’27.37"N)
Lower Right ( 420000.000, 237000.000) ( 1d42’30.39"W, 52d 1’50.26"N)
Center ( 419500.000, 238500.000) ( 1d42’56.32"W, 52d 2’38.88"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
Mask Flags: PER_DATASET ALPHA
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
Mask Flags: PER_DATASET ALPHA
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
Mask Flags: PER_DATASET ALPHA
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

The GeoServer logs contain an error (WMS GetMap request):
2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image
Type at
com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImag
e.java:706) at
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java
:904) at javax.media.jai.OpImage.getTile(OpImage.java:1129)
…
Caused by: javax.imageio.IIOException: Unsupported Image Type
at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown
Source) at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown
Source) at
it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TI
FFJPEGDecompressor.java:278)

Ideally I’m looking to have one source file which can be symbolised as not
just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I’m stumbling into new (for me) territory here.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

— Shape the Mobile Experience: Free Subscription

Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr

k _______________________________________________

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@anonymised.com
rge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

— Shape the Mobile Experience: Free Subscription

Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr

k _______________________________________________

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Geospatial professional services
http://even.rouault.free.fr/services.html

Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Jukka_Rahkonen · November 26, 2013, 11:27am

Hi,

What exactly is wrong with the builds from http://gisinternals.com/sdk/? I have been using them for years with good success.

-Jukka Rahkonen-

···

Jonathan wrote:

Thanks for the replies. My other problem is that I don’t have a good GDAL install (precompiled for windows). Every one I’ve tried has been buggy/non-functional in some critical way (typically environmental variable issues). I tried creating a nice little batch file to do everything at once in sequence for each raster, but alas that didn’t work out so its “do things manually”.

I’ll have to do some more testing.

Thanks,

Jonathan

On 22 November 2013 18:58, Even Rouault <even.rouault@anonymised.com…> wrote:

Le vendredi 22 novembre 2013 19:18:56, Rahkonen Jukka a écrit :

Hi,

I think that the reason is that is is hard/impossible to make an optimal
deflate compressed tiff when gdal_merge goes through the circle "open file

add data - close file". There are other alternatives to test: - You can
use a non-optimal deflate compressed tiff as a temporary file - is is
lossless and the final result will be identical. - Use gdalbuildvrt for
making an interim .VRT file and convert that to final product instead of
using gdal_merge.py. Perhaps GDAL can make an optimal deflate compressed
image from the VRT file with one run.

A hint: If you play with big datasets and deflate compressed images GDAL
sometimes does not guess when it should jump into BigTIFF. Give the -co
bigtiff=yes parameter manually if you feel that it could be needed.

If Even is still sneaking here he can say if the behaviour you see with
gdal_merge.py is expected or a bug. Otherwise you can ask it from gdal-dev
mailing list.

I’m not sure which gdal_merge behaviour Jukka is refering too, but indeed it
might not be the appropriate tool to mosaic stuff into a compressed geotiff due
to the way it operates (it can have to do uncompression / recompression cycles
that will waste space in the geotiff). gdalbuildvrt to do the mosaicing
(without a disk footprint of only a few bytes) followed by gdal_translate to
compress will lead to the optimal file size.

-Jukka-

Jonathan Moules wrote:

On 21 November 2013 21:23, Rahkonen Jukka
<jukka.rahkonen@anonymised.com…mailto:[jukka.rahkonen@anonymised.com](mailto:jukka.rahkonen@anonymised.com)> wrote: I
would try if it makes difference to save result from gdal_merge first into
uncompressed tiff and compress it with deflate in a separate run.

Yep, that worked. Although that’s unfeasible for the full dataset; I don’t
have enough diskspace for an uncompressed version.

Also, doing that (deflate, level 9), the tiled version was about 15%
smaller than the untiled version.

Thanks!
Jonathan

Jukka Rahkonen

Jonathan Moulesmailto:[jonathanmoules@anonymised.com](mailto:jonathanmoules@anonymised.com) wrote:

It is not completely surprising. If there are no repeateable patterns in
the uncompressed stream, deflate can result in (a bit) larger files. You
might want to try with -co INTERLEAVE=BAND added to see if it improves
things. But generally DEFLATE is not appropriate for aerial imagery.

The “bit” larger files are typically about double the size of the
uncompressed one!

I know deflate isn’t as well suited, but I’m experimenting with a whole
bunch of different settings to see what sticks.

======

I’m now trying to get the four band into GeoServer (regular GeoTIFF), but
it’s not having it. I’ve created it the same way as the 3 band: gdal_merge
-q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG
-co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile
tiff_list.txt (low compression for testing). No pyramids yet.

The first thing I notice is that the 4 band is smaller (118MB) than the 3
band (164MB).

The gdalinfo for the four band:

Driver: GTiff/GeoTIFF
Files: rgbi.tif
Size is 8000, 24000
Coordinate System is:
PROJCS[“OSGB 1936 / British National Grid”,
[brevity removed]
Origin = (419000.000000000000000,240000.000000000000000)
Pixel Size = (0.125000000000000,-0.125000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=JPEG
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 419000.000, 240000.000) ( 1d43’22.27"W, 52d 3’27.49"N)
Lower Left ( 419000.000, 237000.000) ( 1d43’22.87"W, 52d 1’50.38"N)
Upper Right ( 420000.000, 240000.000) ( 1d42’29.76"W, 52d 3’27.37"N)
Lower Right ( 420000.000, 237000.000) ( 1d42’30.39"W, 52d 1’50.26"N)
Center ( 419500.000, 238500.000) ( 1d42’56.32"W, 52d 2’38.88"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
Mask Flags: PER_DATASET ALPHA
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
Mask Flags: PER_DATASET ALPHA
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
Mask Flags: PER_DATASET ALPHA
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

The GeoServer logs contain an error (WMS GetMap request):
2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image
Type at
com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImag
e.java:706) at
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java
:904) at javax.media.jai.OpImage.getTile(OpImage.java:1129)
…
Caused by: javax.imageio.IIOException: Unsupported Image Type
at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown
Source) at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown
Source) at
it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TI
FFJPEGDecompressor.java:278)

Ideally I’m looking to have one source file which can be symbolised as not
just RGB, but also as any number of false-colour possibilities.

Any suggestions anyone? I’m stumbling into new (for me) territory here.

Thanks,
Jonathan

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

— Shape the Mobile Experience: Free Subscription

Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr

k _______________________________________________

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@anonymised.com
rge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in
error please notify the sender immediately. All email traffic sent to or
from us, including without limitation all GCSX traffic, may be subject to
recording and/or monitoring in accordance with relevant legislation.

— Shape the Mobile Experience: Free Subscription

Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr

k _______________________________________________

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Geospatial professional services
http://even.rouault.free.fr/services.html

Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

[Geoserver-users] GeoTIFFs verus JP2

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Regards, Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Regards, Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Regards, Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

–

information.

– Regards, Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

–
Regards,
Simone Giannecchini