StarTools

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

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

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

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.

I will try to add support for the LIVETIME keyword. It's a tricky one catering to all possible stackers and their idiosyncrasies.

... 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...

admin wrote: ↑Sun Dec 18, 2022 10:44 pm I will try to add support for the LIVETIME keyword. It's a tricky one catering to all possible stackers and their idiosyncrasies.

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