Your summary is pretty spot on. But you may be in luck... another user recently posted the work around you seek :grin:
Until v7.5 is released (soon, I promise! ), perhaps his script will work for you
This post is a follow up on the previous post, but let me remind the context:
I am would like to inform a coastal study using a temporal series of Landsat images. To ensure data quality, I am willing to process Landsat 8 OLI - Collection 1 with l2gen for atmospheric correction, as described in the following paper:
Franz, B. A., Bailey, S. W., Kuring, N., & Werdell, P. J. (2015). Ocean color measurements with the Operational Land Imager on Landsat-8: implementation and evaluation in SeaDAS. Journal of Applied Remote Sensing, 9(1), 096070–17. http://doi.org/10.1117/1.JRS.9.096070
I overcame the first obstacle that was the format incompatibility (i.e. SeaDAS accepting only pre-collection images, although such images are no longer available for downloaded on USGS database) thanks to the script kindly shared by a member of this forum.
In a second step, I processed the now-compatible L8 image with l2gen in SeaDAS 7.4. It outputted the file "L2016038160136.L2_LAC_OC".
Now, I would like to visualize this image into SeaDAS (and/or export it as GeoTIFF) but I get an error message when trying to import it:
"An exception occurred: Type: java.lang.illegalStateException
Message: DataBTree doesn't start with TREE"
Any idea on how to address this? Also, any recommendation as far best user practice when it comes to work with Landsat for coastal science would be so welcome!
Speculating here, as I don't know the size of your resulting L2 file, but it's possible that your SeaDAS instance doesn't have enough allocated memory. Landsat OLI images can get quite beefy...
Try increasing the memory allocated to the process:
And change -Xmx1024M (the default) to something like: -Xmx2048M or -Xmx4096M (depending upon how much RAM your system has ...don't try to exceed the available system memory!)
Thank you so much for your reply, and sorry for being so late in mine. I have been caught up with other tasks. I finally got to give SeaDAS 7.5 a try, and it worked like a charm! Thank you for the great work!
A few questions related with that, though:
- Would you recommend anything else than the default parameters to process Landsat OLI Collection1 images in L2gen?
- When inspecting the processed file, I see that the reflectance values in Rrs443, Rrs482, Rrs561, and Rrs655 are mostly included between -0.01 and 0.004. I am surprised to (i) have negative values; and (ii) have such small values overall. On the other hand, according to the metadata, there is a scale factor of 2.0E-6, and an offset of 0.05. Can you help me making sense of this?
- When trying to create a RGB image with the bands from the processed L8 image, I get an error message : "the String index is out of range: -1". Any idea?
Thank you for the support, and again, thank you for the great work with SeaDAS 7.5!!
OLI is not an ideal sensor for ocean color retrievals. While we have implemented the ability to process it, not much effort has been put into ensuring the instrument will produce valid retrievals.
The defaults for aerosol selection and vicarious gain coefficients were provided to us by Nima Pahlavan based on his recent publication:
N. Pahlevan, J. R. Schott, B. A. Franz, G. Zibordi, B. Markham, S. Bailey, C. B. Schaaf, M. Ondrusek, S. Greb, and C. M. Strait, "Landsat 8 remote sensing reflectance (Rrs) products: Evaluations, intercomparisons, and enhancements," Remote Sensing of Environment 190, 289-301 (2017).(yes, I'm a co-author)
While these defaults may work for you, they may not. Having negative Rrs is not unusual in coastal waters when the aerosol retrieval is allowed to be selected by the algorithm (i.e. the default)
as where there is significant water-leaving reflectance in the NIR (or even SWIR - although less likely there) channels, the algorithm may not adequately account for it and more signal is attributed to aerosol and removed, thus lowering the water-leaving component. ...or it could be real (slightly negative is OK if the signal is genuinely small and the SNR of the instrument is low - which it is for OLI, at least for ocean applications). This is where the user needs to evaluate the processing options for appropriateness. The l2gen program is extremely flexible ...so your options are vast...play around and have fun with the data :)
The scale factor is just there to put the bands into a scaled integer in the data file. SeaDAS applies these properly to report the floating point value.
I'll leave your third question for Danny to answer :grin:
- Subject Matter Expert
- Posts: 221
- Joined: Mon Apr 07, 2008 4:40 pm America/New_York
Please tell us exactly how you are creating the RGB image so we can replicate this. Include the name of the file you are using, which 3 products you are using for RGB, as well as any transformation expressions entered in the profile.
I just tested this and created a true color (RGB) image using an OLI (Landsat 8) file in SeaDAS 7.5 and it worked fine for me. The file I used is LC08_L1TP_169029_20180410_20180410_01_RT.tar and I used the band-products rhos_655 rhos_561 rhos_482 to create the RGB image. The configuration profile I used is "OLI_TrueColor_(655,561,482)_Log". (Note: I set range for each channel to min=0.1 and max=0.8)
Thank you for helping figure this out.
I am trying to create a true color image from the L2 file generated from the image LC08_L1TP_017040_20150220_20170301_01_T1 with L2gen (default parameters).
When selecting the Old_TrueColor_(655,561,782)_Log profile, I get an error message warning that "the profile is not applicable for the selected product". Therefore, I manually input the RGB bands (Rrs655, Rrs561, Rrs443).