Hi,
JPEG2000 format supports up to 16384 components (bands) but all JPEG2000
libraries probably not. Those working with medical imaging or multispectral
scanners appreciate this but it is also practical for storing multichannel
satellite images. Bands do not even need to have same extents or resolutions
but I do not recommend to create such images because few software can utilize
them.
It you want to trial, take a multiband TIFF and convert it into JPEG2000 with
Kakadu demo program "kdu_show". You can get it for free from
http://www.kakadusoftware.com/index.php?option=com_content&task=view&id=26&Itemid=22
It will be harder to find a good viewer for showing your multichannel JPEG200
images but you can have a try with QGis or OpenEV.
PHOTOMETRIC=YCBCR works only for 3-band images.
In theory it feels clever to use RGBI originals and pick either true colour or
CIR presenstations out of them on-the-fly. It means 4 physical bands instead of
6 when compared to having separate RGB and CIR versions. However, I have been
disappointed with this approach because it is hard to adjust the RGBI bands so
that both RGB and CIR looks good without further adjustment in the viewer or by
the server. And as discussed, three band images compress well with YCBCR and
the saving in disk space is not necessarily so great. Situation is different
with for example Landsat images with 7 thematic bands. I can't even count how
many different RGB combinations there are.
-Jukka Rahkonen-
Jonathan Moules 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.
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
Thanks again,
Jonathan
On 12 November 2013 08:50, Simone Giannecchini
<simone.giannecch...@geo-solutions.it<mailto:simone.giannecch...@geo-solutions.it>>
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<tel:%2B39%200584%20962313>
fax: +39 0584 1660272<tel:%2B39%200584%201660272>
mob: +39 333 8128928<tel:%2B39%20%20333%208128928>
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Tue, Nov 12, 2013 at 9:27 AM, Jonathan Moules
<jonathanmou...@warwickshire.gov.uk<mailto:jonathanmou...@warwickshire.gov.uk>>
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<mailto: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.
------------------------------------------------------------------------------
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
