gdal_merge and gdalwarp: Problems with 1 bit data

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

gdal_merge and gdalwarp: Problems with 1 bit data

Uwe Schmitz-2
Hi,

gdal_merge and gdalwarp seem to have problems writing RasterBands
with 1 Bit depth. I'm using gdal-1.4.2 with old
python bindings(also tested with FWTools-1.3.7).

Let say I have a file called src.tif, where tiffinfo
shows:
TIFF Directory at offset 0x4bbd24
  Subfile Type: (0 = 0x0)
  Image Width: 6299 Image Length: 6299
  Resolution: 400, 400 pixels/inch
  Bits/Sample: 1
  Compression Scheme: None
  Photometric Interpretation: min-is-white
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 6299
  Min Sample Value: 0
  Max Sample Value: 1
  Planar Configuration: single image plane

and gdalinfo reports:
Driver: GTiff/GeoTIFF
Size is 6299, 6299
Coordinate System is:
PROJCS["DHDN / Gauss-Kruger zone 2",
...
Band 1 Block=6299x10 Type=Byte, ColorInterp=Palette
  Metadata:
    NBITS=1
  Color Table (RGB with 2 entries)
    0: 255,255,255,255
    1: 0,0,0,255

Here I'm a little bit astonished to see Type=Byte
and ColorInterp=Palette, but may be it's caused by
abstraction of the interface.

Now if I do the following:

gdal_merge.py -co NBITS=1 -o dst.tif src.tif

the resulting file x.tif looks very jagged. Is this
a known problem?

I have to mention that gdal_translate doesn't have
this problem.

Greetings
Uwe

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdal_merge and gdalwarp: Problems with 1 bit data

Mateusz Loskot
[hidden email] wrote:

> gdal_merge and gdalwarp seem to have problems writing RasterBands
> with 1 Bit depth. I'm using gdal-1.4.2 with old
> python bindings(also tested with FWTools-1.3.7).
>
> ...
> Band 1 Block=6299x10 Type=Byte, ColorInterp=Palette
>   Metadata:
>     NBITS=1
>   Color Table (RGB with 2 entries)
>     0: 255,255,255,255
>     1: 0,0,0,255
>
> Here I'm a little bit astonished to see Type=Byte
> and ColorInterp=Palette, but may be it's caused by
> abstraction of the interface.

Uwe,

AFAIK, 1-bit datatype (generally, non-byte) is represented as GDT_Byte,
so I'd call it as known behavior.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

gdal_merge and gdalwarp: Problems with 1 bit data

Uwe Schmitz-2
In reply to this post by Uwe Schmitz-2
Mateusz,

>
> AFAIK, 1-bit datatype (generally, non-byte) is represented as
> GDT_Byte,
> so I'd call it as known behavior.
>

I see the point, to handle non-byte Data as GDT_Byte internally.
But shouldn't the drivers for formats which allow to write
non-byte data keep track of this and pack the bytes to whatever
is specified.

Noteworthy gdal_translate has no problems in writing 1-Bit Data
and though I haven't looked into it, I assume it uses the same
interface.

Anyhow, I think it isn't a good behaviour to write corrupted
data. At least there has to be an error message saying:
"Can't handle that sort of data". This may save some headache :-)

Uwe

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdal_merge and gdalwarp: Problems with 1 bit data

Frank Warmerdam
In reply to this post by Uwe Schmitz-2
[hidden email] wrote:
> Hi,
>
> gdal_merge and gdalwarp seem to have problems writing RasterBands
> with 1 Bit depth. I'm using gdal-1.4.2 with old
> python bindings(also tested with FWTools-1.3.7).

Uwe,

I was not aware that GDAL 1.4.2 had any support for
writing 1bit files.  FWTools does though.

> and gdalinfo reports:
> Driver: GTiff/GeoTIFF
> Size is 6299, 6299
> Coordinate System is:
> PROJCS["DHDN / Gauss-Kruger zone 2",
> ...
> Band 1 Block=6299x10 Type=Byte, ColorInterp=Palette
>   Metadata:
>     NBITS=1
>   Color Table (RGB with 2 entries)
>     0: 255,255,255,255
>     1: 0,0,0,255
>
> Here I'm a little bit astonished to see Type=Byte
> and ColorInterp=Palette, but may be it's caused by
> abstraction of the interface.

One bit TIFF files have values 0 and 1.  To get this
to display as black and white GDAL abstracts it to be
a paletted image.  Note the GDAL data model does not
directly support 1bit data so we have to promote to byte.

> Now if I do the following:
>
> gdal_merge.py -co NBITS=1 -o dst.tif src.tif
>
> the resulting file x.tif looks very jagged. Is this
> a known problem?

I'm not sure what jagged means.  I tried a quick
gdalwarp to 1 bit file using gdal trunk and it seemed
to work fine.  I would suggest you file a detailed
bug report.  You might even want to try first with
FWTools 1.3.9.  There were some issues with FWTools
geotiff support for a couple revs recently due to the
bigtiff upgrade.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

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