MantisBT - Issues

0002943: Wrong Moon Rise and Set Times in Ephemeris, and Details

Sun, 09 Aug 2026 04:27:15 +0200

When checking the rise/set times in the Ephemeris Calendar, they are totally wrong when compared to rise/set times from other sources.

For example: https://www.timeanddate.com/moon/canada/toronto

The same error can be found when clicking on the moon, and selecting the object details, at the very bottom:

Rise: Local horizon 03h42m42s Azimuth: [...]
Transit: [...]
Set: Local horizon 14h06m33s Azimuth: [...]

0002942: Indi, CCDCiel handling of Indi driver refusal connect

Thu, 06 Aug 2026 08:49:57 +0200

Noted the following:

Indi, CCDCiel handling of Indi driver refusal connect result in this in the log:

026-08-04T22:18:07.201 9: Sky Simulator: Connecting to INDI server "localhost:7624" for device "Sky Simulator"
2026-08-04T22:18:07.216 2: Connecting Mount INDI "Sky Simulator" …
2026-08-04T22:18:07.278 9: Sky Simulator: INDI server send new device: "Sky Simulator"
2026-08-04T22:18:07.278 9: Sky Simulator: Exec: indi_skysimulator, Version: 1.0, Interface: 1
2026-08-04T22:18:08.622 1: Sky Simulator: Server Disconnected
2026-08-04T22:18:09.279 1: Mount connected
2026-08-04T22:18:10.404 3: Sky Simulator: Mount capabilities:
2026-08-04T22:20:47.476 9: Disconnecting devices

A driver that refuses a connection is legal INDI, and the client should say so rather than dropping the server and claiming success.

0002941: CCDCiel discovery find only one of two Alpaca servers

Wed, 05 Aug 2026 11:30:12 +0200

My Sky simulator has Alpaca server address 127.0.0.1, port 11111. When I use a com device in Ascom 7 is starts a second Alpaca server 127.0.0.1, port 32323. CCDciel sees the only the Ascom7 server. Fix to discover both servers:

cu_alpacamanagement.pas:

Line 354
- if not f_loopback then Result.Add('127.0.0.1');

+ {A unicast datagram to 127.0.0.1 reaches only ONE of the sockets bound to
the discovery port, so a second Alpaca server on the same machine - ASCOM
7 starts one automatically - is silently invisible. The loopback
broadcast address is delivered to every socket bound with SO_REUSEADDR,
so all local servers answer.}
if not f_loopback then begin
Result.Add('127.255.255.255');
Result.Add('127.0.0.1');
end;

Keeping 127.0.0.1 as well costs one extra datagram and covers any server that binds the loopback address explicitly rather than 0.0.0.0; the duplicate check drops the second reply from a server that answers both.

0002940: Minor tweak in cu_tiff.pas

Wed, 29 Jul 2026 14:55:29 +0200

Minor tweak in cu_tiff.pas, remove the thefile.free in lines 370, 522, 661, 808

try
thefile := tfilestream.Create(filen2, fmcreate);
except
thefile.free; // <-- thefile is garbage here
exit;
end;

or use attached version

0002939: Le driver de Bresser ne veut pas s'installer

Sat, 25 Jul 2026 09:48:39 +0200

C'est un problème avec ASCOM j'aimerai savoir si d'autre ont eu le même problème ?

0002927: Camera cooling not fully stopped

Mon, 20 Jul 2026 22:04:47 +0200

Hello,

when selecting camera warmup as termination command of a planned sequence, CCDCiel just sets the target temperature to 20°C. This is in summer not ideal, since the ambient temperature can go higher. This leads to continued cooling at the end of the session (or during daytime, if CCDCiel not terminated until then).

I see the following as possible solutions:
- Set target temperature to really high values (e.g. 60°C)
- Disable cooling instead of increasing target temperature

Thank you

0002935: Fails to import CSV file for sequence

Mon, 20 Jul 2026 22:04:09 +0200

Using Sequence-> new and Import csv to pick the file, entire line appears in one column, even the commas.

0002938: New multi-theaded tiff unit

Mon, 20 Jul 2026 22:02:58 +0200

Attached an update for the unit cu_tiff.pas. It is now multi-threaded and twice as fast.

With reference to the other issue I raised, I have also an multi-threaded rice compression unit for fits.fz files. Works well and compression/decompression time is much smaller then the I/O processing time. Seems to me the way to go if you use compatible software like Sirl or ASTAP for stacking.

cs, Han

0002936: Rice compression in native Pascal code.

Mon, 20 Jul 2026 22:02:36 +0200

Hi Patrick,

I have just finished for my ASTAP program the reading and writing rice compressed files using native Pascal code. This makes the utility program fpack and funpack redundant. The implementation is as follows:

Read 16 bit and floating point fits files. Format rice only. Not gzip;
Write 16 bit fits files.

I skipped writing floating point fits files since rice is an compression for integer files and compression of floating point is always lossy. It is also not relevant for CCDCiel.

Compression for my 16 bit images is identical to fpack to about 40%. Compression is lossless so nothing is lost.

The question would you be interested in adding native rice compression/decompression to CCdCiel? If so I can start working on it.

cs, Han

0002937: Unable to install virtualmoon_9.1_amd64.deb on Ubuntu 26,04

Mon, 20 Jul 2026 21:50:20 +0200

I downloaded the last version but install stop for Package libgtk2.0-0 is not installed.

corrado@corrado-ns2-resolute:~$ inxi -SCGc
System:
Host: corrado-ns2-resolute Kernel: 7.0.0-27-generic arch: x86_64 bits: 64
Desktop: GNOME v: 50.1 Distro: Ubuntu 26.04 LTS (Resolute Raccoon)
CPU:
Info: quad core model: 12th Gen Intel Core i3-12100 bits: 64 type: MT MCP
cache: L2: 5 MiB
Speed (MHz): avg: 799 min/max: 800/5500 cores: 1: 799 2: 799 3: 799 4: 799
5: 799 6: 799 7: 799 8: 799
Graphics:
Device-1: Intel Alder Lake-S GT1 [UHD Graphics 730] driver: i915 v: kernel
Device-2: Logitech QuickCam Pro 9000 driver: snd-usb-audio,uvcvideo
type: USB
Display: wayland server: X.Org v: 24.1.10 with: Xwayland v: 24.1.10
compositor: gnome-shell driver: dri: iris gpu: i915
resolution: 1920x1080~60Hz
API: EGL v: 1.5 drivers: iris,swrast
platforms: gbm,wayland,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 26.0.3-1ubuntu1
renderer: Mesa Intel UHD Graphics 730 (ADL-S GT1)
Info: Tools: api: eglinfo,glxinfo x11: xdriinfo, xdpyinfo, xprop, xrandr
corrado@corrado-ns2-resolute:~$

0002933: Ce n'est pas la bonne étoile qui est amenée sur la fente

Fri, 26 Jun 2026 17:52:32 +0200

Bonjour Patrick,

J'ai réussi à faire des scripts pour automatiser les acquisitions en spectro avec CCD Ciel. Parmi ceux-ci, celui qui permet d'amener la cible à l'endroit voulu sur la fente. Les positions sur la caméra chercheur et sur la caméra de guidage ont été synchronisées au préalable en cliquant puis en ajustant avec les valeurs.
Ca fonctionne le plus souvent, par exemple sur T Crb puis Ups CrB (étoile de référence) mais pour la séquence qui a suivi sur V1331 Cyg, ça n'a pas accroché la bonne étoile.. J'avais pris deux étoiles de référence pour comparer mon traitement, une des deux a été ratée également (Rho Cyg).

Je joins le log qui le montre, mon script dérivé de celui existant dans CCD Ciel (qui ne fonctionnait pas pour moi) et ma séquence. Les parties qui concerne l'arrêt du guuidage, calib et flats fonctionnent.

Mon setup est un newton 150/750, un Alpy 600 et une Player One IMX585, une ASI290M en guidage, une ASI678MC sur lunette 50/205 en chercheur le tout sur ZWO AM5.

Je ne sais pas comment améliorer la détection de la bonne étoile..
Merci d'avance pour votre aide !

0002931: The crosshair is randomly shift of the center in the preview image

Fri, 26 Jun 2026 17:52:09 +0200

CCDCiel version 0.9.94-4104-e6ad9b65

Sometimes the crosshair is wrongly displayed off center and have to be deactivated and reactivated again to be redrawn in the center of the preview image.

0002930: Auto guiding step 2 calibration error

Fri, 26 Jun 2026 17:51:46 +0200

CCDCiel Version: 0.9.94-4104-e6ad9b65

After doing the first step of the CCDCiel autoguider calibration when doing the second step I got several times the following error and then the auto guider was stuck until a CCDCiel relaunch :

telescope/0: Pulse guide error: duration -1293 must be between 1 and 10000 ms.

Telescope/0 is a Benro Polaris mount with Alapca v2.2beta driver (https://github.com/ogecko/alpaca-benro-polaris)

0002929: Type de fichier

Fri, 26 Jun 2026 17:50:50 +0200

Bonjour Patrick,
Serait-il possible d'ajouter un type de capture pour la spectro : Calibration (en plus de Light, Bias, Dark et Flat).
J'ai réussi à automatiser les captures (Alpy 600 + module de calibration/flats + bidouille arduino) mais pour mes fichiers de calibration, le nom donné est celui de la séquence puisqu'il n'y a pas ce type dans la liste, contrairement à Flat dans mon cas mis exemple.
Merci d'avance pour cette évolution.. ou solution de contournement.

Jean-Marc Moreau

0002928: Predefined histrogram settings for full 16 bit cameras

Fri, 26 Jun 2026 17:50:13 +0200

This is a follow-up of the discussion https://groups.io/g/ccdciel/topic/118169275#msg4158

For true 16 bit cameras with unity gain setting the output increase one ADU for each electron. Then in practise most histogram data is typically contained in a few hundred ADU. These cameras require in CCDCiel an presetting "Extreme" to get a good contrast.

This is different then for 12 bit cameras whitch unity gain setting where the output increases with 16 ADU for each electron. For those 12 bit cameras the histogram data is 16 times wider. The more moderate stretching settings are required.

So 12 bit camera there is an inherent gain of 16 build in the data.

Is there a way to adapt the stretching for this true 16 bit cameras to cope with this factor 16?

0002925: Gain and offset settings in sequence and camera tab

Fri, 26 Jun 2026 17:49:51 +0200

With the setup of Gerard I noted the following:

Setup with Windows, ASI1600 camera

1) Yesterday using the camera tab both the gain and offset values where not in the FITS header.

2) Today

1) Gain and offset are recorded in the header if a sequence is run.
2) Gain and offset are NOT recorded if images are made using the camera tab.

After a reset of CCDCiel both gain and offst where recorded. So the problem was fixed by a program reset

3) When I switched between profiles, it is possible that the offset setting is not visible. After a reset it is visible again. See attached screenshots.

4) The offset in CCDciel does not change the background of the ASI1600 image. But the camera driver offset setting does. So it looks like the offset in not transmitted to the ASI1600 driver.

Screenshots of the ASI1600 connected are attached. Note that the offset is missing in the second screenshot.

0002926: Séquence d'acquisition en spectro : démarrage des captures avant que l'étoile soit sur la fente

Fri, 26 Jun 2026 17:49:15 +0200

Bonjour Patrick,
J'ai créé une séquence pour acquérir plusieurs spectres de façons automatique. Le centrage de l'étoile sur la fente se fait bien comme il faut mais les acquisitions ont démarré avant que le centrage soit finalisé. Je ne vois rien dans la séquence (étape prévue/condition) qui permettrait de temporiser ou asservir le début des acquisitions au positionnement correct. J'ai ajouter quelques captures qui seront perdues de fait mais je me dis qu'il doit y avoir une solution plus élégante..

Merci d'avance pour votre aide (encore une fois..)
JM.

0002932: Setting server log file in IndiStarter setup ask permission to access Documents directory

Thu, 18 Jun 2026 14:18:01 +0200

IndiStarter version 0.9.94-4104-e6ad9b65

After setting a directory path for server log file setting and restarting IndiStarter, it keeps asking permission to access Document directory but was stuck after allowing it. After a restart it keeps asking for the permission, again and again until I removed the path in the server log file setting.

0002896: SVBony powerbox switch

Thu, 11 Jun 2026 14:25:28 +0200

I couldn't connect to the SVbony SV241Pro powerbox (https://www.svbony.com/products/sv241-remote-astro-power-controller) using ASCOM. It shows an error: "ASCOM.SVBONY.Switch: Connection error: Method 'Connect' is not supported by automation object"

The ASCOM driver is installed, and I can connect it from Astro Photography Tool (APT). Also, if I use INDI (running on Raspberry Pi), I can connect to it from CCDCiel running on Windows.
But I couldn't change values in the PWM fields in the switch window. They always immediately return to default values. The only option is to set it directly in the INDI server settings.

0002923: La texture ne s'affiche pas avec la version de base 9.0 sous Windows 11 64bits

Mon, 25 May 2026 17:26:48 +0200

Bonjour
J'ai installé la version de base 9.0 sur windows 11 64bits. Après lancement de l'applicatif AtLune, je n'ai à qu'un écran noire dans la partie texture. Quand je déplace la sourie, les coordonnées et altutudes changent comme attendu.
Cordialement
Jacques

0002924: Nom des captures

Sun, 24 May 2026 11:49:56 +0200

Bonjour Patrick,
Je n'arrive pas à faire nommer les fichiers capturés avec CCDCiel sous une forme directement adaptée au traitement avec SpecINTI.
Ils sont sous cette forme : HD237475-300s-1x1-0C-20260521-224938-210-6
J'aimerai qu'ils soient sous celle-ci : HD237475-300s-1x1-0C-20260521-210-6-1, HD237475-300s-1x1-0C-20260521-210-6-2,...., HD237475-300s-1x1-0C-20260521-210-6-11
C'est à dire sans l'heure et avec un incrément automatique -1, -2,... , -11, -12 etc...
Idem pour les flats, darks, offsets et calib.

Merci d'avance pour votre explication !
JM

0002841: Implémentation de Platesolve3

Sun, 17 May 2026 21:27:43 +0200

Bonjour Patrick
Aujourd'hui CCDCIEL intègre, entre autres, comme solveur Platesolve2. Pour NINA, le concepteur a proposé la version améliorée Platesolve3 , en autonome, qui est plus rapide, fonctionne en aveugle et hors ligne, il pourrait être intéressant pour CCDCIEL d'intégrer ce solveur (il reste une place dans l'interface pour un choix :)).
J'ai essayé une intégration à l'arrache en changeant juste le nom de l'exe de platesolve3 en platesolve2 (on ne sait jamais), ça lance bien l'application, mais après ça se bloque ..., les paramètres doivent être différents.
- Page NINA (line de téléchargement en fin de page) :
https://nighttime-imaging.eu/docs/master/site/advanced/platesolving/
- Modalités de commande en PJ.
Cordialement
Jacques

0002921: Consistant progress display of guide/finder camera exposure time

Fri, 08 May 2026 20:12:30 +0200

When looping through exposures from the finder and guider camera, the progress indicator of the camera is not displayed at a consistent location and, depending on the chosen tab, not displayed at all. When for instance doing an AutoFocus the exposure progress is not shown at all. In the tabs where it is shown it is shown at different locations. It would be appreciated if an exposure progress bar could be added next to the exposure progress bar of the main camera. Being able to see this progress is especially useful when working with long exposures (e.g. 30s).

0002922: Add indicator in split guider/finder view to show which image is (or not is) being refreshed

Fri, 08 May 2026 20:12:08 +0200

When using the split finder/guider window two images are shown to the user. Currently it is, however, not possible to tell which one is recent and which one is old. It would be good to make it clear that an image has recently been (or soon will be) refreshed, and/or to indicate which image is old (old being older than the image in the other pane).

A few suggestions:
- a small red dot in a corner or along the edge of the window that is not currently being refreshed and a green one in the other
- greying the window that has the oldest image of the two (i.e. adding a grey layer with transparency)

Nicolàs

0002919: Spectroscopy, ghost stars supression for focusing and solving.

Fri, 08 May 2026 20:11:35 +0200

For bright stars, a reflection on the slit glas results in two ghost stars with a different focus point. This is problematic for focusing and solving.

To fix this there are two options:

1) Focus on the brightest star only. This will not help for solving but in some case solving could cope with ghost stars.
2) Blackout the ghost star above and below using a software routine.

Which option to implement? 1) or 2) or both?

For 2) I have developed a simple brute force procedure which works. I will attach it later.