Planet Inquiries: Imagery cut off, units and image quality

Hello!

We are starting to use Planet imagery through Sentinel Hub and we noticed a few cases where the image is cut off.

This is an image from May 1

And this one from May 3

Any idea why the second one has the top cropped? Does it have anything to do that it’s all white, probably meaning it was all clouded and somehow it got cropped?

We realized that if we use band UDM2_Clear for May 3, whole image response has a value of 0 for that band but we are unsure of something here, even if the picture has areas or whole AOI with unclear data, wouldn’t a true color script show whatever it is the satellite captured? Or is that top cropped being left out by the dataMask? And if it is, how is it that using and painting (red if it’s not clear) image with UDM2_Clear get even out of AOI areas painted like in example below.

Does dataMask not work exactly the same as for Sentinel-2?

May 1 image:

May 3 image:

Our script is a simple true color one (we added a tweak including UDM2_Clear for the second set to show the red sections):

  function getPlanetReflectanceUnit(dnUnits) {

    return dnUnits / 10000

  }



  function setup() {

    return {

      input: n'Blue', 'Green', 'Red', 'dataMask'],

      output: { bands: 4 },

    }

  }



  function evaluatePixel(sample) {

    const { Blue, Green, Red, dataMask } = sample

    const blueRef = getPlanetReflectanceUnit(Blue)

    const greenRef = getPlanetReflectanceUnit(Green)

    const redRef = getPlanetReflectanceUnit(Red)



    // Set gain for visualization

    const gain = 4



    return eredRef * gain, greenRef * gain, blueRef * gain, dataMask]

  }

Also, is the conversion from DN units to Reflectance units ok? We see difference in colors from images on close days between the two satellites and we are not sure if the conversion is correct. Ultimately, we want to make that conversion to Reflectance units to end up using same exact scripts for both Sentinel-2 and Planet if possible.

Thanks!

Page 1 / 1

Hi @minian.matias

It is possible that May 3 image was acquired by Planetscope sensor with the footprint as displayed on your post and was delivered to Sentinel Hub as such. It seems like it was a cloudy day, hence it is displayed as white with a true color script. Regarding the UDM_clear 0 values , we will investigate and report back

Does dataMask not work exactly the same as for Sentinel-2?

Yes, it does function the same way as it does for Sentinel-2 data.

Also, is the conversion from DN units to Reflectance units ok?

Yes, the conversion factor is correct , you can always check here . Since the Sentinel-2 and Planetscope sensors are different , the differences in colour visualisation is somehow expected.

Hi,

the exact data and metadata as delivered by Planet can be inspected by finding the respective delivery in the dashboard and choosing the “Download TPDI original data” action. For your example from 2022-05-03, the original data open in QGIS look like this:

The raster image shows the red, green and blue band.

The pink area is from the metadata.json file and represents the geometry of the whole product. For this case, thus, the metadata states that the top-right portion is outside of the product geometry, thus Sentinel Hub will not use it. This explains the cut off from your example.

The values in the right are the UDM bands for the location under the mouse pointer. They are, in this case, equal for all other pixels in the raster as well:
- clear, snow, etc bands are all zero, as is the confidence band, which implies there is something wrong with this data. This explains the fully red image.
- The “unusable data mask” value is 253, which you can interpret using the product specification.

Thanks for both responses!

Related to the cropped part, is there a way to know that it’s cropped when querying catalog/process/statistical APIs from Sentinel? We would like to understand if the AOI is complete or not.

Thanks!

Yes, the geometry of the ingested data (that is, the data Sentinel Hub will try to use) can be obtained using Catalog, in your case for May 3:

https://services.sentinel-hub.com/api/v1/catalog/collections/byoc-<YOUR COLLECTION ID>/items?bbox=-180,-90,180,90&datetime=2022-05-03T00:00:00Z/2022-05-04T00:00:00Z

This returns two tiles, whose geometries look like this:

The blue one is the tile we discussed above.

Yes, but we mean programmatically.

Is there a best practice to apply or metadata in the response to look for, for us through code to understand that the image is cropped and that it’s not the complete AOI?

I am not sure I fully understand your question. While searching for PlanetScope products you get their geometries, so you can check which products’ geometries cover your full AoI. There will often be products only partially overlapping with your AoI and it is up to you whether you include those in your order or not. With subscriptions however you cannot do this, partially overlapping ones will always be ingested as well.

The process and statistical API will always use all the data that fully or partly overlaps with the AoI (and that meets other criteria of course), regardless of the input collections. For example, a process API request for Sentinel-2 whose dataFilter matches exactly one Sentinel-2 tile will also return a cropped response if that tile only partly overlaps the AoI. It works the same for PlanetScope data.