Why is Clip Raster resampling?

[ZacharyUhlmann1]

Seems clipping a raster to a polygon should be straightforward.  I have a raster, I have individual polygon feature layers selected from a feature class.  The polygons are rectangles.  Same projection.  I want to loop through it in Python ultimately, but I have tried both via Python and in the GUI - same result.  Note that even using a feature layer with one feature and not setting clipping_geometry to NONE, the results are identical.  Here is my code:

arcpy.Clip_management(r'path/to/raster(an adf)',"", 'ras_name_out', 'feature_lyr_from_TOC', "#","ClippingGeometry","NO_MAINTAIN_EXTENT")

The final argument/parameter is optional and the documentation (https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/clip.htm ) states this:

• NO_MAINTAIN_EXTENT—The cell alignment of the input raster will be maintained and the output extent will be adjusted accordingly.

Yet my output raster has clearly been resampled.  Pixels are slightly shifted, the pixel value range (DEM) changed.  

FYI - I am trimming excess NaN values from existing raster datasets.  

I don't understand why NO_MANTAIN_EXTENT is resampling.  Should be simple.  If this data were given to me as non-proprietary data type like a GeoTiff I could have easily batch processed these in GDAL.  Should be simple.

[DanPatterson]

snap raster

cell size

extent

These are the three important things that need to be set and considered

Snap Raster (Environment setting)—ArcGIS Pro | Documentation

Cell Alignment (Environment setting)—ArcGIS Pro | Documentation

Cell Size (Environment setting)—ArcGIS Pro | Documentation

and if the coordinate systems are not the same

Cell Size Projection Method (Environment setting)—ArcGIS Pro | Documentation

[ZacharyUhlmann1]

Thanks  @DanPatterson .  I did not consider the environmental settings.  However, those were not the issue.  The magnitude of my original issue is more minor than originally perceived – i.e. the raster values are NOT being resampled.  But, the mechanism that led to my reaction has added multiple issues when visualizing and mapping raster data that I cannot solve.  To simplify my issue, clipping a raster led to a colorbar range being WAY higher than the original.  The max value changed from 938 ft to 1885 ft.  I assumed that Clip Raster had resampled my data, but that has turned out to be incorrect.  Opening the original raster dataset in a Pro map does not display the full pixel value range - in the default “Stretch” Symbology. In my case: 0 to 1885ft.  It displays as 0 to 938ft.  The default Stretch Type = "Percent Clip” at 0.5 on either end.  The ONLY way to automatically display the color bar with the proper range is by switching from Stretch to Classify, in this case with the default Natural Breaks (Jenks).  Tinkering with Clip values or Standard Deviation within Stretch change the raster rendering but NOT the colorbar labelling or scale.  In regards to the Env. Variables you suggested @DanPatterson , only Snap Raster is applicable for the tool.  The result is different, but the raster resolutions don’t EXACTLY match the original or the output from tool without Snap Raster.  Either using Snap Raster or NO_MAINTAIN_EXTENT did not match cell sizes, albeit very slightly.  Out to the 10th decimal.

Yes the cell size change is incredibly minor, but perceivably when toggling the two datasets.  The bigger question is why does Stretch NOT use the full range automatically and why doesn't tinkering with parameters in standard deviation or clip stretch type change the range labels?  THAT is what I’m interested in now and ultimately what led to my panic.  1) Why is Stretch not changing the range and labels in response to changing parameters and 2) Why is the default symbology clipping my range upon initial loading?

Above show how the clipped and original load and the colorbar scale that basically requires manual labelling or switching to a different Stretch type.