implemented using bscale for storing std

[tammojan]

This stores the standard deviation as uint8 with the standard FITS keyword BSCALE=0.1, which means all stored values will be scaled down by a factor 10 by all FITS-compliant software (including Astropy). This means that the values for the standard deviation with this change are limited to the range 0 to 25.5, and have one digit of precision.

I have tested this on my camera NL000D, so far everything works as expected, but I'll report back when I've had a clear night.

A side effect of this is that when opening FITS files with astropy and writing them back (something that RMS and CMN_binviewer do not) the values will be stored as floating point numbers, increasing the file size. This can be avoided by opening them with astropy.io.fits.open(FFbla.fits, scale=True) (note that the scaling always happens, this refers only to the writing behavior).

As suggested by @cbassa in #74

[dvida]

This needs to be conditional on whether the fits format is used or not. RMS can produce the CAMS-format bin files, and this won't work there.
Also, I don't think this is really an issue at all. Even if the stddev is only 1, the meteor still needs to be 4 levels above the background, which is really really faint.

[tammojan]

I can make it conditional on using FITS I think.

I think the issue will occur more when the stddev is less than 0.5, which will be rounded to zero and make those pixels unusable. @cbassa mentioned that he ran into this when trying to detect satellites, maybe he can expand a bit.

[dvida]

The line below the stddev computation limits it to a minimum value of 1, to avoid zero division errors afterwards: https://github.com/CroatianMeteorNetwork/RMS/blob/master/RMS/CompressionCy.pyx#L163
This effectively takes care of those issues.