Landsat 8 Mosaicking issue in SNAP

Dear All,

I am trying to mosaic Landsat 8 scenes in SNAP. Though it worked but the output file has problem with dark background/nodata values (attached screenshot).

Any suggestions to overcome this issue. Please let me know.

Thanks!

can you please share which operator you used and which settings?
Also, did you modify the data before the mosaic?

Yes, the information ABraun requested can help us to help you.
In addition I would suggest to check the source data of the dark area in the middle. The value range seem to be totally different to the other data.
The fully black no-data area can be treated by setting a no-data value to the bands. Look up the value of the black and set this value on the properties of the band.
Here as an example an other product.

Dear Andreas,

I am using Mosaicking operator (attached screenshot) with map projection UTM/WGS84 and in Variables & Conditions, I used all the bands from image 1 and image 2 with OR .

I also tried to assign no data value as Marco suggested but it didn’t work. I see the no data value for source image is -0.9999 and that is giving the problem.

Please let me know if you need any additional info.

Thanks!

You have set the “no-data values used” property. But the no-data value is still 0.
Set this to -0.9999. Then the black area will go away.

Dear Marco,

I tried to set the no-data value to -0.9999 as you suggested but still there is black background issue.

Please see the attached screenshot.

Thanks!

in your screenshot the assigned NoData value is -1.0

Yes, because -0.9999 was rounded and converted to -1.0 automatically.

that is true. I have just tested it and I also cannot enter a float value in the NoData expression. @marpet can this be fixed?

As an alternative you can use any of the quality bands to create a valid-pixel expression, for example like this:

It depends a bit what kind of additional rasters you have in the product.

Thank you so much! Valid-pixel expression helped to remove the black background as you suggested.

Regarding the rounding of the no-data value I’ve created an issue, this should not happen.
[SNAP-1424] No-data value is rounded when setting in GUI. - JIRA (atlassian.net)

Instead of setting this to every band, it is probably doable to set a condition as mosaic parameter.

One question, where is this data from? Actually the Landsat data should already have this value correctly set. This is the case for all the Landsat products I have on my disk.
If this would be set correctly, then the mosaic would have no problem, because the count bands would be correct. Those count bands are used to decide in the mosaic where data is and where not.

good suggestion about the Condition!

Dear Marco,

Thank you for the suggestion. I have used the condition as you suggested and was able to fix the mosaicking issue. I am using Landsat surface reflectance product (Level-2 data downloaded from EarthExplorer).

Let me know if you need more details!

Little update to the no-data issue:
Actually the behavior is correct, because the raw no-data value is set here. But this is not what the user expects. It should be possible to modify the geophysical no-data value.

I’ve now tried the two products (level-2 from Collection 2 from EarthExplorer):
LT05_L2SP_230056_20100501_20200824_02_T2
LC08_L2SP_231055_20160422_20200907_02_T1

SNAP can’t open both of them.

I guess you have used the on-demand level-2 from Collection 1, right?
Can you provide it to me? Then I don’t need to order one.
Maybe via WeTransfer. Send me the link as direct message.

Yes, currently Collection-2 data are not readable in SNAP (that is another area to work).

Regarding WeTransfer, can you please share the Email that I will use to transfer the file?

Thanks!

The fill value was not read from the metadata and therefore not set to the bands. This will be fixed with the next release.
[SIIITBX-386] Fill value is not considered for Landsat Level-2 data - JIRA (atlassian.net)

Decimal fractions are converted to a binary representation. Many decimal fractions don’t have an exact binary representation.

No, it is not about the floating point accuracy. It is related to the raw data type.
But in general you are right.

Btw., setting -9999 as no-data value works for the Landsat data. Because of the scaling factor of 0.0001, this results in the necessary geo-physical no-data value of -0.9999.

1 Like

hello, sir how to solve the problem can you help me