POST
|
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
01-07-2023
01:53 PM
|
0
|
3
|
1443
|
POST
|
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
11-02-2022
06:42 PM
|
1
|
1
|
791
|
POST
|
You are correct, the current implementation does not take the Pitch for CamHeading when using 360 imagery. The CamPitch etc are used for approx orientation and does not include the rotation for the 360 imagery. We will look to refine this. In the mean time the solution is to create a field call CamOri and populate with a string of the following form 3|wkid_h|wkid_v|X|Y|Z|CamHeading|CamPitch – 90|CamRoll wkid_h should be the Horizontal SRS, if Orthometric height, wkid_v = 105700 if ellipsoid height., wkid_v = 115700 X,Y should be available Z is absolute height (not height above ground. You will need to determine the height possibly by offsetting the ground elevation with height of the sensor above the ground. Oriented Imagery will pick this up and use this to more accurately render Regards
... View more
10-28-2022
12:50 PM
|
0
|
0
|
1024
|
POST
|
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
09-03-2022
04:58 AM
|
0
|
0
|
1120
|
IDEA
|
Thanks for reference to this. If one looks into the EXIF/XMP on sees the following (see end) It has the GPS Position with a precision of a couple of meters. The orientation in the XML show 0 for all angles. It is possible that in the post processing the data is internally resampled such that the angles are 0, or it may be that the values are not measured. Will become apparent once added. We should have enough to get this added. Will update this post once available. EXIF_FocalLength=(1.4) EXIF_GPSAltitude=(1.1) EXIF_GPSAltitudeRef=0x01 EXIF_GPSDateStamp=2022:07:23 EXIF_GPSImgDirectionRef=M EXIF_GPSLatitude=(30) (20.321) (0) EXIF_GPSLatitudeRef=N EXIF_GPSLongitude=(89) (24.097) (0) EXIF_GPSLongitudeRef=W EXIF_GPSMapDatum=WGS-84 EXIF_GPSMeasureMode=3 EXIF_GPSTimeStamp=(20) (22) (17) EXIF_PixelXDimension=11008 EXIF_PixelYDimension=5504 EXIF_Software=RICOH THETA X Ver 1.10.1 Metadata (xml:XMP): .. GPano:PosePitchDegrees="0" GPano:PoseRollDegrees="0" GPano:ProjectionType="equirectangular" GPano:UsePanoramaViewer="True" xmp:CreateDate="2022-07-23T15:22:22" xmp:CreatorTool="RICOH THETA X Ver 1.10.1" xmp:ModifyDate="2022-07-24T16:39:08-05:00" xmp:MetadataDate="2022-07-24T16:39:08-05:00" ....
... View more
08-04-2022
10:39 AM
|
0
|
0
|
2825
|
IDEA
|
Note there are no standard for how to encode image orientation into EXIF/XMP. Each vendor have their own method. We have a generic Image Type in Oriented Imagery to which we have added the method used by a number of vendors (eg DJI). If you can provide a couple of sample images we can look to see if that can be added. The alternative is to create your own python image type.<>
... View more
08-03-2022
03:31 PM
|
0
|
0
|
2839
|
IDEA
|
Nice interface focused on the images taken vis what the image are taken of. The original concept for Oriented Imagery is to provide documentation of the features and objects and the location of the images is secondary. This is especially true as an object may be covered by many images and an image may cover many objects. There are more requests for such image centric interface and we will look to see how these can be improved or at least made simpler to implement. The experiences with frameless views and more configuration with more simplistic interfaces is also being reviewed.
... View more
08-03-2022
12:20 PM
|
0
|
0
|
894
|
IDEA
|
Can you clarify what you feel is currently missing in this regard with Oriented Imagery. You should be able to create an OIC that references both the 360 and video. If you click the point (or click what you would like to see) the OIC would bring up the appropriate image/video. If there is is a direction/orientation associated with it it will also show you the frustum.
... View more
08-03-2022
12:03 PM
|
0
|
0
|
2859
|
POST
|
Recommendation would be: Create a mosaic dataset of all your source data. Use this to perform a QC of the data and ensure all is as expected. Eg clip out areas not required etc. The mosaic dataset is only virtual and reference the source data. If you then want a single dataset with minimum storage you will want to persist (export or copyraster) to a persisted dataset. You need to determine the number of bands, compression and pixel size. If the data is 4band and you want to later perform analysis then you will likely want to store lossless (eg Deflate/LZW). If this is 3band and visual display you may opt for JPEG compression which can reduce volume >10x with minimal loss in quality. For a 4Band image (or >8bit) I would recommend exporting as CRF. For 3band with JPEG use Manage Tile Cache (or look at Raster Tile Cache tools).
... View more
06-21-2022
05:37 PM
|
0
|
3
|
1538
|
POST
|
Number of Records in Merge: You can have more than 100 records, but I would check performance. If there are too many records the performance will degrade. Also if you can consider merging the many small files into a single larger dataset. (eg using mosaic GPtool). It would result in a duplicate of the data, but can be a lot simpler so long as you don't have too much data. Importing Geometry: If you have a footprint (eg project limit) then you can use the 'Import Mosaic Dataset Geometry' to replace the footprint with that from a feature class. You will need a common attribute to 'join' by. Also the footprints are editable, so you can use standard clipping tools within ArcGIS Pro to just clip the extent footprint by a feature.
... View more
11-01-2021
08:53 AM
|
0
|
1
|
1669
|
POST
|
To resolve the issue on edges of the footprint, use the shrink footprints option (part of build footprints) to bring the footprints in a small amount. The vertical artifact you have is likely to be from the edge between two input image tiles. Do ensure you run Build Footprints for such tiled imagery with the maintain sheet cut option. Also it is better to have much bigger image tiles and preferably remove the tiling with no overlap. It can always create some issues when re-projecting. There is also a merge function that you can merge many rasters into a single time. I would not recommend with too many rasters (>100) Also note that you can have the edges blended if you want. To do this convert the footprint to seamlines or create a new seamline polygon that defines the required edge and then set up blend. (This is another reason you will want to merge or reduce the number of images). Set the blend to be inside and define the required width
... View more
10-28-2021
12:25 PM
|
0
|
3
|
1699
|
POST
|
Issue here is that you need to get the 'item' function chain to recognize the 4th band to be a mask. The standard raster dataset raster type will not do this. You will need to create a raster function template the takes the 4th band and uses the mask function to set this as the mask on the source. The source (and derived) mosaic dataset can remain as 3band. Simplest way to test this is to temporarily include an additional (larger but lower resolution that covers the masked area) and set it LoPS value to 0 so that it is displayed at all scales. If the function is set correctly then this will not be covered by white. Do ensure the default properties also are set to allow no data within the footprint extent. The second (and possibly better) solution to this is to run build footprints by radiometry. This will refine the footprint to represent the extent of the data and then clip out all data outside the footprint. There are a number of advantages to this, but you may want to approximate the extents so that there are not many thousands of vertices.
... View more
10-27-2021
07:59 PM
|
0
|
0
|
1723
|
POST
|
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. 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
09-13-2021
04:39 PM
|
1
|
1
|
980
|
POST
|
This is strange. I'm also surprised to see jagged edge at that location. Can you change the Approx vertices to a smaller value say 10 to see if this resolves. Also is the imagery JPEG compressed? If so please try changing the minDataValue to about 10. I think the issue is that the image is large, but when doing recompute footprint it resamples the image to a size of 2000x2000 pixels. It is possible that due to the angle of the edge the resampling creates a slight jagged line that is then being detected. Possibly send me the file and I can try to identify what is causing this.
... View more
09-13-2021
09:10 AM
|
0
|
3
|
993
|
POST
|
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
07-20-2021
04:39 PM
|
1
|
1
|
929
|
Title | Kudos | Posted |
---|---|---|
1 | 08-08-2024 01:59 AM | |
1 | 11-02-2022 06:42 PM | |
1 | 09-13-2021 04:39 PM | |
2 | 08-09-2023 05:08 PM | |
1 | 05-09-2023 11:25 AM |
Online Status |
Offline
|
Date Last Visited |
08-21-2024
02:08 PM
|