FWHM in fits header

[Riaandw]

Goodday

Is it possible to sort captures?

Folder structure- Date\TargetName\ImageType\ END OF FOLDER STRUCTURE

File Name- \{FWHM}{FrameType}{TargetName}{Gain}{Exposure}{SensorTemp}{FrameNumber}

This way its easy to cull shitty captures.

To essentially have all live stack saves in the same folder per target per date, and all saved frames in a separate folder per target with individual names for each frame.
This is not working. I now have to copy all into one folder... And guess what? The files have name conflicts.
https://photos.app.goo.gl/LhkcQZysiKRd1pU5A


How do I go about setting this up? Thank you for the assistance.

[admin]

Hi,

I think what you are missing is having either the {Time} or {FrameTime} in the template for the file names - without those, if you do a live stack on the same target twice in the same day, you will likely get files with identical names.

You also need to look at the 3 bottom template patterns which are used to set up the filenames used for live stack saved file - the top two templates which affect normal captures are not used for the filenames when live stacking.

Hope this helps,

Robin

[Riaandw]

Thanks Robin. I play around with those. Do you think I will succeed in getting it to save to the same folder by editing the naming templates?

Is there a way my image names can start with the FWHM figure for the capture?

[Riaandw]

The issue with having everything spread over 100 folders is post-processing those saved images. I don't want my capture software to make it more work, it should make life easier, right?

[Riaandw]

I think I have resolved the folder structure. All raw saved frames are now being saved to a single subfolder per target with individual names for every capture.

I cannot find any information on how to include image weight via FWHM in the file name. Is there a way to do this?

[admin]

Hi,

actually, no, there isn't a way to inclde the FWHM in the filename. I suppose the reason behind this is that in the normal image capturing process, SharpCap doesn't bother to detect stars in each image or work out the FHWM. The detection is only carried out when there is some tool in SharpCap active that needs information on the position of stars or their FWHM. From the user point of view, this keeps the CPU usage down when just capturing as detecting stars would probably use more CPU time/power than the rest of the capture and save process for a frame.

If you are live stacking in SharpCap then the star detection is necessary for the alignment, so the FWHM gets calculated as a by product of that - in that case, the FWHM will get added to the FITS headers of the saved raw live stacking frames. Not sure if that is helpful.

cheers,

Robin

[Riaandw]

Thanks for the reply. Do you know of a way to arrange files by the FHWM in the FITS header? If the information is already there, it should not be impossible to add it to the file name. Perhaps SharpCap can enable this in future. I can see the need for raw speed during planetary work, but we are now also doing deep sky with your software. We are now in the region of 4fps; the measurement has already been completed in the quality gate. It's there waiting to be used. Planetary wouldn't make use of the FHWM with ser files either.

Even at 4 frames per second, we are talking about thousands of files. FHWM in the file name allows us to sort by name and cull the unwanted **% in seconds. I know live staking has the quality gate already. It also knows the quality of the saved fits file already.

Another question, I guess saving to ser file is not possible when deep space live stacking?

[admin]

Hi,

I'm sure there must be software that lets you sort and filter FITS files based on header field information. Stacking programs may well show the FITS header data when you load multiple files and Astap has some batch processing capabilities, but I didn't see one to filter on FWHM. I did have a quick search around to see what else might be available, and Fits4Win looked like a possibility (https://astroshed.com/fits4win/fits4win2doc.htm) although you do need to pay for it.

I will have a look at adding the FWHM tag to the raw image saving from live stacking, where the FWHM data is already being calculated. That doesn't impact anything in terms of performance. For normal captures it will require more consideration, because detecting stars for a large image could take several seconds on the sort of low end 'mini PC' hardware that some people use.

As you suspect, saving from deep sky live stacking is to still image formats (PNG, FITS, etc) only.

cheers,

Robin

[Riaandw]

Thanks Robin. I'll find my way around.

Might just abandon the live stacking and capture SER for the time being. That's easier to process and discard a set percentage. My other stacking programs do not do well past 1000 files.

SC has come a long way since using it 3 years ago. Keep up the good work.