Latest Contributions by PeterBecker

Answer depends on the sensor and processing applied. Most modern satellite and aerial sensors capture 12-14 bits per pixel enabling a wider dynamic range to be captured and reducing the quantization of the imagery. The larger bit depth enables more details to be captured especially in dark and light areas of the image. This is only applicable if the sensor also has low noise. The value of higher bit depth is also more evident in images that have more significant light fall off or other trends in the image. If the image has been correctly processed vast majority of the information content will be within the 8bit range. Use of 16bit imagery is typically used for imagery directly from the sensors. The number of bands depends on the sensor. Note some sensors such as those in most drones actually only have one band in the raw data, but include filters (Bayer) on the CCD/CMOS that then enable the interpolation of a 3band image. Most images from such cameras are recorded as 3band JPEGs, although some cameras can also record the RAW sensor data, which can be post processed to gain a bit more detail. Some more advanced sensors capture 4 bands typically to include near Infrared bands for agricultural applications. There are also cameras and sensors that capture more bands for specific applications. For the majority of application dealing with the visual interpretation of processed imagery 8bit 3band imagery is sufficient. ... View more

The accuracy of the Orthoimage will depend on the accuracy of the RPB (or correction you make to it); the accuracy of the DEM and the sensor look angle. Do check the DEM that you are using. On steeper slopes and with image at less nadir look angles you will see more artifacts. The orthorectification will not affect the radiometry, but the pansharpening can. Do check the pansharpening method. If you are using Gram Schmidt do ensure you compute stats on the MS and Pan Image first. The Gram Schmidt method uses covariance value that are computed with the image statistics. The imagery you have is probably 16bit so there is a lot of dynamic range. In areas with dark shadow and snow this dynamic range is very valuable. Suggest you use the DRA capabilities that are part of the appearance tab. The apparent dark image may be that you have DRA on and are now zoomed to an area that includes white snow so the system dynamically makes the image darker to allow details in the snow. You can also set the stretch to be applied. ... View more

Jeff What you are showing are the properties of the layer and not the properties of the dataset. If you want to re-project the data (which I dont recommend) then you can do this using the reproject tool or just using export. Unless you set on the Export Raster the  'Use Render' flag, then the tools will not change the values. What you are seeing is a change in the stats of the image and that the default renderer uses the stats to display the image. Note if you are re projecting such an image I suggest you set resampling to bilinear or cubic and also use bilinear for they pyramids. If the source was a MrSid then set the compression to JPEG YCbCr ... View more

Jeff If your intent is to create a tile cache for a collection of imagery and publish to ArcGIS Online as tile cache, then please review the 'Serving Cached Imagery' workflow. Essentially the processes is to create a mosaic dataset from you source data (also see Managing Preprocessed Orthphotow workflow) and then cache this mosaic dataset. Their is no need to pre-project the data It will be projected when the caching is performed. Before caching to ensure that Stretch is defined a None and Gamma set to 1 for display of how the cache will look like. The issue you mention with change of brightness is not related to the GPTool that you are using, but instead the computation of image statistics and the subsequent use of these when the output is displayed. It is likely that in the reprojection of the data as a separate process you have created areas with Black on the edges and if not defined as NoData then the histogram shifts the left resulting in the default image being rendered brighter. If NoData is correctly defined then black will remain as NoData and this histogram will not shift. ... View more

Why would one want to create overviews and then convert to raster proxies rather than letting the raster proxy cache be created dynamically? Overviews are reduced resolution versions of the mosaic dataset. IE they are the result of mosaicking multiple images together at lower resolution and used when users zoom to small scales that would otherwise require opening a large number of the source images. There is not simple method to have the system generate such overviews automatically. Once you have added your imagery to the mosaic dataset you typically then create overviews. If you create these locally then you need to copy them to you cloud storage and you can reference them through raster proxies. The alternative is to directly create them on the servers in the cloud (eg directly on the ephemeral drives). These would by default be created on the server file share. An alternative is also to use Generate Raster to create the overview image as a CRF directly to the cloud store. Why would someone want to create external raster proxy files rather than having them embedded in the mosaic dataset? In many cases users create raster proxies from data they have in the cloud in order to have a local representation of the cloud storage (and metadata) on local machines. This can simplify image management for users that prefer to work on local machines. Then before publishing to a cloud server they embed the raster proxies in the mosaic dataset so that the mosaic dataset does not reference external files. How could we estimate the disk space needed for the raster proxy cache? Use the disk space needed for our on-prem overviews? Size of one of our cached image services? The disk space used for the raster proxy cache is equivalent to the unique areas of imagery that is accessed by the server. If users access the same area frequently it will remain small. If users go to many different areas it will increase, and directly dependent on the extent and resolutions visited. Note that the cache can be cleared away at any time and tools are included to automate this. It is recommended to have the cache on local ephemeral drives on each server machine.  Storing the mosaic dataset overviews on ephemeral is an option but may required more management if you have multiple machines. The size of a tile cached (IE rgb 8bit) can be estimates as  CacheSize in MB is approximately AreaInKm2*0.5/(PixelSize in m)^2   eg 20km2 @ 0.25m resolution is approx. 160MB   What is the best practice, have mosaic datasets in individual FGDB's on each GIS server instance or in an enterprise geodatabase? An enterprise geodatabase stored in RDS is simpler to manage. Any updates can be immediately reflected on the serves and does required anything on the server to be changed. Putting the FGDB on the ephemeral drive of the server mean you don’t need to manage (or pay for) an enterprise geodatabase (eg RDS), but you do need to change the servers when the mosaic datasets get updated. This could be automated but can be fiddley. Also if working with very large mosaic datasets (in the millions of records) then it can be time consuming to copy to server machines on updates.. I do not recommend putting a file geodatabase on a fileshare. Is it best to set image compression, pyramid compression, and raster proxy compression to use the same type of compression for performance? All LERC, all JPEG, etc. You can mix compression. No need to keep to the same. Compression should be dependent on the data you have and how much information loss you accept. Historically, our imagery is primarily used for background contextual viewing and we have always used JPEG compression. We have always included a notice to users that because of the compression, it should not be used for any type of analysis. Would using LERC compression remove this caveat? If so, what are the recommended settings we should use? If you use Lossless compression (eg LERC with suitable tolerance or deflate) then the pixel values will not be changed from the original values. No artifacts from compression will be added. If the data source is suitable for analysis or not depends on the source. If for example compression was used in the production process or the data has been in different ways resampled then this could also have added artifacts in the source. Then again many deep learning models are quite invariant to the artifact created by compression, so the answer also depends on what analysis is to be performed. ... View more

Please Include details of the error in a different way. The above link in your message is not accessible. ... View more

1st look to see if the requirement can be changes such that a mosaic dataset can be used.It also depends on the number of images. If not too many then you could just use a webmap with a list of image services each with its own legend. If you create a custom app then there are options that can be developed. ... View more

With a mosaic dataset the image are mosaicked together to create a single image when viewed. Each image can have its own color scale, but the resulting image will be a mosaic of the individual images. The legend is therefore that of the combined image. If you want each image to have its own layer/legend then the mosaic dataset may not be optimum. All the rest of the other requirements such as single layer, and identify are handled by mosaic datasets. ... View more

This is one example of where you need and Enterprise Geodatabase (Oracle, SQL Server, Postgres) so that you can update the mosaic database while it is being used. The alternative is to add the new rasters to a copy of the original and when ready, shutdown the server and publish the updated mosaic dataset, which can be done very quickly. ... View more

My understanding is that you are requesting a workflow to update a hosted tile layer with a new tpk while ensuring the name and item ID remains the same. Currently ArcGIS Enterprise doesn’t have defined workflow for this. Currently is necessary to delete the existing layer and republish the new tpk with the existing name. There is work being done to enable this in future. Until then there are two options: Continue existing workflow of generating tpk using Desktop and then deleting the corresponding hosted tile layer before publishing a new one. OR Use ArcGIS Server to generate cache using Map/image service where the underlying data can get updated for generating updated cache. This would require and image server license if using mosaic datasets.   Note that ArcGIS Image Server is not required to create or work with Mosaic Datasets. Mosaic Datasets are created using ArcGIS Desktop (Pro or ArcMap) Standard or Advanced. Mosaic Datasets can be accessed in all levels of ArcGIS Desktop and also served as image services using ArcGIS Image Server. Without ArcGIS Image Server you should be able to use the workflows to manage the scanned maps in mosaic datasets and use them directly or cache them in ArcGIS Desktop. The general caching tools are available with ArcGIS Desktop. The Manage TileCache tools enable the updating of tile cache. For ArcGIS Online I would recommend using the tools mentioned above, which do allow for the update of tiles without changing the service. ... View more

See the Serving Cached Imagery Workflow that links to Raster Tile Cache Tools. This provides tools to not only create tile cache easily with Pro, but also update tile cache with updates. For working with scanned historical maps do have a look at Managing Scanned Maps. It defines how best to create mosaic datasets from scanned maps that can be served as dynamic images services (IE single service that includes all dates and enables control such as selection of dates and metadata). The same mosaic datasets can also be used to create tile cache. ... View more

Just to add. Note the DEM if provided just provides a better base. It is not needed to see stereo. If you provide the DTM (or constant elevation) then when you open the mosaic dataset and zoom in you should be able to see the imagery rectified to the ground in approx the correct location. This is a good way to ensure the coordinate system etc is correct. Also you do not need to use the OrthoMapping workflow. Just use the Build Stereo Model Tool. This is required to define  the stereo models. In it you can also define parameters so as to limit the stereo models to only the forward overlap if required. Once the stereomodel table is created you can open the mosaic dataset in the stereo tool and the stereo models will become accessible. ... View more

Make image active in the contents Imagery Tab, Raster Functions Search for Mask. Set raster to the raster dataset that you want to work with  For No Data Interpretation - set to 255 For No Data interpretation - Match Any Create New Layer ... View more