In case anyone else is hitting this issue, the version of GDAL that comes
in the OSGeo4W package http://trac.osgeo.org/osgeo4w/ - works just fine,
including the python stuff and it's easy to install.
On 26 November 2013 12:56, Jonathan Moules
jonathanmou...@warwickshire.gov.uk wrote:
Hi
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
Hi Jukka,
I've tried that one before. First there's the fact there are far too many
options and I can never be sure I'm getting the right thing (the page
assumes a significant level of knowledge about what package is what).
Second the python scripts (i..e. gdal_merge.py) don't work out of the box
Hi,
If you are on Windows 64-bit and don't need Python nor Oracle, use this:
http://gisinternals.com/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver.zip
Installation is like with FWTools: unzip. Go to installation directory, run
sdkshell or perhaps sdkshell hideoci.
This is for sure
On 21 November 2013 21:23, Rahkonen Jukka jukka.rahko...@mmmtike.fi 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
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
: 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
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
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
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,
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
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.
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
On Tue, Nov 12, 2013 at 9:27 AM, Jonathan Moules
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
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)
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
On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini
simone.giannecch...@geo-solutions.it 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
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
Selon Andrea Aime andrea.a...@geo-solutions.it:
On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini
simone.giannecch...@geo-solutions.it 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
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
20 matches
Mail list logo
