Raster Calculator reduces the count number?

[KuangYinZhao]

Hi all, im trying to use raster calculator to add 100 to all the cell values of a land class Raster (img file ) provided by USGS.
However, whenever i performed this operation "[rastername] + 100" the resultant raster output "count" always been reduced by a lot.
not only using raster calculator, even if i just export the original "img" file into "GRID" file using data export, it will reduce the "count" in the attribute table, and using any reclassificaiton method brings the count down as well ...

Can anyone help me on this? please..

[DanPatterson_Retired]

adding 100 to a grid does not affect the count field, but the class values.  The count fields represents the number of cells that belone to a particular class.  convert your raster to a grid, assuming it is an integer grid, compare the before and after results of adding 100 to your original grid to confirm

[KuangYinZhao]

adding 100 to a grid does not affect the count field, but the class values.  The count fields represents the number of cells that belone to a particular class.  convert your raster to a grid, assuming it is an integer grid, compare the before and after results of adding 100 to your original grid to confirm

Thank you for your reply!

i converted this ".img" file into Grid but the count field was reduced  during the process of converting to grid...more importantly, visual inspection can not see any  points being reduced.

[DanPatterson_Retired]

visual inspection can be deceiving, don't rely on it.  during the conversion process, did you ensure that the extent and cell size were explictly set during the conversion process?  if not then ESRI defaults will come into play and the cell size and extent and hence counts etc may change.  do not rely on anything unless you have check the most important steps.  if none of this applies, then you will need to provide concrete screen grabs/zip files of what exactly you mean isn't happening so that others can investigate further
Regards

[KuangYinZhao]

visual inspection can be deceiving, don't rely on it.  during the conversion process, did you ensure that the extent and cell size were explictly set during the conversion process?  if not then ESRI defaults will come into play and the cell size and extent and hence counts etc may change.  do not rely on anything unless you have check the most important steps.  if none of this applies, then you will need to provide concrete screen grabs/zip files of what exactly you mean isn't happening so that others can investigate further
Regards

Thank you again,

The first picture below shows the original "img" file attribute table, the second one shows the dialog for transforming from �??img�?� to �??grid�?� file. The last picture shows the transformed Grid file's attribute table. We can see that the �??count�?� field had been reduced for land class 11 and 12(as well as the rest of the land classes). Moreover, the land class with count 0 in the original "img" file disappeared from the Grid file attribute table

I had checked the cell size and extend before and after transformation, they are all identical. the only two difference between "img" and "Grid" file is under "Property--->Source tab---->Statistics---->Band1---->Build Parameters" the original "img" file had " ignored value : 0 " but the transformed file only shows "Ignored Value:" with no "0"

Anther difference is under "Property--->Fields tab", the data type and length for each file is different between img and grid files. Picture 4 shows the Fields tab for img file and picture 5 shows the Field tab for grid file.

should i check the "use Render" before i transforme the img file? or i did something wrong somewhere else?...

[KuangYinZhao]

File 2.jpg shows us many things, all of them internally consistent:

• The grid uses one byte per cell (uncompressed).


• It has 17,167 columns and 9,953 rows, yielding 170,863,151 cells.


• Its uncompressed size on disk is "162.95 MB," which is exactly what 170,863,151 converts to when divided by 2^20 = 1,048,576 = one megabyte.


• The cellsize is 0.000941698 (decimal degrees), implying the horizontal extent is 17167*0.000941698 = 16.1661 degrees and the vertical extent is 9953 * 0.000941698 = 9.3727 degrees.


• Sure enough, the horizontal extent from -109.903 to -93.7969 degrees is 16.1661 and the vertical extent from 40.0558 to 49.4285 is 9.3727 degrees.


• 0.000942 degrees is 3.39 arc-seconds, consistent with a grid that is nominally either at 3 arc-seconds or 100 meters resolution. (A grid in decimal degrees cannot have a constant resolution due to curvature, so approximate equivalence is ok here.)

The data shown in File 1.jpg conflict with this. In particular, a grid of less than 171 million cells simply cannot have a valid count of 465,635,133 for any single value.

I don't know what's going on, but I do know that the information in these two screen shots is contradictory. That implies the problem occurs at the outset, before you have even done any conversion, and may be related to the values reported in the first of the five screen shots.

I should also point out that adding 100 to cell values in an eight-bit grid can cause unexpected results, unless you are truly expecting values to be calculated modulo 256. E.g., 243 + 100 = 87. (343 cannot even be represented as an eight-bit integer.) In fact, because this clearly is a categorical grid, adding 100 to the values has no intrinsic meaning. (Which is not to say that the addition operation is nonsensical: it could be needed, for example, to convert one internal coding of the categories into another. But be careful!)

Thank you so much for your comment, they are very very useful.
So in deed, i added all the counts in the img file, it exceeded the total number of cells. However, if i transform the img file to Grid file the count number matches with the total grid cells.... Do you know why is it?...
Here is the Website link where i got my img file from:

http://www.mrlc.gov/multizone_download.php?zone=6

i downloaded the "land cover zip file"

[KuangYinZhao]

The image file there actually has dimensions 39902, 32521, is projected, ...you must have performed some preliminary processing that you did not describe (I suspect you unprojected it), and during that processing you resampled the image to a larger cell size. The resampling would not have changed any attribute values, including the [count] field: that's why there appears to be a discrepancy. In short, the Raster Calculator has done nothing wrong.

Thank you Again,

Sorry i didn�??t mention any preprocessing of this data, yes; i had unprotected it and even exported to a courser resolution. However, the discrepancy occurred before that, the attached picture shows the count summary for both the original 30meter projected .img file and transformed Grid file (still projected and 30meter, all I did is change its format to Grid). The total size, as you had indicated earlier is 39902*32521 = 1297652942. While the img file's count exceeded this value, but the transformed Grid file matches exactly. My question is: what makes these differences in counts?

With your help,  I realized that it is not the Raster Calculator's issue, sorry i don�??t know how to change the title of this post, otherwise i would...

Thank you so much

Zhao

[deleted-user-4RbHy6ryQ4a8]

A coworker and I just ran into a similar problem.  We were performing a mosaic using an img and a grid and we were checking the cell counts of the final raster, and they seemed much too low.  Come to find out, the totals for the img are wrong.  I downloaded your raster, and observed the same results.

Use the copy raster tool to copy to a grid.  You will see the cell count totals for the grid are much lower than the original img.  Use copy raster again to copy the grid back to an img.  The new img has the same cell count totals as the grid.  We hypothesize that there is some corrupted state an img can exist in, such that ArcGIS cannot properly count the cell totals, but it can still properly convert to different raster types.

[JeffreyEvans]

The question I would ask is: where did these counts come from? It looks like you are working with NLCD landcover data. The USGS/MRLC tiles the NLCD to 15 ecoregional boundaries for download purposes. I imagine that the counts are a legacy from before the data was tiled. The NLCD data is managed using ERDAS Imagine. Imagine does not automatically recalculate the count attribute like grid does, you must manually calculate this attribute. When you convert the raster to a ESRI grid format the count field is an internal attribute and is recalculated to match the actual grid.