2

This is the line of code that is creating these ...

arcpy.CopyRaster_management(raster, fname, "DEFAULTS","0","","","ColormapToRGB","8_BIT_UNSIGNED")

and I did have a colormap file with specifics to make it that light blue. I don't know where the other color is coming from or the apparrent "streaking". I think I saw something similar posted about this when I was searching for information about this type of conversion but I can't seem to find that post now. The question remains "Why is this happening and what can I do about it"? It seems like it must be a bug. Note that I'm using 10.1 ArcGIS.

This is the INPUT. Its actually a tif made from the same input GRID by direct "data export" from within ArcMap. enter image description here

This is the OUTPUT OUTPUT

3
  • 2
    Looks like incorrectly defined nodata value to me.
    – Chris W
    Commented Apr 17, 2015 at 21:05
  • I didn't think I needed to be concerned by NoData so I left it blank. I'm not sure what value to use but I'll explore this. Commented Apr 17, 2015 at 21:09
  • I'm not sure why a default "" is "incorrectly defined". However if I put a 0 or any number other than 255 in for the NoData argument, it does fix the problem. Commented Apr 21, 2015 at 15:58

1 Answer 1

1

The first thing that springs to mind is an incorrectly defined nodata value. What I notice in the two images is that the dark blue area should be nodata and that it only occurs between valid/data/light blue pixels.

Based on the help file, it actually relates to two of the tool parameters - nodata_value and background_value. From the help file:

Use this option to remove the unwanted values created around the raster data. The value specified will be distinguished from other valuable data in the raster dataset. For example, a value of zero along the raster dataset's borders will be distinguished from zero values within the raster dataset.

The pixel value specified will be set to NoData in the output raster dataset.

For file-based rasters and personal geodatabase rasters, the Ignore Background Value must be set to the same value as NoData in order for the background value to be ignored.

And that pretty much looks like what is happening. Pixels on the outside/border of the image are being rendered as white/nodata, but those presumably same values on the inside of other data is being rendered as something else. Your code line is setting background to 0, but you're not defining nodata. Since the two don't match, they're being rendered differently in the output. Though I do find it interesting you can use different values and get it to work in a file-based raster contrary to the help.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.