UTM COGs render incorrectly in ImageryTileLayer

MarcPfister · ‎11-15-2022

The new beta functionality to read directly from Cloud Optimized Geotiff doesn't seem to work on UTM COGs:

They get rendered in about the right place but something seems to be going very wrong in drawing the internal blocks.

Since this is beta functionality I'm not looking for a fix a or a workaround, just reporting the problem. For more test images around the globe feel free to use anything in https://ard.maxar.com/samples#v5/ .

UndralBatsukh · ‎11-17-2022

Hi there,

Glad you are trying out support for adding COG to ImageryTileLayer. So we looked into this and indeed your COG file has unsupported settings. We added support for your unique case where the change is:

Added support for an internal noData pixel Mask, in addition to noDataValue. 
Corresponding tags are PHOTOMETRICINTERPRETATION = 4 (transparency mask), 
NEWSUBILETYPE = 5 (source level) or 4 (pyramids)

In addition, PHOTOMETRICINTERPRETATION is YCbCr, or CMYK are supported only 
if compression is JPEG, that means result is in RGB space. This is done as 
part of JPEG decoding.

I will let you know when we have this support on our next version. Hope you can test it out and give your feedback.

Cheers,

-Undral

UndralBatsukh · ‎02-24-2023

HI there,

Just want to let you know we added support for noData pixel Mask. Here is your codepen updated: https://codepen.io/U_B_U/pen/rNZMMvQ?editors=1000

StephenSharp · ‎06-23-2023

Undral, we have noticed similar issues with the beta release. Imagery not rendering properly. Also images being placed in the wrong location:

Orthoimagery (bad rendering, ok location): https://maps.vcgi.vermont.gov/pub/View_VT_Imagery_COG_AWS.html
- https://vt-opendata-pilot2.s3.us-east-2.amazonaws.com/LIDAR/0_7M/2014/HILSHD/COG/LOSSY/Elevation_HIL...
Lidar hillshade (ok rendering, bad location): https://maps.vcgi.vermont.gov/pub/View_VT_Hillshade_COG_AWS.html ,
- https://vt-opendata-pilot2.s3.us-east-2.amazonaws.com/IMAGERY/VTORTHO/0_3M/CLRIR/2022/COG/LOSSY/VT_4...

I also noticed that in the case of imagery its looking for a *.tif.aux.xml and for the hillshade its also looking for *.tif.vat.dbf...which returned a 404 error since we don't have those. Not sure if that is part of the "problem", but obviously those files shouldn't be necessary for the COGs to render properly (which they do in Pro and QGIS).

Thanks for your effort to but COG support with the ArcGIS Javascript API. I will be really handy once its ready for prime time!

Steve, VCGI