Incorrect obs-date in saved stacks

[MikeB838]

Dear Robin

I'm "shooting" Asteroids and use Astrometrica to check their position.
Normally I take 5 frames with 30s each.

If the Astoroid is very dark, I do not use a single frame but rather use the stack of
5 frames.

Today I found out that the observation dates of the stack (DATE-OBS, DATE-AVG and DATE-END
in the fits header) depend on the moment, at which I save the stack and are not the actual
observation dates of the single frames. (both in 16 or 32 bit stacks)

When I use the folder monitor, the single frames observation time is also transfered to the
current time (ok if thought of as if the pictures are currently taken). But when I press
"Save as 16bit stack" one hour later, the stacks observation time is stored with this
additional hour.

The part of the log, when I press "save as 16bit stack":

Code: Select all

Info    14:30:32.723274 #12 =='.NET TP Worker' (New Thread)
Info    14:30:32.723390 #12 Initializing FitsFileWriter at 2712x1538x3x0bits, RGB, 2 bytes per PEL for Loaded from fits file                        in void SharpCap.Base.FileWriters.FileWriterBase.Initialize(IFileNameProvider fnp, ColourSpaceId colourSpaceId, int width, int height, int bytesPerPixelElement, int significantBitDepth, int colourPlanes, string DeviceName)
Info    14:30:33.206317 #1  Writing capture settings file to C:\Users\Mike\Desktop\SharpCap Captures\2024-06-23\Capture\12_06_37\Stack_16bits_4frames_120s.CameraSettings.txt               in void SharpCap.Models.Camera.WriteCaptureSettingsTextAndHistogram(bool writeHistogram, string filename, string contents)
Debug   14:30:33.208128 #1  Notification (Status=OK): Stack saved to C:\Users\Mike\Desktop\SharpCap Captures\2024-06-23\Capture\12_06_37\Stack_16bits_4frames_120s.fits         in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)

I hope this is not a feature and can be corrected

Thanks for taking this into account!

best regards,
Michael

[admin]

Hi Michael,

an interesting one - unlikely to affect anything except the folder monitor camera unless you ran live stacking, left it paused for some time then saved.

I will investigate to see if the time of the last stacked frame can be used as the time for saved stack files, which should cure the issue for the folder monitor camera without any negative impact. Actually it would be nice to set both the start and end time for the saved stack according to the start time/most recent frame of the stack.

cheers,

Robin

[MikeB838]

Hi Robin,

thanks for looking!

For me the time in the folder camera is not the main problem (but worth to be corrected).
For my measurements I need exactly the observation time of the middle of the exposure.
It is correct for a single frame, but wrong for the stack.
If I shoot a fast moving asteroid it is a line not a point in a stack of eg. 5 frames of 30s, so the
exact time is crucial.
For brighter ones I only use a single frame, but the fainter ones sometimes need the stack
to crosscheck the position.

So the stack should have the start time of the first frame, the end time of the last frame and
the middle time calculated between that times ((DATE-OBS, DATE-AVG and DATE-END).

For the folder camera it would be nice, if the same applies but with the times of the original frames,
not of the newly created frames

Thanks a lot for your magnificent peace of software (eg. the Moon mosaics work great)

cheers,

Michael

[MikeB838]

Hi Robin,

thanks a lot for SC v4.1.12338 !
The use of the correct frame times in the final stack - especially in the folder monitor - helps a lot!

Sorry, but: the start time is not correct (neither in the folder monitor nor using the test camera 1)!
The end time is correct (= end time of last frame). The mid time is incorrect due to the wrong start time.

I have a fast moving asteroid pictured for 16x30s. The start time was 2 minutes off in the stack.
For this object a too big offset to measure the asteroids position correctly.

In the folder monitor: The created frame contains only a subset of the fits header information of
the single frames. Is it possible to copy all missing fits header info from the single frames to the
resulting stack? The single frames had been created by SC itself. Thank you for thinking about it!

Cheers,
Michael

[admin]

Hi Michael,

ahh, it looks like somehow it is recalculating the start point based on the end point and the total exposure, which is fine when the start point isn't known, but shouldn't be happening in this case - I will have a look - hopefully it will be the same thing for both.

Yes, the re-read of FITS headers is a bit limited at the moment, I will have to investigate how much work to re-read all of them (there are quite a lot of possibilities, and not all make sense either).

cheers,

Robin

[MikeB838]

Hi Robin,

thank you very much!

I hope it is not so much work to copy at least the FITS headers that are created by SC itself.
But I know the devil is in the detail. Thanks for checking it!

cheers,
Michael

[MikeB838]

Hi Robin,

thank you very much for the new Version V4.1.12367!

In the folder monitor: the calculation of the offset of the midtime (against start or end time) of the observation of the stack seems to be correct,
but you added the offset to the end time instead of subtracting it!
So the mid time is later than the end time in this version.

Thank you for adding more fits header to the stack!
I noticed some slight changes to: RA, OBJTALT, OBJTAZ, CCD_TEMP, AIRMASS. Are they intended?

And is it possible to further add: FOCALLEN, BITSHIFT, TRUDEPTH, FRAMETYP, IMAGETYP?
Adding seems to make sense, but even their absence do not stop me in my current workflow.

Thanks a lot again!

Cheers
Michael

[admin]

Hi Michael,

oops - I did actually subtract from the end timestamp, but I had managed to calculate the duration as a negative number (end and start the wrong way round in the subtraction), so the net result was the mid point coming out after the end Fixed for next time.

I now load all the FITS headers that are sensible to reload, which wasn't too hard, but while they will naturally end up in saved images if you save from the folder monitor camera directly, the flow of data through live stacking is more complex - I suspect that some such data is not copied to output live stacking files for normal cameras either.

I suspect that there may be rounding errors to the values that you mentioned - how big were the changes?

FRAMETYP and IMAGETYP will come from the current settings in SharpCap for frame type in the toolbar rather than the values read in. Not too sure abou t the others - will have to look.

Robin

[MikeB838]

Hi Robin

I have done software for decades, done that more than once

I add the contents of a single frame (as it comes out of SC) and the stacked result. So you can have a look:

fits_header.zip

(1.82 KiB) Downloaded 17 times

Thank you very much!

Cheers,

Michael

[MikeB838]

Hi Robin,

all times are perfect now in the stacks (16 and 32 bit / live and folder monitor) in V371.

Thank you very much!

cheers,
Michael