Re: [gdal-dev] how to convert UInt16 Tiff

[Brent Fraser]

Another alternative is GINA's 
(http://www.gina.alaska.edu/projects/gina-tools/) gdal_contrast_stretch:


Usage: gdal_contrast_stretch.exe  
  { { -linear-stretch   } |
{ -percentile-range   } |
{ -histeq  } }
  [ -ndv  ]
Input must be either 8-bit or 16-bit.  Output is 8-bit.

I think the input can be any GDAL supported raster type.

Best Regards,
Brent Fraser


On 4/24/2012 2:53 AM, jr.morre...@enoreth.net wrote:

On Tue, 24 Apr 2012 09:38:44 +0200, Even Rouault wrote:


thanks for the reply, I did try with NBITS=8 and 12 with osgeo4w's gdal
and tamas' nightly build but the output results are incorrect

Here is a sample file (93Mo) :
http://dl.free.fr/iFT4hH3Yj

I'll try to rebuild gdal on my linux box with the internal libs


I haven't looked at your result image, but you cannot just specify 
NBITS=8 or

12, if the range of the values in the original file is full 16 bits.

You need to rescale the values, otherwise they will get clamped to
[0, 255] or
[0, 4096].

So you can look for the min/max reported by gdalinfo -mm
uncompressed_original.tif

and then try :

gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif 
compressed.tif

-scale min max 0 255 -ot Byte

or

gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif 
compressed.tif

-scale min max 0 4095 -co NBITS=12


Thanks, I didn't knew that !

The man says that you can omit the input min max scale so gdal 
computes it for each source, however I can't find how to write that 
correctly

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

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

Re: [gdal-dev] How to read part of the tiff data and generate a new tiff file

[Chaitanya kumar CH]

weixj,

You can use the -projwin option of gdal_translate utility.

http://www.gdal.org/gdal_translate.html

2012/4/24 weixj 

> I have a tiff file and four points' coordination(and they are in the range
> of the min and max value of the coordination of the tiff file,I want to
> generate a new tiff file,and the edge of it is constructed by the four
> points.
>
> Thank you  in advance.
>
>
> --
> 网易Lofter，专注兴趣，分享创作！ 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] How to read part of the tiff data and generate a new tiff file

[weixj]

I have a tiff file and four points' coordination(and they are in the range of 
the min and max value of the coordination of the tiff file,I want to generate a 
new tiff file,and the edge of it is constructed by the four points.
 
Thank you  in advance.___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] how to convert UInt16 Tiff

[Even Rouault]

Selon jr.morre...@enoreth.net:

> On Tue, 24 Apr 2012 09:38:44 +0200, Even Rouault wrote:
> >>
> >> thanks for the reply, I did try with NBITS=8 and 12 with osgeo4w's
> >> gdal
> >> and tamas' nightly build but the output results are incorrect
> >>
> >> Here is a sample file (93Mo) :
> >> http://dl.free.fr/iFT4hH3Yj
> >>
> >> I'll try to rebuild gdal on my linux box with the internal libs
> >
> > I haven't looked at your result image, but you cannot just specify
> > NBITS=8 or
> > 12, if the range of the values in the original file is full 16 bits.
> >
> > You need to rescale the values, otherwise they will get clamped to
> > [0, 255] or
> > [0, 4096].
> >
> > So you can look for the min/max reported by gdalinfo -mm
> > uncompressed_original.tif
> >
> > and then try :
> >
> > gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif
> > compressed.tif
> > -scale min max 0 255 -ot Byte
> >
> > or
> >
> > gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif
> > compressed.tif
> > -scale min max 0 4095 -co NBITS=12
>
> Thanks, I didn't knew that !
>
> The man says that you can omit the input min max scale so gdal computes
> it for each source, however I can't find how to write that correctly

Actually, the manual says :

-scale [src_min src_max [dst_min dst_max]]:
Rescale the input pixels values from the range src_min to src_max to the
range dst_min to dst_max. If omitted the output range is 0 to 255. If omitted
the input range is automatically computed from the source data.

In other words, you can use it in 3 ways :
* -scale : in which case src_min and src_max are automatically computed from the
source data.  And dst_min and dst_max will be set to 0 and 255
* -scale src_min src_max : the user specified values for src_min and src_max are
used, and dst_min and dst_max will be set to 0 and 255
* -scale src_min src_max dst_min dst_max : all user specified values are used

There's no syntax to just specify dst_min and dst_max and let src_min and
src_max be computed.

In the case where you want to convert to 8 bits /byte, you could actually just
do : gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif compressed.tif
-ot Byte -scale

For the 12 bits case, you must specify the whole set of values for -scale.

>


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

Re: [gdal-dev] how to convert UInt16 Tiff

[jr . morreale]

On Tue, 24 Apr 2012 09:38:44 +0200, Even Rouault wrote:


thanks for the reply, I did try with NBITS=8 and 12 with osgeo4w's 
gdal

and tamas' nightly build but the output results are incorrect

Here is a sample file (93Mo) :
http://dl.free.fr/iFT4hH3Yj

I'll try to rebuild gdal on my linux box with the internal libs


I haven't looked at your result image, but you cannot just specify 
NBITS=8 or

12, if the range of the values in the original file is full 16 bits.

You need to rescale the values, otherwise they will get clamped to
[0, 255] or
[0, 4096].

So you can look for the min/max reported by gdalinfo -mm
uncompressed_original.tif

and then try :

gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif 
compressed.tif

-scale min max 0 255 -ot Byte

or

gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif 
compressed.tif

-scale min max 0 4095 -co NBITS=12


Thanks, I didn't knew that !

The man says that you can omit the input min max scale so gdal computes 
it for each source, however I can't find how to write that correctly

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

Re: [gdal-dev] how to convert UInt16 Tiff

[Even Rouault]

>
> thanks for the reply, I did try with NBITS=8 and 12 with osgeo4w's gdal
> and tamas' nightly build but the output results are incorrect
>
> Here is a sample file (93Mo) :
> http://dl.free.fr/iFT4hH3Yj
>
> I'll try to rebuild gdal on my linux box with the internal libs

I haven't looked at your result image, but you cannot just specify NBITS=8 or
12, if the range of the values in the original file is full 16 bits.

You need to rescale the values, otherwise they will get clamped to [0, 255] or
[0, 4096].

So you can look for the min/max reported by gdalinfo -mm
uncompressed_original.tif

and then try :

gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif compressed.tif
-scale min max 0 255 -ot Byte

or

gdal_translate -co "COMPRESS=JPEG" uncompressed_original.tif compressed.tif
-scale min max 0 4095 -co NBITS=12

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

Re: [gdal-dev] FID in a vrt

[Even Rouault]

Selon William Kyngesburye :

> As I worked on a test case and fiddled around with a few other ideas, I think
> I found the error of my ways.
>
> The computer I was doing the conversion from vrt to PostGIS has GDAL 1.8.  In
> my test case, GDAL 1.9 correctly preserves the FIDs.  Was -preserve_fid
> broken in 1.8?

Not that I'm aware of. -preserve_fid job is pretty stupid. I'd bet more on a
difference in another place, perhaps in the VRT driver.

>  I see the option listed in the help for 1.8, but not
> described (it is described in the 1.9 help).
>
> But, neither version reports the FID column info on a vrt.  Though it does on
> the PostGIS table.

Ah ok, I see what you mean. The VRT driver does not currently report that it
does use the source FID if it is specified. It is a matter of implementing the
GetFIDColumn() method. Would you mind opening a ticket about that ?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev