WBPP 2.1 file name group items vs fits, FLAT keyword

Linwood

Well-known member
Finally upgraded and trying out the new WBPP 2.1.

SET-TEMP is a fits header that now, with dash support, works, so my files come up with -10.0

I have some library items without anything in the header for SET-TEMP, so I renamed them to have SET-TEMP_-10.0_ in the name (and other temps of course).

These come up as -10 (no decimal .0).

WBPP then doesn't match these up because of the trailing decimal-zero.

Is WBPP supposed to ignore decimal points? I'm guessing it does due to the file "type" conventions.

Also, and maybe I just missed something -- previously I thought a file starting with FLAT was presumed to be, well, a FLAT. When I loaded them they ended up as LIGHTS? I can force them easily to flats so no big deal, but ...?

The real killer for me is the -10 vs -10.0 as I don't see an easy way to mass-change file headers (I could put them in there instead of the name). Is there a trick, for example to say "this is a numeric field treat it as such"?
 
Almost as soon as I wrote this I found one workaround -- the file name apparently overrides the FITS header, so I mass renamed the files to have the temp (with the decimal, that then was ignored) and it matches the darks. Ugly but workable. Is there a better way?

is there a "mass update fits header", I see people volunteered scripts, but no built in way? I'll dig up one of the newer scripts and try if not.
 
Finally upgraded and trying out the new WBPP 2.1.

SET-TEMP is a fits header that now, with dash support, works, so my files come up with -10.0

I have some library items without anything in the header for SET-TEMP, so I renamed them to have SET-TEMP_-10.0_ in the name (and other temps of course).

These come up as -10 (no decimal .0).

WBPP then doesn't match these up because of the trailing decimal-zero.

Is WBPP supposed to ignore decimal points? I'm guessing it does due to the file "type" conventions.

Also, and maybe I just missed something -- previously I thought a file starting with FLAT was presumed to be, well, a FLAT. When I loaded them they ended up as LIGHTS? I can force them easily to flats so no big deal, but ...?

The real killer for me is the -10 vs -10.0 as I don't see an easy way to mass-change file headers (I could put them in there instead of the name). Is there a trick, for example, to say "this is a numeric field treat it as such"?
Hi @Linwood,

when the keyword value is read from the fits header it's taken entirely as it is, so these files have the complete "-10.0" text.
Differently, when the keyword value is read from the file name, only alphanumeric chars and the minus are valid so the text is truncated at the dot.
The good news is that in the next WBPP 2.1.3 this constraint is relaxed and the dot, along with other special chars will be valid chars read from the file name too.

For now, as a temporary solution, you can move your files under a folder named "SET-TEMP_-10", this will have the precedence to the fits headers content and your files will be recognized to have "-10" as SET-TEMP value.

Robyx
 
Almost as soon as I wrote this I found one workaround -- the file name apparently overrides the FITS header, so I mass renamed the files to have the temp (with the decimal, that then was ignored) and it matches the darks. Ugly but workable. Is there a better way?

is there a "mass update fits header", I see people volunteered scripts, but no built in way? I'll dig up one of the newer scripts and try if not.
great to hear! massive rename yes, but if you don't want to rename the files just move them into a folder properly named :)
 
Thanks, I also tried again and this time it put flats in flats, no idea why it once loaded in lights.
 
Back
Top