I worked a bit with pyFAI-calib (and pyFAI-recalib) in version 0.9.2
and 
suggest some updates/fixes, see the attached patch. I hope they are
easily 
mergable with the development that you did in the master branch.

I took care of these issues:
- added the possibility to interactively remove a single point from
the
   current group in the peakPicker - a useful feature if some rings
are
   close to each other and some not (i.e. one cannot play too well
with -g
   option).
- disconnect 'onclick' from 'button_press_event' once editing of
points is
   done (otherwise 'onclick' was still called when stating ring
numbers)
- little changes to 'figure 1' display (where points and rings are
drawn):
   * add a colourbar
   * colour range ignores first/last per mille of pixel intensitites
to
     help with strong outliers (my test image had basically one colour
only
     otherwise, even in log scale)
   * add a title to indicate that
- correct logging information about adding full groups or single
points
   etc. (sometimes group number was off by one, etc.)
- logging info from onclick(..) now tells it comes from
pyFAI.peakPicker
- avoid redrawing of annotation if only points are added (helps to
keep
   control where the annotation is - close to the first point!)
- document existing (and very useful!) option to add new group to
current
   one (right-click + m) 
- choosing the ring number after groups are defined gave some odd
default
   values, e.g. 'None' for first ring if no rings read from file
- avoid redrawing of previous rings when rings are searched and
plotted in
   pyFAI-recalib
- to validate the calibration, I added drawing of vertical lines at
the
   2theta/q/r value of each used calibration ring (in calibration.py)
   Unfortunately I access a private member (ControlPoints._angles),
but
   I do not know how to access the used angles otherwise.
   For unit=R_MM I am also not sure whether the conversion from 2theta
is
   correct ingeneral. What exactly means unit R_MM? Which frame?
Distance
   relative to what? My formula should be correct if the frame is the
   detector after moving it such that it is orthogonal to the beam and
R is
   vs. beam centre

Some miscellaneous issues I encountered, but did not address:
1) saturation option is ignored if neither dark nor flat files nor
    cutBackground nor > 1 input file
2) if image is processed by averageImages, result files are called
    'merged.*' even if it is a single image! Nasty e.g. if problem 2)
is
    solved by applying averageImages
3) Would like to have an option to choose between linear and log
colour
    scale.
4) points of a group change coulor if points added or removed

Cheers

 	Gero