Hi,
This issue was logged as a software defect with this reference number: NIM094582
You can use the workaround mentioned above by Jeff Swain until the issue is fixed. We apologize on any inconvenience that this issue might cause on your work flow and thank you again for bringing this issue to our attention.
Regards,
Prasanta.
Can you please indicate more about your input data. I see you mentioned 3 band, but not bit depth or anything else about the input rasters? Usually 3 band rasters are either 8 bit or 16 bit. Based on your experience, I am guessing that they are 16 bit, because they are usually usually the more problematic. Can you indicate if the issue is with 16 bit inputs or 8 bit? Also can you indicate what bit depth you are setting on the input raster? I tested here with some imgs that I had that were 8 bit and they are fine.
The source imagery can be 8 bit, but if the spatial reference is altered or if the NoData value is specified outside the range of 0-255, then the process will resample the raster. In the resampling, rather than delete data or replace values, the bit depth on the raster will be upgraded to the next bit depth. So if you values run 0-255, a NoData value of say '0' is not set, then the process will make the NoData value 256. Then it will look at the values and upgrade the bit depth. This change from 8 bit to 16 bit usually causes a lot of the loading issues.
Thanks for this post.
It saved me a few more days of trouble shooting even though two were already wasted. EXTREMELY frustrating to have functionality deteriorate year after year. (at least 25% of my job time goes to chasing bugs and error codes, and 'not responding')
.....and the bug still exists in 10.2.2
I understand your frustration. After checking the status of the bug report, it is still marked as
'assigned', which means it is being actively worked on by a developer. I know that it is not a solution, but know that it is still being worked on and should be resolved in future releases.
Still an issue in 10.3 as well it seems.