Updated my Astrophoto website

17 views
Skip to first unread message

wols...@gmail.com

unread,
Nov 18, 2021, 12:42:59 PM11/18/21
to CaLIGHTs
Today I finally updated my website with my 2021 astrophotos.  

Enjoy

Peter


Scott Kuchma

unread,
Dec 6, 2021, 4:39:34 PM12/6/21
to CaLIGHTs
Hi Peter ,

Sorry for the delayed response . I did not get an Alert to your Post . I was just skimming through my various URL's and spotted your 2021 Update . My , you were busy and lucky in 2021 . Very nice Showcase of your efforts .
I , on the other hand , have absolutely nothing to show for 2021 . Very depressing . I think I've lost my Mojo . LOL . Fingers crossed for a better 2022 eh ?

Scott...........

wols...@gmail.com

unread,
Dec 6, 2021, 8:56:04 PM12/6/21
to CaLIGHTs
Scott,
I think 2022 will see a resurgence in Astrophotography when on Dec 22nd the James Webb telescope is launched. Maybe, over the winter, you can put together your wedge design.  I have been bugging the Deep Sky Stacker folks to get their program capable of reading 32 bit floating point FITS. The FITS file standard already supports floating point numbers...both 32 bit and 64 bit. Obviously the resulting file sizes are bigger but the increase in resolution is very tempting.  I have a development version of CaLIGHTs that will create 16 bit and 32 bit Integer FITS, as well as 32 bit floating point FITS.

Hopefully, this year, the DSS folks will put effort into supporting 32 bit FITS format.  I am actually trying to debug their code right now. I have a C+ compiler(VS 2019) and the code for DSS is available to download. Unfortunately I am crap at C+ programming but with winter coming it might be a distraction from everything covid.

Take care and enjoy the James Webb buzz.

Peter

Scott Kuchma

unread,
Dec 10, 2021, 10:46:45 AM12/10/21
to CaLIGHTs
Hi Peter ,

I think you may have to explain some of the above to us non-Programmers (me) . I thought the Floating Point Operations were internal processing modes and independent of the resulting Output File size ? i.e. 16- or 32-bit .

When other Programs have a bit-size limit to what they can open or use it usually means they only accept 16-bit File sizes . (like GIMP and Photoshop and Faststone )

What am I not getting and how should I then try and match Outputs to Inputs ? If that makes any sense .

Scott...................

wols...@gmail.com

unread,
Dec 10, 2021, 10:06:23 PM12/10/21
to CaLIGHTs
Scott,
It does get messy when you move away from 16 bit files. CaLIGHTs reads our 16 bit raw files and immediately converts them into 32 bit floating point values. All of the calculations in CaLIGHTs are therefore floating point calculations. I designed CaLIGHTs so that it's calibrated LIGHT frames are 16 bit FITS files. This was because programs like Deep Sky Stacker only accept 16 bit formats...right now. It's actually quite easy to create a datafile that contains 32b floating point numbers. CaLIGHTs has been creating temporary files that contain 32 bit floating point numbers all along. CaLIGHTs uses temporary files to avoid consuming large amounts of RAM memory as it performs all of its calculation. You may not realize this but the MasterBIAS, DARK, FLAT and DARKFLAT files that CaLIGHTs generates are all 32 bit floating point FITS files. I just "invented" the MSTR file extension for master files just so they were easy to find. Basically, it's very easy to create datafiles that are any arbitrary data type. I believe the FITS standard includes up to 64 bit numbers!

Most other programs are limited to 16 bit files. I did read, just this week, that SIRIL will read 32bit FITS files so maybe the folks writing SIRIL have heard the same rumours I have about 32bit image files become possible.

There ends up being very little need to match input to output files 16b, 32b etc.  Remember that Deep Sky Stacker takes in your 16b raw files, or CaLIGHTs 16b raw files, and after stacking them creates an output file that is a 32 bit floating point FITS file. That 32 bit floating point file is then brought into Photoshop or SIRIL or GIMP or Startools where the image is stretched, filtered, coloured...and then the images are written to disk as either 16 bit TIFFs or 8 bit JPEGs.

I'm interested in 32b floating point files because I believe there may be some calibration "goodness" that may be lost when CaLIGHTs writes the data out to 16 bit FITS files.  My research has yet to prove that going beyond 16b will have any meaningful benefit in the quality of the final images...but I am always curious....and I may need to add 32 bit support if these rumoured cameras do appear on the market. Actually, CaLIGHTs already does support 32bit RAW files...there was never a need to mention it until now.

Peter

Scott Kuchma

unread,
Dec 11, 2021, 12:26:47 PM12/11/21
to CaLIGHTs
Hi Peter ,

Thanks for taking the time to explain all of this . Very interesting . So it looks like DSS is the bottleneck at the moment ?

I see SiriL has released v1.0.0 rc2.0 after fixing some bugs in rc1.0 . Glad they're moving to being able to read 32-bit FITS . GIMP will have a new version , 3.0 , soon and it too is rumoured to be able to handle higher bit depths .

You've heard rumours about 32-bit Cameras ? Where ? Very interesting . Hopefully all this will mean better , and easier , Processing in 2022 !

Scott................

wols...@gmail.com

unread,
Dec 11, 2021, 2:47:00 PM12/11/21
to CaLIGHTs
Scott,
I would like DSS to offer 32 bit support. I have studied their code and 99% of it is there for supporting 32b images. I think it may become necessary soon.  Right now I have to admit that 65,535 brightness levels in a 16b image is impressive and very capable.  My concern is that most DSO occupy a tiny, tiny, tiny range of values in most RAW astrophotos only because we always need to protect against bloated stars.  Stretching the image to pull out the details in a DSO raises the risk of the 16 bit quantization being visible. I keep looking for it in my astrophotos but the jury is still out. The bottom line is that I can't say that 32 bit is justified right now.

QHYCCD has already enabled 32bit data transfers for their latest batch of cameras to cater for in-camera binning and enhanced fullwell capabilities. I will put up a link to the QHY site a little later today....I gotta run some errands right now.

Peter

wols...@gmail.com

unread,
Dec 11, 2021, 3:30:27 PM12/11/21
to CaLIGHTs
Here is a link to the 32 bit data transfer protocol documentation published by QHYCCD

Peter

Reply all
Reply to author
Forward
0 new messages