arcgis 10.1 - What is causing these streaks in my output tif using arcpy.CopyRaster_management?

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.

This is the OUTPUT

Answer

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.