Dear Mike, Thanks very much for the updates. Indeed, the IOP modelling used in the bandshifting does not include fluorescence so I would not play with the red bands too much. If we add 681 we might also consider 678 (from MODIS). At a higher level, obviously we should ponder seriously the choice of bands, including as far as users are concerned. CCI versions are coming at a rate of one per year, which is nice because it means progress, but any investigation with a version is not reaching the possibility for a manuscript submission before another version is out. If at the same time, the band set is changed while people have got used to the SeaWiFS bands, it might generate irritation (for the few who are using RRS). Perhaps we could consult a sample of users we know are using RRS? Another possibility would be to have both band sets available for V4 (but it means a lot more data). Technical details: Below you might find updated coefficients for aph, adding 620, 678 and 681 (for completeness). On your concern associated with a comment in Init_Water_Iops: there should be no problem if the argument 'sensor' is defined and the keyword iop_wat_outband_opt is set; then the first option of the routine is activated and the IOPs are calculated (the second option would indeed go to tabulated values that were initially made for SeaWiFS). Best, F. a_hash = hash('412',0.0323,'443', 0.0394,'488',0.0279,'510',0.0180,'531',0.0115,'547',0.00845,'667',0.01685, '678', 0.0193,'665',0.0152, $ '413',0.032775,'490',0.0274, '560', 0.0062, '555', 0.007, '620', 0.0065, '670', 0.0189, '681', 0.0174, $ '410', 0.0313, '486', 0.0285, '551', 0.0078, '671', 0.0193) ; VIIRS UPDATE b_hash = hash('412',0.286,'443', 0.3435, '488',0.369,'510',0.260,'531',0.134,'547',0.0625,'667',0.140, '678', 0.158, '665',0.134, $ '413',0.28775,'490',0.361, '560', 0.016, '555', 0.0315, '620', 0.064, '670', 0.149, '681', 0.1515, $ '410', 0.283, '486', 0.373, '551', 0.048, '671', 0.151) ; VIIRS UPDATE -----Original Message----- From: Mike Grant [mailto:mggr@pml.ac.uk] Sent: Wednesday, November 2, 2016 11:03 AM To: Frederic Melin ; 'PML OC-CCIers' Subject: Re: [oc-cci] v4.0 OLCI bandshifting Hi all, Fred: thanks for the comments - we had a quick chat on Monday (main points below) to organise ourselves to do a few tests (main points below!), prior to hoping you might be available for a short telecon sometime in the next week or two. Tom's going to try and set that up separately. -------------------------- Main points from the Monday chat: In general, we want to use MERIS/OLCI bands where it makes sense. The "main" bands are close enough to SW that it's unlikely to be a problem. 620 might be useful, but isn't well supported by other sensors. Bandshifting to it from other "nearby" bands is quite suspect, as "nearby" might be 50nm! Shubha proposes that we include it as a "raw" band (i.e. present only when MERIS/OLCI is present). This will make the data harder to use consistently, but means 620 is there if we want to try it. It's also easy to implement. 681 is also interesting (fluorescence), but we think the bandshifting model doesn't include it, so couldn't reliably fill this band in for sensors that don't have it. Shubha proposes we also include it as a raw band. For the bias-reference (which can be independent of the bandshifting-reference), Shubha proposes MERIS as a step in the direction of OLCI. Mike fretted annoyingly about the eastern camera making a mess of things and the difficulty of overlap with other sensors (VIIRS & OLCI). We agreed to do some tests: 1. look at the existing MERIS-SeaWiFS bias maps and see if there's any visible naughtiness. Similarly look at existing data to search for problems. 2. generate a MODIS-MERIS bias map (and reverse the MERIS-SeaWiFS to a SeaWiFS-MERIS), and run some tests through to end products. Look for nasties. 3. if possible, try doing some bandshifting tests to OLCI/MERIS bands -------------------------- Results of tests So far, we've done #1. The results are: We can see a faint ripple pattern in the MERIS-SW bias maps that we don't see in the MODIS-SW ones. We believe this is from the camera boundaries. It's fainter than the GAC/LAC Hawaii band, though obviously it's not always in a single place, as the GAC/LAC band is. It's most visible in the gyres. In some places it's not visible. We assume that it's present globally, so the bias maps will have a variation in a given pixel depending on which MERIS camera observes it. As we don't have any compensation for these detector effects, this basically means a higher "noise" level in the maps. This ripple pattern will inevitably come out into the final products, though it may not be easily visible in normal viewing conditions; need to test this. Things to discuss in a future telecon: - bandshifting and raw band proposals - MERIS as a bias reference (or other sensors) Cheers, Mike. On 21/10/16 10:10, Frederic Melin wrote: > Dear Mike, > Sorry I have not been reactive on this ; we can discuss this in November (I'm away next week). > From the software point of view, there should be no problem for 'normal' cases. 620 is a bit of trouble: from a coding point of view, we could adapt a solution similar to the 531/510 approach, where there is 2 band shifting (for instance: 531->510 and 488->510) and an average. However the validity of this is weak indeed. For the red, I'm always avoided to look at issues like fluorescence, non-elastic phenomena in general... > Best, > F > > -----Original Message----- > From: Mike Grant [mailto:mggr@pml.ac.uk] > Sent: Thursday, October 13, 2016 4:27 PM > To: PML OC-CCIers ; Frederic MELIN > > Subject: [oc-cci] v4.0 OLCI bandshifting > > Hi all, > > I've just been poking through the bandshifting code to see how hard > it'd be to change it to produce OLCI compatible bands. Some bits look > easy, some need guidance from Fred. It probably also would benefit > from a sanity check on the whole idea ;) > > Assuming it's sane enough to try it and see what happens, we should > decide exactly which bands we want to (try and) produce. See the > attached spreadsheet. The only "new" ones that are plausible to > produce > are: > 620 (weak support) > 681 > 753 > 778 (weak support) > 865 (hard work) > > Which, if any, of these are desirable? > > If we go ahead on this, the bits that need further guidance from Fred are: > > 1) may need Bricaud coefficients for new bands in > IopSpectralModel.pro > (get_A_B_Bricaud) and have no idea where to get them ;) > > 2) these comments for Init_Water_Iops in QAA_Context.31.pro scare me: > ---- > ; COMMENTS: > ; 1. For now, only SENSOR with pre-defined pure water IOPs is SeaWIFS. > In that case, make sure the input bands are > ; exactly equal to following array: [412,443,490,510,555,670]. > ---- > - do we need to update something here, if we're using a different bandset? > > Cheers, > > Mike. Please visit our new website at www.pml.ac.uk and follow us on Twitter @PlymouthMarine Winner of the Environment & Conservation category, the Charity Awards 2014. Plymouth Marine Laboratory (PML) is a company limited by guarantee registered in England & Wales, company number 4178503. Registered Charity No. 1091222. Registered Office: Prospect Place, The Hoe, Plymouth PL1 3DH, UK. This message is private and confidential. If you have received this message in error, please notify the sender and remove it from your system. You are reminded that e-mail communications are not secure and may contain viruses; PML accepts no liability for any loss or damage which may be caused by viruses.