Good morning,
I would like to understand why some pixels get after the Radiance to Reflectance processor have an NaN value.
Do you have an explanation for that ?
Is it do to some pixels which are not correctly extracted during the processing ?
1 Like
I have exactly the same question.
I still don’t understand why…
It may be due to some atmospheric corrections which are not correctly computed, but I cannot prove it (~black box).
Somebody else has the same issue except us ?
Good morning,
I would like to understand why some pixels get after the Radiance to Reflectance processor have an NaN value.
Do you have an explanation for that ?
Is it do to some pixels which are not correctly extracted during the processing ?
https://sentinel.esa.int/web/sentinel/technical-guides/sentinel-3-olci/level-2/radiance-to-reflectance-conversion
I guess that these issues are due to some atmospheric corrections which are cannot be computed (==> NaN).
Thanks.
Older post : (it’s a difficult issue to resolve alone wink: )
https://forum.step.esa.int/t/nan-after-the-processing-radiance-to-reflectance/9740
Do the NaN values correspond to the invalid quality flag?
Maybe you can show some image of the result and tell on which product you experience this issue.
As a note, during the radiance-to-reflectance conversion, no atmospheric correction is done.
Hello marpet,
I have the issue on some OLCI images.
I join some example below. In this example, I show the image in Radiance before applying the processing Radiance to Reflectance as well as a specific area in the output (Reflectance). Here, I showed only the 20th band, but this issue occur also in the orther bands (but not necessary with the same density or positions of black dots…)
Can you explain me marpet where I can find some invalid quality flags ?
In my output product (Reflectance), I can’t find any “quality flag” pannel…
One example (OLCI L1b) :
Name of the product used :
S3A_OL_1_EFR____20180308T123505_20180308T123805_20180308T142528_0179_028_337_3960_MAR_O_NR_002.SEN3
Radiance 20 : (before the processing “Radiance to Reflectance”)
Specific area of Reflectance 20 (caused by the Radiance to Reflectance processing)
I have exactly the same issue with other products.
I think that I have to select all the NaN with a band math operator in order to create a mask: how can I do that ??
I can’t find any operator isNaN in SNAP.
What is for you the issue with this processor if it’s not due to some atmospheric corrections (how is it possible to convert radiance to reflectance without these kind of corrections ???) ?
Thanks.
Regards,
arossCLS
The Rad2Refl is only a conversion. It stays at TOA. That’s why it is not an AC. It is explained in the help.
You can find the quality_flags already in the L1 product. If flagged as invalid the Reflectance is not computed. You can enable an option, than it is copied into the resulting product.
You can check the flags with the PixelInfo View.
I checked your product.
In your case the NaN values result from TOA radiances which are zero.
I consider this as an issue and create ticket for it. (SIIITBX-185)
Thanks for the report
Ok thank you for the report; I would have never find this issue alone.
Do you know where I can find the Solar Spectral Irradiance values in the OLCI L1b product ?
What is exactly an auxiliary data ?
Regards,
arossCLS
I didn’t see specific problem reported in the Flags window which could be caused by some zero values in the OLCI L1b and in the output products…
The solar irradiance is stored in the bands solar_flux_band_# solar_flux_band_1
For MERIS the solar irradiance is stored in files, which are provided with the software. If you want to have a look:
No, the zero value is not reported in the flags. You can see it in the radiance values:
Thank you Marpet.
I didn’t really understand one think; in the equation related to the conversion between Radiance to Reflectance, if L_{TOA} = 0 (radiance = 0), then the reflectance R_{TOA} should be zero also (why NaN instead)???
Yes, that’s the bug.
I just want to add that I can’t use any filter in this kind of image because the convolution creates big holes in the images due to the lack of data caused by these NaN…
I hope that this issue will be resolved soon because it semmes to be quite easy to resolved futhermore, no ?