FitsImage does not properly support FITS files with BSCALE/BZERO defined

[astrofrog]

FITS files such as the following one:

https://astropy.stsci.edu/data/galactic_center/gc_2mass_h.fits

can have BSCALE/BZERO set. Currently, WWT does read in BZERO (not BSCALE) in FitsImage.cs but doesn't do anything with it.

[astrojonathan]

What would you suggest the correct behaviour should be?

[astrofrog]

This FITS standard states that values should be transformed using:

new_value = value * BSCALE + BZERO

where BSCALE defaults to 1 if not specified, and BZERO to 0.

[astrofrog]

The easiest way to do this might be that if BSCALE != 1 or BZERO != 0, we always use a double buffer and scale the values as they are read in.

[astrojonathan]

If we are only displaying the values, does this have any material value to the image generation? The offset an scale will only be undone by the display processing, and the user does not inspect any values, so it would only have effect if the default scale was from zero to max. If we already stretched from low to high linearly by default, the the user will not notice the difference.

[astrofrog]

@astrojonathan - yes this is only coming up because I am setting the scale manually via setImageScale. Maybe another idea would be to adjust the limits passed to setImageScale to account for BZERO/BSCALE?

[astrojonathan]

Do we need a fix here?

[astrofrog]

I personally think it's still something that should be fixed ideally, at least in setImageScale, so that BZERO/BSCALE are taken into account. Currently in PyWWT I convert all files explicitly to BITPIX=-32 (and also reproject to TAN and equatorial coordinates) so I can live with the current API though if needed.

[jsub1]

I think it makes sense to support setting limits and other indirect access to the data using either the raw values in the files or the scaled values. We can take the current setImageScale functionality and rename it setImageScaleRaw (or similar), and then we have a setImageScalePhysical that corrects for the BSACLE/BZERO. We keep setImageScale functioning as-is to prevent breaking anything, but mark it as deprecated in favor of setImageScaleRaw.

[jsub1]

Closed with #240