Opened 17 years ago

Closed 17 years ago

#1662 closed defect (worksforme)

Data type limitation in gdal_rasterize

Reported by: lukeroth Owned by: warmerdam
Priority: normal Milestone: 1.4.2
Component: GDAL_Raster Version: 1.4.1
Severity: normal Keywords: rasterize
Cc:

Description

I've noticed a limitation in gdal_rasterize: it seems to be saving all values as 8-bit data regardless of the data type of the target image. For example, I have a shapefile for which the value of the feature being rasterized is 710, and I use gdal_rasterize and pass it an unsigned 16-bit image to rasterize to, and the value saved to the image is 195. I've browsed through the gdalrasterize.cpp code and it seems to have special-case code to handle both GDT_Byte and GDT_Float32 data, but no others. However, I don't feel I understand the code well enough yet to know if this is intentional or if it should be fixed. The code in issue is from gdalrasterize.cpp, lines 319-387 (gdal version 1.4.1), where eType is limited to GDT_Float32 for all non - GDT_Byte source image types.

Change History (2)

comment:1 by warmerdam, 17 years ago

Component: defaultGDAL_Raster
Keywords: rasterize added
Milestone: 1.4.2
Status: newassigned

Luke,

The code, as structured, is intended to load 16bit data into a float32 buffer, apply changes, and write back to the 16bit file. This should work properly for 16bit data. But you are apparently seeing a different behavior which surprises me. Can you attach a small 16bit raster file, shapefile and commandline that reproduces the problem?

I use Float32 as the general case because it can be used as a working format for most image values without any data loss - though there are some exceptions (float64, complex values and very large int32 values).

comment:2 by warmerdam, 17 years ago

Resolution: worksforme
Status: assignedclosed

Luke writes (via email):

Thanks for the quick followup - it looks like I jumped the gun on submitting this problem, I've re-read through the code and I think I understand how it works a bit better - I misunderstood exactly how the rasterIO functions handled the data type specification, and it was my code that was handling it incorrectly. Sorry for the trouble!

Luke

--

Closing. Please reopen if you find there is a problem.

Note: See TracTickets for help on using tickets.