Save as 16bit Fits instead of 32?

Mmmmmm, good question. I think it'll be 16-bit if the masters are 16-bit, but it would be nice to have a conversion for fits saving indeed. With saving to tif (you can select 8, 16 and 32-bit) and jpg it works. Let's tag Mabula (@Mabula-admin).

Vincent, my source files are all 16 bit fits.  If I calibrate my lights and save the resulting data as fits, the files are 32bit.  I thought perhaps the ability do change the output to 16bit fits was already present in APP and I was overlooking it. It's not something I would need to do on a regular basis, so not a big priority by any means.  Thanks

Does this also happen when the (create 32-bit masters) option is unselected? If so, I have to say I don't think it does output to 16-bit in another way. Not that I'm aware of at least, never used photoshop to process further so never encountered it as a problem, but I certainly think it should be an option (@mabula-admin).

Dear Scott  @skestergmail-com & Vincent @vincent-mod,

Let me explain in detail what APP does:

In 2) Calibrate, if you let APP create 32bits Masters, then the calibrated data will always be 32bits. If you disable the creation of 32bits masters, then the calibrated data will still be 16bits IF the light frames are 16bits. If the light frames are 32bits, then the calibrated frames will be 32bits as well.

Now if you create an integration, the result will always be 32bits in APP. The data normalization in 5) Normalize will convert all 8bit & 16bit data to 32bits. This is required for good data normalization and also ensures that APP, as an application, has no issue with normalizing data of different bit depths of different sources (different camera's/captures software).

So the integration will always be 32bits. However if you load the integration into the image viewer by double clicking on it, you can save it to another data format and/or depth with the save button below the histogram. You will be able to save it with or without a stretch applied. So if you just want the 32bits integration converted to 16bits then:

1. double click on the integration in the frame list, this will load the integration into the image viewer.
2. disable the stretch box next to the save button
3. click on save
4. save as FITS
5. choose 16bits

Now, I would always recommed to not do this. You will be throwing away data which is very important to get a good processed result after stretching the data. So if you want to save the 32bits integration as 16bits, at least apply some stretch on it before saving it to 16bits.

Let me know if this is clear and makes sense 😉

Kind regards,

Mabula

Mmm, I just tried on a 32-bit integrated result, but I don't see an option to change the amount of bits. So step 5 doesn't show up for me. It only shows up for tiff and jpeg.

Posted by: Vincent Groenewold - Moderator

Mmm, I just tried on a 32-bit integrated result, but I don't see an option to change the amount of bits. So step 5 doesn't show up for me. It only shows up for tiff and jpeg.

Yes, same for me.  If saving as tiff I am prompted to choose bit depth, but not for fits files.  

Hi Vincent @vincent-mod and Scott @skestergmail-com,

Okay, yes indeed, I will make sure that this is possible in the next release 😉

Mabula

Guys, is it possible to have an option to save normailzed Light files as 16bit?  It seems to be saving as 32bit which end up creating 300meg+ files sizes for each light saved.  

I would be very interested myself in the feature WB91 was asking for: with DSLRs like EOS 2000D fits run in the 300MB size range and processing slows a lot, besides creating some disk space issue.

This is of particular interest to me since I usually take many short exposures (like 200 20s exposures) and with such sizes both time and space needed for processing are becomeing critical.

I'm in the same boat as lucacheli . Actually, it's even more severe for me. I'm on an Alt-az mount and takes a large number (e.g. 600) of  short subs (6-10s).  300MB * 600 is 180GB .

Another (perhaps very stupid) question is if I need to save normalized light frames on the disk before the integration. If I don't have to, I'd not have the disk space issue (the processing time is still an issue, though).