Controling bit depth of raster in FGDB format

[ChrisSnyder]

I've noticed an annoying issue that when I do raster math on a 32-bit float raster datasets , the output (if in FGDB format) has the bit depth get upped to 64-bit. Other than using the CopyRaster tool to copy it back to a 32-bit float format, is there any way to control the bit depth? As far as I know there is no geoprocessing envr setting or spatial analyst function that does this... but seems like there should be!

[DanPatterson_Retired]

Yes there should be, especially if it can be set within the Raster properties in the Environments tab for SA tools.  This thread on bit depth suggests that Esri grids may be the solution, or that rasters with a full range of classes already occupied and contain nodata cells will be upscaled automatically.  I somewhat doubt that the latter is the case, but have you tried saving the results to Esri grid format to see if the problem persists?

[ChrisSnyder]

GRID only supports up to a 32-bit float (64-bit isn't even an option!), so yes that would work. I actually prefer GRID format usually, but indeed some things are faster/more efficient with FGDB format. One thing in particular is that the FGDB format offers (over GRID, .img, etc). is compression support for 32-bit floats. This comes into play especially for rasters with sparse data coverage (the NoData values compress!). Otherwise your 7.2GB LiDAR raster in FGDB format ends up being a 120GB GRID format raster!

Yes, a bit depth environment setting or spatial analyst function sure would be nice!

[DanPatterson_Retired]

Hmmmm and it appears that RasterToNumpyArray and its reverse only support certain environment settings as well, although I haven't played with changing the array data type to a lower floating point representation prior to output back to raster. 

[JayantaPoddar]

Hi Chris,

Specifying the NoData value will allow you to control the pixel depth and the value that will store NoData. If a NoData value is not specified, the program will find an empty value to use as the NoData placeholder, which may not be desired or expected.

Here is what you could try before running Raster Math.

1. Check your input rasters (grayscale bands). Note the values of NoData pixels (e.g. the dark background).

2. Open Reclassify (Spatial Analyst). Change the background value (e.g. 0 in my case) to NoData. Remove all other entries.

You could use ModelBuilder/ArcPy to batch process it.

3. Use these output raster for Raster Math.

Let me know if it solves your issue.

Thanks,

Jay

[ChrisSnyder]

Hi Jay - Not sure what you mean here... your explanation of the process is not very clear.

Basically I have a 32-bit float input raster in FGDB format, and I want to do some simple math involving  some floating point numbers. For example: myRst * 3.2808. I want the output raster to remain in FGDB format. Currently when this process is executed the output raster (in FGDB format) is pumped out as a 64-bit raster. Is there a direct way to "force" the output to remain a 32-bit float?

For what it's worth, I did try the following w/ no success:

1. Created a 32-bit raster (a copy of the input), and used that as the output (aka I overwrote the copy with the output). Result: 64-bit.

2. Altered the NoData envr setting (under Raster Storage heading) to 'MINIMUM'. Result: 64-bit.

[ChrisDonohue__GISP]

What you may be running into is sometimes termed "Bit Depth Promotion":

Esri's products contain all the designations of unknown values within their raster datasets. The unknown values are NoData. Internally, a real value must be used to store the NoData cells. Accordingly, when NoData is added to a raster that already has a full bit range (meaning that there is at least one cell in the raster extent occupying all the values in the bit range, for example, when 0 to 255 are all represented), it is promoted to the next higher bit depth. For example, a hillshade grid with cell values of 0 to 255 (which would otherwise fit within the 8 bit range), that also contains some NoData cells, is represented as unsigned 16 bit.

Source:

ArcGIS Help (10.2, 10.2.1, and 10.2.2)

Chris Donohue, GISP

[DanPatterson_Retired]

Chris, that is the same link I sent him 5 days ago and he seems to have ruled that out as a possibility.

[ChrisDonohue__GISP]

I mentioned it as from Chris' response I wasn't sure if he had evaluated that specific point.  And, as of a short while ago he was still looking for a solution.....

Knowledge is power, use it well

Chris Donohue, GISP

[ChrisSnyder]

Sorry Dan and Chris, I should have clarified, but bit depth promotion is not what is going on here.

For example... a value of 34.5678 * 3.2808 would not result in an output value >= 3.402823466e+38 (which according to the documentation would be the max of the 32-bit threshold), but regardless the resulting raster is output as a 64-bit float... even though there is no reason to warrant that.

If I was trying to resolve 3.402823465e+38 * 3.2808 I would of course expect (and want!) the result promoted to a 64-bit depth.

Basically what I'm look for (wishing for!) is either a envr setting or a map algebra function that would ignore the unwarranted bit depth promotion.

My feeling is that ESRI probably just hard coded it so that if a float type operand was used with an input 32-bit float datasets it would just auto-promote, regardless if the output values exceeded the limit of the 32-bit max/min. A more elegant algorithm would test the max values of the rasters, the operations, and operands then resolve if promotion was necessary. More code for sure, but certainly more elegant.

Worth noting that multiplying a 32-bit float raster by an integer (34.5678 * 3) retains the original 32-bit float depth in the output.