The auto-detection of the exposure time of images loaded in Compose is a great idea, but it doesn't work for files produced by Siril (via SirilIC if that makes any difference).
It looks like siril is writing two different header values and ST picks the wrong one.
EXPTIME is the individual exposure time
LIVETIME is the total stacked integrated time
I don't think there's anything I can change in Siril/SirilIC to alter their header wrinting behaviour.
Alex
Incorrect Exposure Time in Compose
Incorrect Exposure Time in Compose
- Attachments
-
- Screenshot 2022-12-16 150806.jpg (9.47 KiB) Viewed 22402 times
Re: Incorrect Exposure Time in Compose
Hi, for APP files it works correctly. FITS data is showing total integration time as "EXPosure time", while I think Siril's labelling makes more sense, there doesn't seem to be any Lifetime parameter available in APP files. Not sure about DSS, PI etc.
Clear Skies,
Jochen
Clear Skies,
Jochen
Re: Incorrect Exposure Time in Compose
Yes, I'm sure it's going to be different for each stacking appllication.
Maybe take LIVETIME if it's set, and if not use EXPTIME
Maybe take LIVETIME if it's set, and if not use EXPTIME
-
- Posts: 1166
- Joined: Sun Jun 20, 2021 10:05 pm
- Location: Alta Loma, CA
Re: Incorrect Exposure Time in Compose
Agreed, this could possibly be difficult.
For me, using ASTAP, sometimes it works and sometimes it doesn't.
I'm not sure if it's something I did, or if perhaps I'm looking at stacks made with different ASTAP revisions. But, I can sometimes look at the FITS header in some stacks and the EXPTIME filed is appropriately the the full integration in seconds.
However, with other stacks the EXPTIME is the subexposure (like 300s), and you'd have to look at the filed LIGH_CNT and multiply that by the EXPTIME.
I'll do some tests and see if I caused it. Could be due to straight stacking the one (all I had was L), and the other being split but registered multi-filter stacks that were not then combined into a single RGB stack, since of course I wanted to compose in ST.
But again, unless Han and all the other stacker creators start following a certain standard, there will probably always be times this nice exposure pre-fill in Compose doesn't work.
For me, using ASTAP, sometimes it works and sometimes it doesn't.
I'm not sure if it's something I did, or if perhaps I'm looking at stacks made with different ASTAP revisions. But, I can sometimes look at the FITS header in some stacks and the EXPTIME filed is appropriately the the full integration in seconds.
However, with other stacks the EXPTIME is the subexposure (like 300s), and you'd have to look at the filed LIGH_CNT and multiply that by the EXPTIME.
I'll do some tests and see if I caused it. Could be due to straight stacking the one (all I had was L), and the other being split but registered multi-filter stacks that were not then combined into a single RGB stack, since of course I wanted to compose in ST.
But again, unless Han and all the other stacker creators start following a certain standard, there will probably always be times this nice exposure pre-fill in Compose doesn't work.
Re: Incorrect Exposure Time in Compose
I will try to add support for the LIVETIME keyword. It's a tricky one catering to all possible stackers and their idiosyncrasies.
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: Incorrect Exposure Time in Compose
... probably ST would just need to take the biggest value of both EXPtime and LIVEtime ( whatever available), to be on the save side for most scenarios...
Re: Incorrect Exposure Time in Compose
Thanks Ivo.
Supporting all stackers and what they do to the headers is going to be impossible, but hopefully there are a few quick wins available