Round of developments: Vignetting correction and Cosmic killer

[emanueledimarco]

This PR includes two main developments and some additions / fixes:

1. Vignetting correction (for LIME). This is from run 3806 with ~40 images of 10s exposure. Since the noise at the top/bottom is large, the correction is set to 1 there. The map wrt @davidepinci one is 12x12 (not 16x16) to get better the GEM slices borders

The correction is 1/this map and it is applied before the zero-suppression not to amplify the noise. In any case the noise surviving the ZS is visibly amplified, but it doesn't seem to be caught by the clustering

2. Cosmic killer. @gianlucacavoto @davidepinci From LIME with cosmics & AmBe data, it seems that there is a large occupancy of short, low density clusters in the region of low LY due to vignetting. This is visible in the "isolation" plot (number of clusters in a circle of DeltaR<5cm around a cluster vs distance from center of the sensor):

Investigating, it seems that they are due to cosmic tracks that, due to vignetting, have pieces that goes under ZS threshold and are more easily split than in the high LY region. This is partially solved by correction 1., not completely, because the ZS is done before the vignetting correction.

So the implementation of the "cosmic killer":

• each "long" track (200 pixels) is fitted with a line (nominal and systematic variation)
• the track is extrapolated along the full sensor, and intercepts are found with other clusters. If the extrapolation (cosmic killer) intercepts enough pixels of another cluster (10), the "target" cluster is flagged and variables set in the supercluster variables:
  1. sc_mindist = minimum distance of the target from the killer (2304 = sensor width means no match)
  2. sc_nmatchrobust = number of pixel matching the nominal fitted line extrapolation
  3. sc_nmatchweak = number of pixel matching the alternative fitted line extrapolation

this can be used to filter more of the clusters from unattached cosmic pieces of tracks.

With this PR two additional things come:

• Fix of supercluster pathlength. The problem was that the pathlength counted the number of pixels after ZS of the skeleton of the supercluster. Since along the crest there are still many ZS pixels, this resulted almost always in an underestimate of the pathlength. This cannot be solved completely, since the non-ZS pixels are lost in that part of the code. The approximate solution is to estimate it from the number of slices * slice radius. This seems reasonable for small enough slice radii. Few clusters seems fine:

@baracch @SamueleTorelli

• Add the inclination of the track. This is simple enough from the robust estimate of the major and minor axes from the covariance matrix of the 2D cluster. The angle is wrt the vertical (i.e. cosmics are expected around theta=0):

@davidepinci @gianlucacavoto