Are you sure to reload the result.fits?
Yes I’m sure I reloaded the result.fits with Siril 0.99.10.
At the end of the process, I checked that the “EXPTIME bug” was found on other result.fits as you can see in the logs. The bug was always present.
Screenshot 2021-06-16 at 09.46.16.pdf (6.1 MB)
If you want to check yourself , I uploaded a few files at: http://dl.free.fr/v8waw0evu
I preprocessed these files with the original OSC_Preprocessing.ssf script.
Applying standard script on your images I get:
SIMPLE = T / file does conform to FITS standard
BITPIX = -32 / number of bits per data pixel
NAXIS = 3 / number of data axes
NAXIS1 = 4656 / length of data axis 1
NAXIS2 = 3520 / length of data axis 2
NAXIS3 = 3 / length of data axis 3
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
BZERO = 0. / offset data range to that of unsigned short
BSCALE = 1. / default scaling factor
INSTRUME= 'ZWO CCD ASI1600MC-Cool' / instrument name
TELESCOP= 'Reducer ' / telescope used to acquire this image
OBSERVER= 'JCJ ' / observer name
DATE = '2021-06-16T08:53:58' / UTC date that FITS file was created
DATE-OBS= '2020-05-20T22:03:34.541000' / YYYY-MM-DDThh:mm:ss observation start,
EXPTIME = 50. / Exposure time [s]
EXPSTART= 2458990.41914978 / Exposure start time (standard Julian date)
EXPEND = 2458990.41982632 / Exposure end time (standard Julian date)
XPIXSZ = 3.8 / X pixel size microns
YPIXSZ = 3.8 / Y pixel size microns
XBINNING= 1 / Camera binning mode
YBINNING= 1 / Camera binning mode
FOCALLEN= 1960. / Camera focal length
CCD-TEMP= -15. / CCD temp in C
GAIN = 139 / Camera gain
OFFSET = 21 / Camera offset
CTYPE1 = 'RA---TAN' / Coordinate type for the first axis
CTYPE2 = 'DEC--TAN' / Coordinate type for the second axis
EQUINOX = 2000. / Equatorial equinox
OBJCTRA = '16 41 39.40' / Image center R.A. (hms)
OBJCTDEC= '36 31 43.33' / Image center declination (dms)
PROGRAM = 'Siril v0.99.11' / Software that created this HDU
So, with 5 images, for me the behaviour is ok.
You get the right EXPTIME = 50 sec
I really don’t understand why I get EXPTIME = 10 sec
Here is the result of a new pre-processing with Siril 0.99.10
Screenshot 2021-06-16 at 11.00.38.pdf (655.1 KB)
Are you working on a Mac ? Maybe the bug is only in the macOS version .
I don’t see why there would be a difference between linux (which is UNIX) and macOS in this part.
Please, share the whole result.fits file.
@rbarbera we need your help 
Can you reproduce it with the version you compile on mac?
If yes I will need you output some debug line and I will tell you where.
Hi, sorry for the delay. On first place: the official 0.99.10 (the one that was published last week) is also failing on my machine with my own dataset. Then I’ve checkedout the current main branch and compiled it locally. This version didn’t fails and performs as expected. I’ve stacked 40x240s (9600s total)
I’m adding evidences of this behavior:
Individual frame
Stack with the official version:
Strack with my own build:
Obviously right now, I’ve not changed anything on the source code.
Regards
Wow thanks, that’s a funny one!
Probably a story about lib version …
Well, in fact they are different (at the minor number, but different)
On my computer, I have 2.68.2
brew list glib
/usr/local/Cellar/glib/2.68.2/lib/libgio-2.0.0.dylib
/usr/local/Cellar/glib/2.68.2/lib/libglib-2.0.0.dylib
/usr/local/Cellar/glib/2.68.2/lib/libgmodule-2.0.0.dylib
/usr/local/Cellar/glib/2.68.2/lib/libgobject-2.0.0.dylib
/usr/local/Cellar/glib/2.68.2/lib/libgthread-2.0.0.dylib
Inside the package you are using 2.64.2
Inside the bundle
2,5M 10 jun 10:40 libgio-2.0.0.dylib
1,6M 10 jun 10:40 libglib-2.0.0.dylib
39K 10 jun 10:40 libgmodule-2.0.0.dylib
431K 10 jun 10:40 libgobject-2.0.0.dylib
Looking inside the strings, we can use the symbols reference to know the version
➜ lib strings libgio-2.0.0.dylib | grep 2
....
G_IS_APP_INFO (appinfo2)
../../../../gtk/source/glib-2.64.2/gio/gbufferedinputstream.c
../../../../gtk/source/glib-2.64.2/gio/gbufferedoutputstream.c
../../../../gtk/source/glib-2.64.2/gio/gbytesicon.c
../../../../gtk/source/glib-2.64.2/gio/gcancellable.c
../../../../gtk/source/glib-2.64.2/gio/gcharsetconverter.cI don’t see how a library change would impact the simple task of adding exposure times?
That depends of g_date_time probably. Will investigate I can almost reproduce the AppImage
@vinvin @rbarbera @JCJ : I think I found it.
Not an easy one …
Here: GDateTime: GLib Reference Manual
You can see there is the %f, and I use it. However, looks like this was introduced in the glib 2.66 version. But the documentation says nothing about it.
1 Like
Bug is now probably fixed in master.
Good catch!
Well done effectively !
Issue solved in 0.99.10-1.
Thanks to the team !
3 Likes