Appreciated, but unfortunately log files will be of little use for this particular issue. I need to have known sgf files that produce the issue so I can effectively reproduce. Thanks!
Sorry Ken! Here you go… Hope that helps sort the issue
Alright… just a quick update here. I have been looking at the memory management code here for a few days now. Unfotunately is all looks and seems sound. Doesn’t mean that it is, this is just my observation. I have tested with a Canon T1i (more memory consumption) and a KAF-8300 chip. I should probably test with the ASCOM camera sim and use some ridiculously large image.
Anyhow… memory usage is mostly affected by these things:
- Number of targets (~30MB of memory per target)
- Sequence files (like working images from the MFW). Those images usually occupy about 6MB each (not just the image, but all of the Windows controls supporting them in the framework too).
- Image history: Keeps a history of the last 25 images for each filter / binning combo. The last 4 images (not for each combo) are actually held in memory. For a KAF-8300 chip, this will occupy ~128 MB of memory
- The temporary data display (FF, AF, Plate Solve, etc). For a KAF-8300 chip, this occupies about 32 MB of memory
- The main camera display. For a KAF-8300 chip, this will occupy about 32 MD of memory.
For a KAF-8300 with image history turned on, the temp data window open, 4 targets and at least 5 images into the sequence, SGPro should occupy 315-400 MB of memory. This is what I see when I run sequences. When we “release” image memory, Windows do not release immediately, but rather when the OS determines it is need of memory (a process called garbage collection).
Also, it is important to note that each process (SGPro is a process) can allocate about 2GB of RAM before edging toward failure. If the scenario above gets close to this for you, we will need to take more drastic steps to manage memory. I think somebody reported issues around 600MB? That level of memory consumption should not even be close to flagging a memory issue.
KAF-8300 chips produce 16MB images if you want to reverse engineer the math and apply to your camera.
TLDR: I cannot reproduce this issue, I don’t know why it happens to some people and not others. Memory management looks OK. I will keep looking, but I am just hitting one dead end after another.
Ken, If there is a build you can give us that has some verbose logging turned on, I would be happy to run it and provide you with the logs when this situation reoccurs. It might be rather tough to reproduce it since I saw it happen repeatedly one night and completely resolved itself the next night.
This issue does not arise using my Atik490EX (or at least, I cannot recall it happening very often) but it happens regularly with my G4-16000 camera. The G4 images are 4096x4096 and 32MB each as a saved FITs, but each image appears to use 4x that amount RAM when it is downloaded from the camera. I said it happens @ 600MB or over and by that I mean if the memory usage is sitting at 600MB then the chances are the NEXT image will fail to download. I’ve had a lot of practice at this. I do not have image history enabled.
This error will also occur if I set the machine to take a set of Darks or Flats (no other targets in the sequence - just with the camera set up to take 25 Darks OR Flats and not both). No mount or focuser driver is loaded. It happens with 1x1 binning every time when I reach the RAM limit noted above, it also sometimes happens with 2x2 binned images but the memory usage may also peak a little below 600MB in which case I can get all 25 frames without the issue happening at all. More often than not though I get the first failure at around 20 frames (these 2x2 files are ~8MB in size)
A few experiments (using Dark or Flat frame captures) show that, immediately after the image download has failed, I can abort the sequence and attempt to capture another frame, upon abort the memory usage will drop enough that this is sometimes successful - but not always. So a program restart is not always needed. However, when taking real images it’s not worth the risk of losing a 30min sub so I would always restart SGP which offers the lowest memory footprint to start with.
The fact that I see it rarely with the Atik490EX may suggest the Moravian ASCOM driver is perhaps at fault, but I see no such errors when collecting a set of Darks or Flats with SIPS, and the memory usage remains low and stable.
I don’t know why SGP would need to have the last 4 images retained in memory seeing as no processing is done and all SGP is doing is simply capturing raw data (often unattended), so perhaps an option would to disable all this memory-hungry stuff would be a solution?
ChrisH