Latest Contributions by PeterBecker

There is very little point compressing imagery using ZIP. I recommend against using ZIP to compress a directory of images. If you are looking for lossless compression of imagery then simplest is to use Deflate or LZW. There are some better lossless compression methods, but the differences will be limited. If you have collection of imagery that are not compressed and you want to compress them then its better run them through Optimize Raster to compress. Some datasets such as elevation compress better using compression such as LERC. For more details on how to convert and optimize imagery check out OptimizeRasters.    Using Mosaic Dataset is the best way to manage the data as this references the source data (full resolution and any pyramids) and enables the definition of additional attributes, functions to process the data on the fly and enables quick access to all the data either directly in ArcGIS Pro or serving as image services through ArcGIS Image Server.  When directly using the mosaic dataset in ArcGIS Pro it acts as a layer defining functions applied to the appropriate imagery. Yes you are accessing the full resolution source data when zooming in. The compression for transmission that you set is the compression used to transmit the data. It is the client application that can set it and the compression quality at any time. There is no reason to only allow ‘None’.  As you mention setting this to say JPEG  can speed up transmission of the data. There are Export and download options. Export will typically resample the data and apply any defined functions on the data. The application defines the resampling compression etc. Download downloads the original pixels were possible. I say were possible as if you use say a MrSID then the data is compressed and the data must first be decompressed before writing it to a new file so the data structure will change but not the pixel values (unless you define another lossy compression). You can directly use Mosaic datasets as input to your analysis tools. This enables large collections of imagery and rasters to be seen as a single dataset, with control of many properties. If you want to ensure that the pixels are exactly the same as those stored on disk then you should use the environment variables to set the appropriate pixel size, projection and extent to ensure the requested pixels align with the source. Do check out the ArcGIS Imagery Workflows page, it provides lots of best practices ... View more

When you create an image service, by default it does not contains specific symbology. There are ways you can defined raster functions to be applied to service. Multiple functions can be defined enabling the end users to easily select a specific rendering or function that are applied on the server before the data is transmitted to the client. The function (such as band combination) defined on the server is independent of the function the client may additionally define. In this case I assume you have not defined any function and the rendering you are seeing it the default for this dataset in ArcGIS Pro. When a raster is added to Pro the default renderer added is 'Percent Clip'. Percent clip looks at the statistics included as part of the service and attempts to stretch the image for optimum display. This is done by stretching the intensity of the image so that the majority (99%) of the image content is stretched between the min and max output values and that the gamma is changed so try and balance the imagery. This works well for most images based on the available statistics. In this case it looks like the stats are incorrect and hence the the Gamma value has changed to 1.5. The most probable reason this is that the original image that you had has black borders that are not defined as NoData. If they are not defined as NoData then the black is included in the statistic computation resulting in incorrect statistics. The value most affected would be the resulting Gamma. Please look back at the original image and set the appropriate raster properties including setting NoData to 0 and recompute the statistics. Then republish and all should look a lot better.  Alternatively remove the statistics and Pro will not attempt to enhance the image based on the statistics.   ... View more

MrSID files include pyramids and there should be no need to create overviews (unless you have a large number of MrSID files). If one of the files fully overlaps the other and has a different resolution then you may want to review the MinPS, MaxPS values so that only the appropriate image is being accessed depending on scale. MrSID files should display fast if they are stored on local storage. They are not cloud optimized in that reading any section of the image may required multiple requests to the storage system. Please check reading the MrSID files directly in ArcGIS Pro from the same machine as the server. Are they both slow? The performance for serving should be very similar.  ... View more

I took a look. I can not  fully explain the specific artifact you showed at the start of post. I noticed you set the request size to -1 which means it will use the full image. This can lead to a more detailed footprint, but I think internally it need to break the image into smaller tiles and you are seeing an artifact from the tiling. The simplest way to resolve this in this case is just to simply edit the vertices. Footprints can be edited like any other feature class. Alternatively if you have a shape that defines the image extent then you can just clip the footprint by this extent. (I would appear that the original image was clipped to some well defined extent, to you may have this).  As an automated way to get the best results I would suggest using the following parameters. This results in about 2m of the image being clipped off the sides, but otherwise it work quick and has less artifacts. PeterBecker_0-1631575719129.png I would suggest you take care in not having too many vertices in the footprint. Every time you pan the system will need to clip the image by these footprint. If you have 10,000 vertices then that is a lot of clipping.   ... View more

It would appear that the source images have a white border, are JPEG compressed, and you have defined white as being no data. The footprint currently is probably the envelope of the image. What is happening is that as in the pyramids of each image the lower resolution images are being created using JPEG compression and the pure white is no longer white so at lower scales they are no longer NoData/Transparent. The solution to this is to Build footprints by radiometry (say approx 20 vertices and shrink distance of 100m. This should result in a footprint being created around each image and it being clipped by the footprint so excluding all the white areas more cleanly. You should find that after this modification the dynamic mosaic will display faster. Now if you re-build the overviews the artifacts should go away. Also note that you can generate seamlines which will also determine the optimum location for the join. To further reduce any noticeable transition look to set a blend width (say 10pixels) on the seamlines. Also consider running the color correction tools which will further remove trends between different images.  ... View more