Day Time Image Corruption with ASI178MM

[Astro-Pete]

Hi

Anyone else get this issue with corruption and over/under exposure with ZWO cameras during day time capture? I believe we have no control over settings during day and its hard coded for auto exposure @0 gain? I never get this issue at night (I use autoexposure @ 100 gain) Also its not just the displayed image, its on the saved images. I’m running a Pi 4 4GB, camera connected via USB 3 (its not the cable, I’ve tried various ones). No other devices attached other than a GPIO relay board for dew heater control. Only other software running is small python script that grabs weather data every 10 mins and writes out a file for the extratext overlay file. Selecting a different image mode makes no difference either (RAW16, 8,RGB24), its always the same.

I can only assume this is down to either the ZWO Linux drivers or AllSky as I don’t get this issue using another AllSky app on Windows.

[Astro-Pete]

OK, a bit of an update.

This seems to be related at least somewhat to Auto Exposure, although I can't explain why this never happens at night. Image brightness maybe, causing very short exposures?? at night the exposures are generally magnitudes longer even with a moon high up (I have 30 sec set as max exposure).

So, I hacked the capture.cpp file to force day exposures to be a higher gain than 0, this made no difference. even with a gain of 100 (used for my night exposures) I get the same issue.

I then changed the exposure time displayed to be 6 decimal places to see the actual exposure time. This showed that the exposures were jumping about a bit, sometimes going from 0.000032 to 0.3 secs. This would explain the full white out images I see as 0.3 sec is waaaaaay too long for a day capture on a clear blue sky with the sun visible. Usually I see the exposure time bounce from 32us to around 97us, this accounts for the slightly overexposed images I get .

Next I forced the day capture to a fixed exposure of 32us and gain 0, this gives me a pretty good exposure for a clear sun lit sky and most exposures are perfect. I have had 2 corrupted images like the ones in the screen grab above out of dozens taken so far.

One odd thing I noticed is that on my other ASC (a 120mc old usb2 version running on a Pi 3+) when I enabled the extra text overlay the first captured image after saving the settings was also a full white out image. I don't know if this points to any other issue or is juts a weird one off, however disabling extra text overlay on the 178MM system makes no difference to the day time issues.

I know the camera itself (the 178MM) has no issues as it works perfectly using 'AllSkyEye' on Windows with the same cables so this leads me to think the issue is in the Linux drivers for this camera or something else buried in the AllSky code.

I'll keep playing but would it would be good know if others using this camera are seeing similar issues and have any ideas how to address them. I really want to stay with AllSky as running on the Pi platform is my preferred setup.

Cheers and clear skies.

[EricClaeys]

I have the exact same problem with my new ASI178MC - overexposed, and WAY overexposed daytime images (including many images that are pure white, even outside the circle from the lens), and auto-exposure times that jump around a lot for no apparent reason. It definitely appears auto-exposure related, although sometimes I'll get a way overexposed frame with a short exposure, and other times the same short exposure will produce a fine image. I've also tried many of the same things you have (manual exposure during day, adding digits to the exposure time, etc.). I think you had a one-off with enabling overlay with your 120MC - the overlay is added after the picture is taken.

I also get some images with the stripped diagonal lines and assume those are USB-related. I've changed the USB bandwidth higher and lower and it didn't help.

[Astro-Pete]

Hi Eric

Thanks for reporting this, at least I know I’m not going mad! 🤣

I've also tried the USB bandwidth settings and also tried connecting the camera via USB 2 but this still makes no difference. I left the camera capturing at fixed exposure yesterday and watched for the switch to night mode and the gain go to 100 with exposures ramping up quite quickly above the minimum exposure time. Not a single garbled image came in after that up until I brought the camera back as we had rain due and I haven’t weather proofed my setup as yet.

I only mentioned the extra overlay thing as I’ve never seen a white out image on the 120mc before and wondered if the overlay process was causing the image to be completely overwritten somehow rather than it being overexposed, but it was just a long shot. Not seen this since so likely a red herring.

So looking like the ZWO Linux libraries I guess?? How up to date are they? Maybe Thomas can chime in with some ideas.

I don’t use Linux for anything else so no other experience to go by, I’m a Windows user for my main imaging rig with my 533MC-Pro. All my cameras work flawlessly under Windows in all apps.

Now back to hunting down the other little bugs I still have.....public page on web server not working on one ASC while the same file works fine on the other?? The image name is truncated in the inspect window in Chrome so it wont load, if I hack the HTML and force the name it loads!....Weird!! Lol

[Astro-Pete]

Oh, forgot to mention that I also tried binning the camera 2x2 to reduce the large file size to see if this helps with the corrupted images, didn’t help though.

[EricClaeys]

I added the ability to specify auto-USB-bandwidth, auto exposure target brightness, and auto white balance to capture.cpp, but none of those helped. Now, in addition to complete white pages I get completely green or blue pages (probably because of auto white balance). I can't see any pattern to the behavior - the exposure time and brightness jump all over and the exposure reported by the camera doesn't always correspond the the brightness in the image. For example, one image of 0.0012 s will be all white and the next image with the same exposure will look fine. I tried using ASI's tool to control the camera and it works just fine, so it's either something in capture.cpp or in the ASI drivers. I'm on a Raspberry Pi 4b.

THOMAS, has anyone else reported this issue?

[Astro-Pete]

Hi Eric

I also noticed that the reported exposure time does not make sense sometimes. The overexposed images are a lower reported exposure time than the normal ones usually. Is there a ASI tool for Linux or did you use the Windows one? I’ve only used the Windows one to check the camera is functioning as expected and not at fault.

Where’s Thomas? ;)

[EricClaeys]

Astro-Pete, II used ASI Studio's ASICap for Planetary Imaging. When I did it yesterday it connected at USB 2 on my laptop - not sure why, because ASIImg connected at USB 3 when plugged into the same port. Tonight when I tried ASICap, it connected at USB 3 and I never could get the auto white balance to work at night indoors. I was also getting a lot of poorly exposed image.

[Astro-Pete]

Hi Eric

I also use that for focusing the camera in the day. I can’t say I’ve seen the same behaviour so far. The auto exposure is quite sensitive as you can see it changing if you move anything in front of the sensor, blocking some light getting to it. But that only results in very slight changes in image brightness. I’ve not seen any corruption or fully white out images using ASICap or any of the other modes within that suite. Again I’m using Windows for this. We’re you? I see there is a version for Linux. I can’t believe there is a fundamental issue with ZWO cameras on Linux or Mac OS as there would be outrage all over the Web. These cameras are not cheap. If I find time I may install a Linux dist on an old Laptop or dig out my old Mac mini and try on that. Cheers..

[thomasjacquin]

Hi,

I wish I could chime in on this one but I don't have an ASI178. I've heard reports of this issue by at least another person. The ZWO libraries are up to date. Someone reported seeing the issue with one of his ASI178 but not his other ASI178. I don't really have any clues at the moment. Maybe a firmware issue?

Thomas

[EricClaeys]

Astro-Pete, While testing I've started/stopped the allsky service a gazillion times, and sometimes after re-starting it can't find the camera. I have to turn off power to the USB ports or reboot the Pi. Have you ever noticed this?

Also, have you ever tried connecting the camera to a USB 2 port? I plan to, and don't think it'll negatively impact the speed since speed isn't really that important to an all-sky camera. I'm hoping it'll at least fix the occasional semi-corrupted images.

I emailed ZWO support about this problem. Here's what I said:

_Hi, a few of us with ASI178MC and ASI178MM cameras are having issues when auto-exposure is set and gain = 0 while taking pictures during the day. We are using the ASI178 for all-sky cameras with the camera connected to a Raspberry Pi on the USB 3 port. The exposure jumps around - going up and down quite a bit, and many of the shots are extremely over exposed (some to the point that the whole frame is white, even the area outside the area covered by the lens). The author of the program (Thomas Jacquin) has stated that the Linux ZWO drivers are up to date, and has also said he knows someone who has the problem with one of his ASI178's and not his other one. When the exposure time is jumping around, sometimes an exposure at, for example, 0.001 seconds looks ok and another time at 0.001 seconds it's way over exposed, and another time at 0.001 seconds it's underexposed. I've looked at the code that deals with the camera, and it appears to be working correctly.

Is this a known problem?

Is there a new Linux driver and/or firmware release?

Thanks - Eric_

[bbillp]

I am curious, is the 178 in a powered hub ?

Sent from my iPad

On May 4, 2021, at 8:10 PM, EricClaeys @.***> wrote:

 Astro-Pete, While testing I've started/stopped the allsky service a gazillion times, and sometimes after re-starting it can't find the camera. I have to turn off power to the USB ports or reboot the Pi. Have you ever noticed this?

Also, have you ever tried connecting the camera to a USB 2 port? I plan to, and don't think it'll negatively impact the speed since speed isn't really that important to an all-sky camera. I'm hoping it'll at least fix the occasional semi-corrupted images.

I emailed ZWO support about this problem. Here's what I said:

_Hi, a few of us with ASI178MC and ASI178MM cameras are having issues when auto-exposure is set and gain = 0 while taking pictures during the day. We are using the ASI178 for all-sky cameras with the camera connected to a Raspberry Pi on the USB 3 port. The exposure jumps around - going up and down quite a bit, and many of the shots are extremely over exposed (some to the point that the whole frame is white, even the area outside the area covered by the lens). The author of the program (Thomas Jacquin) has stated that the Linux ZWO drivers are up to date, and has also said he knows someone who has the problem with one of his ASI178's and not his other one. When the exposure time is jumping around, sometimes an exposure at, for example, 0.001 seconds looks ok and another time at 0.001 seconds it's way over exposed, and another time at 0.001 seconds it's underexposed. I've looked at the code that deals with the camera, and it appears to be working correctly.

Is this a known problem?

Is there a new Linux driver and/or firmware release?

Thanks - Eric_

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Astro-Pete]

Hi Eric

I’ve not seen the issue you describe with the app not finding the camera, I’ve also stopped\started it many many times in testing and not seen this. I have seen a few times images with a few dark thin lines through the image horizontally at the top of the image, another stop/start fixes this though and once its ok it stays that way.

I’ve also tried USB 2 connection but that is the same as USB 3 unfortunately.

I hope you get a response from ZWO, it’ll be interesting to see what they have to say. I did look for a firmware update for this camera but didn’t find one, only the 120 and a few other older cameras.

@bbillip We are discussing the ZWO178MM and MC cmos cameras. Very nice cameras but seem to have issues with very short exposures when used on a Raspberry Pi which effects daytime image capture.

[horatti]

Hi! I also use 178MC, and this is exactly the phenomenon (underexposure and overexposure) that occurs with daytime images. Otherwise I have no other problems with the system, everything works fine. I have also varied a lot with the settings, the cabling, but nothing helped. :-( Ati

[Astro-Pete]

Hi Ati

Thanks for letting us know. The more people report it the better the chance of getting it fixed I guess. Maybe Eric can point ZWO to this thread so they can see it’s not a one off occurrence, assuming he gets a response 🙏

[horatti]

Yes, that’s exactly what I thought, when I wrote the post!

[EricClaeys]

I am curious, is the 178 in a powered hub ? … Sent from my iPad On May 4, 2021, at 8:10 PM, EricClaeys @.***> wrote:  Astro-Pete, While testing I've started/stopped the allsky service a gazillion times, and sometimes after re-starting it can't find the camera. I have to turn off power to the USB ports or reboot the Pi. Have you ever noticed this? Also, have you ever tried connecting the camera to a USB 2 port? I plan to, and don't think it'll negatively impact the speed since speed isn't really that important to an all-sky camera. I'm hoping it'll at least fix the occasional semi-corrupted images. I emailed ZWO support about this problem. Here's what I said: Hi, a few of us with ASI178MC and ASI178MM cameras are having issues when auto-exposure is set and gain = 0 while taking pictures during the day. We are using the ASI178 for all-sky cameras with the camera connected to a Raspberry Pi on the USB 3 port. The exposure jumps around - going up and down quite a bit, and many of the shots are extremely over exposed (some to the point that the whole frame is white, even the area outside the area covered by the lens). The author of the program (Thomas Jacquin) has stated that the Linux ZWO drivers are up to date, and has also said he knows someone who has the problem with one of his ASI178's and not his other one. When the exposure time is jumping around, sometimes an exposure at, for example, 0.001 seconds looks ok and another time at 0.001 seconds it's way over exposed, and another time at 0.001 seconds it's underexposed. I've looked at the code that deals with the camera, and it appears to be working correctly. Is this a known problem? Is there a new Linux driver and/or firmware release? Thanks - Eric — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[EricClaeys]

Bill, My camera is connected directly to the Raspberry Pi 4b with a 6 inch USB 3 cable.

Ati, Thanks for letting us know you are also seeing the issue. Eric

[horatti]

Hi, My camera is also connected directly to the Raspberry Pi 4b with a 2 m USB 3 cable. Ati

[ac4lt]

I’m in the process of putting an all sky camera together using a pi4 and an Asi178mm i had. I’m seeing exactly the same sort of daytime behavior, occasional corrupted frames, occasional white frames and inconsistent auto exposure.

I was going to get a 178MC to use as I’d like it to be color but now it sounds like I should use a different camera. Are there cameras that are known to work well?

[EricClaeys]

Ac4lt, horatti, Do you also see this behavior using the Windows ASI Studio program that came with the camera? Astro-Pete and I don't (although I once had a way overexposed frame with that program. Eric

[ac4lt]

I tried with Sharpcap and didn’t (though I did see some horizontal lines at every low exposures). It’s dark enough now that it is behaving but I’ll try tomorrow and see.

[EricClaeys]

ZWO's reply: Yuchuan.Mao 2021-05-06 16:40 Hi Eric, We tested it with our ASIAIR Pro which is based on Raspberry Pi4 with same SDK (v1.17), and there is no issue. So you need to check if camera is Ok, try it on PC and if there is issue. If no issue, maybe this has something to do with your upper level software.

---

There is a Linux version of ASI Studio (https://astronomy-imaging-camera.com/software-drivers); it says it's for Ubuntu 16.04 or higher. I'll try it on my Pi.

[horatti]

I have never used ASI Studio, only ASICAP, ScharpCap, and FireCapture. When I bought the camera, I tested it during the day with these programs, and most recently when I built the Allsky camera and focused it with the laptop, but I don't recall having any problems with exposure. Anyway, I used to use it only at night for planetary photography, but now I have another camera for that.

[Astro-Pete]

I guess ZWO have a point there, they do use a Pi 4 as the base of their ASIAir and that is very popular, used by many with ZWO cameras. I’d expect they’d know pretty quickly if there were issues with their SDK. Writing my own capture software as a test is some way outside my skill set but if anyone else has those skills maybe that would be the acid test, a simple single autoexposure with a reasonably large delay between shots test to see if we get the same problem we are seeing with TJ’s software?

As for powered hubs, I’ve not tested with one as I usually steer well clear of such things as they can cause more problems than they address. I’d wager that most ASIAir users wouldn’t use one either as it would be mounted at the scope close to the cameras usually.

[ac4lt]

I installed ASI Studio and ran ASI Cap in auto exposure mode and it worked perfectly. No corrupted frames and no overexposed frames. Exposure was consistent and accurate.

Next I switched to sharp cap in auto exposure mode and it also was well behaved.

Does the ASI Air have the same auto exposure capability? If it doesn't then ZWO may not have made an apples to apples comparison. If it does then it's probably a good indication that this is a software issue with the AllSky application.

[Astro-Pete]

@ac4lt That’s pretty much my findings on Windows. I don’t run Linux on anything else other than more RPi’s. I’m thinking about going back to an Astroberry Image and testing with oaCapture to see if that produces the same issue. At least if it doesn’t we can say its not the Pi or the SDK.

[EricClaeys]

ZWO support said their Ubuntu Linux ASP Studio does NOT work on the Raspberry. They suggested I try the "demo" program, so I asked where it was. I'd like to find the source code for another Linux program that controls the ASI cameras.

Astro-Pete, have you tried setting a fixed daylight exposure but letting the gain be automatic?

[Astro-Pete]

@EricClaeys Ive not tried auto gain at all. I’ve only tried fixed exposure (minimum 32uSecs) at gain 0 and a few other values close to 0 to see if 0 itself was the cause. Any higher values for gain at day just resulted in overexposed images anyway with the f2 lens.

Oacapture is open source so that might be worth a look for testing, I was going to test this myself on an Astroberry image (already installed) but I’m about to travel overseas on business for a few weeks so I won’t get to it for a while.

I was wondering if taking a burst of exposures at very short exposure values would allow the camera to settle and then just display the last correctly exposed image. Most uses of these cameras (for planetary imaging for example) are taking constant exposures and when they first start up you do see the exposures ‘home in’ on the best value over a number of frames. AllSky is just taking a single exposure and hoping the camera is getting right first time I’m guessing?? Thoughts?

[ac4lt]

I tried updating the USB limit from the default of 40 to 100 and that seems to have eliminated the corrupted frames (or at least minimized them to the point where I haven't seen one) but the inconsistent auto exposure remains.

[jcauthen78]

This also seems to have resolved some similar problems (black daytime images, and freezing script) with my ASI120mc (with upgraded firmware) on my 2nd Pi4.

[EricClaeys]

Try the files in this ZIP file to correct the daytime autoexposure. Rename your "capture.cpp" to "capture.cpp-OLD". Rename your "/etc/raspap/camera_options_ZWO.json" to /etc/raspap/camera_options_ZWO.json-OLD". Unzip the file and copy the two files onto your Raspberry Pi. In your "allsky" directory, run "make allsky". Restart the allsky service: sudo service allsky restart

My changes in the capture.cpp file have a comment with "ECC" in them. I made a BUNCH of changes to allow additional functionality (e.g., auto white balance, ability to specify the time format on the overlay, added degrees F, etc. etc.). You'll see those options on the camera settings admin page.

I looked at ZWO's "demo" source code (available in their SDK) and tried to mimic what they were doing, since their daytime auto exposure worked. I then made sure capture.cpp did things in the same order.

Let me know how it goes. Hopefully Thomas will incorporate my changes.

ECCchanges.zip

[EricClaeys]

Hold off. It was working well in the house, but once I put the camera facing outside the daylight exposure problem came back.

Interesting that the exposures in ZWO's demo program didn't change when the camera was in the house, whereas in allsky they changed a little.

Pointing outside, full resolution in 16-bit mono (I have the color camera), ZWO's demo program's exposure don't change, but in color, full-resolution, they do - just like in allsky. So there appears to be a bug in ZWO's drivers. I will let them know.

Eric

[ac4lt]

The inconsistent auto exposure in daylight issue is not unique the the ASI178. It also occurs on the ASI385MC.

[EricClaeys]

Does also only occur when taking color pictures at full resolution? But doesn't occur with mono pictures or less-than-full resolution?

Eric

[ac4lt]

I changed the 385MC to bin2 and switched to png with RAW16 and it made no difference in the behavior. Did that answer the question?

[ac4lt]

As a followup, I modified line 877 of capture.cpp to use a fixed exposure of 1500 microseconds and not to use auto exposure. That is producing a stable exposure, albeit one that may not be accurate throughout the day. At the moment it seems the lesser of the two evils. For anyone who wants to try it, here is the line I used: ASISetControlValue(CamNum, ASI_EXPOSURE, 1500, ASI_FALSE);

Putting this in 877 looks like the spot to subvert the daytime auto exposure behavior.

Stop the service, do a 'make all' and restart the service to see it in action.

[ac4lt]

It appears I spoke too soon. About four minutes before sunset the inaccurate exposure behavior started. It's still in daylight mode. The log shows the exposure value as 1500 microseconds. But the exposures are suddenly overexposed.

[EricClaeys]

All, I gave this URL to ZWO support, so hopefully they will chime in. May I suggest we all describe the issue(s) we're having, to help ZWO support find and fix the issue?

Here's what I see: Things are fine using the Windows ASI Studio program. When using either Thomas' "allsky" program OR ZWO's "demo" program on the Raspberry Pi, when I take color auto exposure images with my ASI178MC at full resolution (3096x2080) during daylight, the exposures vary widely with most frames WAY overexposed, some fine, and some dark. The exposure time reported by the camera usually doesn't relate to the brightness of the picture. For example, a 12 ms exposure may be ok but a 3 ms exposure is way overexposed. Then the next 3 ms shot is fine. This occurs for as long as it's bright outside. At some point it gets dark enough and this behavior stops and auto exposure works as expected. I don't have any data indicating where that bad/good line is. Also, when auto exposure is not working, about 5 % of the images have banding, which looks like a USB issue. I have tried different USB bandwidths and auto bandwidth but it hasn't made any difference. If I take mono (8 or 16 bit) or non-full resolution color images I don't see the auto exposure issue. I don't have any data, but it seems like changing the brightness setting makes things worse.

I have a Raspberry Pi 4b. The 6 inch, 15 cm USB cable goes from the camera directly into one of the USB 3 ports on the Pi.

Eric

[ac4lt]

My symptoms are very similar. The differences are:

1. setting the USB limit to 100 has eliminated (or they happen so infrequently that I haven't caught it) the corrupted frames
2. I haven't been able to replicate the behavior with smaller or mono frames. Other than that I'm seeing the same thing with an ASI178MM and an ASI385MC.

This is n a Raspberry Pi 4B with the camera plugged into a USB 3 port with a 12 inch cable.

[EricClaeys]

ac4lt, You're also seeing this daytime auto exposure issue with a mono camera (ASI178MM)? If you download the ZWO "demo" program and change it to do auto exposure, it's easy to reproduce the issue.

The "demo" program is part of the SDK and can be found on the "Developer" tab here: https://astronomy-imaging-camera.com/software-drivers In the "demo" folder, update line 293 of main_SDK2_video.cpp, changing ASI_FALSE to ASI_TRUE (this tells it to use auto exposure). Then run "make" in that folder". When you run the command, enter "0" (camera number), "0" (customer format), "0 0 1 1" (first 0 is for max width, second 0 is for max height, first 1 is for 1x1 bin, second 1 is for image type of color). You can plan around with the width and height (I believe they need to be a multiple of 1024), and the image type (0 = raw 8 bit mono, 1 = color, 2 = raw 16 bit mono).

Eric

[ac4lt]

Thanks for the pointer! Took a bit of fooling around to get it to build and run but got it going. I ran it against the ASI385MC and it behaves just like the AllSky app does. I'll try in on the ASI178MM later this afternoon but based on this I'd expect it to do the same thing.

[ac4lt]

As expected, the ASI178MM behaves the same way it has been. This is using the 1.18 SDK downloaded today from ZWO's website.

[ac4lt]

I've been playing around with trying to solve two problems. The first is the auto exposure wildness that makes daytime and early twilight exposures all but unusable. The second problem and unrelated to this thread was how hot my sensor was getting. It was getting up to 65C during the hot part of the day.

I'm attaching some code for others to play with. It needs to be cleaned up to be suitable for a pull request and I'll work on that during the week but others might find this useful.

In a nutshell here's what I did:

1. turn off video capture when not actively doing an exposure. This made a 15 degree C difference for me and should help others.
2. Added some code to calculate a histogram out of a 500x500 square in the center of the frame and then compute where the histogram peak is. The is rudimentary. The peak is the lowest bin with the maximum value so multiple peaks or wide peaks really aren't distinguished.
3. If the peak is < 60 multiply the exposure by 1.25 and try again.
4. if the peak < 120 multiply by 1.05 and try again
5. if the peak > 250 divide by 2 and try again
6. if the peak > 132 multiple by 0.95 and try again
7. None of these intermediate exposure are displayed if they peak is not between 120 and 132.
8. It tries up to ten times or it hits a minimum exposure of 50 microseconds or the configuration defined max exposure

This code is a bit of a mess at the moment. It only works for RBG24 and may not work well for cameras other than the ASI385MC. It also subverts the check for auto exposures and always does the auto exposure (but keeping the sdk in manual mode).

This was stable during the day and at night but didn't work perfectly during twilight though it wasn't bad for a first attempt. I'm attaching it here for others to try and comment on. If it seems to work well for people I'll clean it up and generate a pull request for Thomas to review. capture.cpp.zip

[ac4lt]

As a follow up, I'm hoping to bring the camera inside in the next couple of days so I can run a sweep to calibrate the histogram peaks location to changes in exposure length. That should help fine tune the adjustments which are a bit hit and miss at the moment.

[EricClaeys]

I'll check it out. I changed my code to allow non-auto exposure images during the day, in order to attempt to solve the problem.

I solved the issue of the first 3 images not changing, and hence all images being out of sync. It works well. While doing that I added error checking and noticed that ASIGetVideoData() sometimes fails with ASI_ERROR_TIMEOUT, especially when the program first starts. I added some sleep() statements thinking it's a timing issue but am not sure they help. I would be interested to see if others get the errors.

I also added code to time how long an exposure actually takes, and output a message if it's less than what the ASIGetControlValue(CamNum, ASI_EXPOSURE) says the exposure was. Many exposures say they are 60 seconds but take less than a second for ASIGetVideoData() to return, so I can't figure out what's happening. Shouldn't ASIGetVideoData() take at least 60 seconds plus download time to return?

Eric

---

From: ac4lt @.> Sent: Sunday, June 13, 2021 11:57:44 AM To: thomasjacquin/allsky @.> Cc: EricClaeys @.>; Mention @.> Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)

As a follow up, I'm hoping to bring the camera inside in the next couple of days so I can run a sweep to calibrate the histogram peaks location to changes in exposure length. That should help fine tune the adjustments which are a bit hit and miss at the moment.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/thomasjacquin/allsky/issues/363#issuecomment-860241168, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AT2PYK4BDOBKWIPBDDJJLMDTSTPQRANCNFSM43UTXRIQ.

[EricClaeys]

Ac4lt,

I merged your changes into mine and am running it – so far, so good, but I’ll continue testing again tomorrow during the day.

How will it work at night? Should it revert to non-histogram mode at night?

Attached is the merged version. Note that I have a lot of other changes in my version. I put #ifdef’s around your code to make it easy to determine what’s yours and to turn off if needed.

Eric

From: ac4lt @.> Sent: Sunday, June 13, 2021 11:53 AM To: thomasjacquin/allsky @.> Cc: EricClaeys @.>; Mention @.> Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)

I've been playing around with trying to solve two problems. The first is the auto exposure wildness that makes daytime and early twilight exposures all but unusable. The second problem and unrelated to this thread was how hot my sensor was getting. It was getting up to 65C during the hot part of the day.

I'm attaching some code for others to play with. It needs to be cleaned up to be suitable for a pull request and I'll work on that during the week but others might find this useful.

In a nutshell here's what I did:

1. turn off video capture when not actively doing an exposure. This made a 15 degree C difference for me and should help others.
2. Added some code to calculate a histogram out of a 500x500 square in the center of the frame and then compute where the histogram peak is. The is rudimentary. The peak is the lowest bin with the maximum value so multiple peaks or wide peaks really aren't distinguished.
3. If the peak is < 60 multiply the exposure by 1.25 and try again.
4. if the peak < 120 multiply by 1.05 and try again
5. if the peak > 250 divide by 2 and try again
6. if the peak > 132 multiple by 0.95 and try again
7. None of these intermediate exposure are displayed if they peak is not between 120 and 132.
8. It tries up to ten times or it hits a minimum exposure of 50 microseconds or the configuration defined max exposure

This code is a bit of a mess at the moment. It only works for RBG24 and may not work well for cameras other than the ASI385MC. It also subverts the check for auto exposures and always does the auto exposure (but keeping the sdk in manual mode).

This was stable during the day and at night but didn't work perfectly during twilight though it wasn't bad for a first attempt. I'm attaching it here for others to try and comment on. If it seems to work well for people I'll clean it up and generate a pull request for Thomas to review. capture.cpp.zip https://github.com/thomasjacquin/allsky/files/6644313/capture.cpp.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thomasjacquin/allsky/issues/363#issuecomment-860240591 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AT2PYKZAVGYSATO4562POIDTSTO75ANCNFSM43UTXRIQ . https://github.com/notifications/beacon/AT2PYK2AJLXP2KZHBFVOJ5DTSTO75A5CNFSM43UTXRI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGNDDVTY.gif

[ac4lt]

It won’t try to adjust the exposure beyond the value in asiMaxExposure so it should be stable once beyond twilight.

It might struggle a bit at twilight I’ve got some updates that should smooth it out a bit that I’ll send along tomorrow. It’s a bit of a challenge relating the histogram peak to exposure values but I think we can probably fine tune it some.

[EricClaeys]

Here’s an updated merged file. I added #define’s for most of the variables and did some other cleanup.

Your new function to get one exposure seems to have fixed some problems I was seeing, like ASIGetVideoData() occasionally failing.

All calls to takeOneExposure() set useAutoExposure to ASI_FALSE; how will autoexposure work when it’s dark and the histogram method isn’t needed?

Have you ever noticed that the first nighttime exposure (e.g., 60 seconds) can take a couple minutes to return?

Eric

capture.zip

From: ac4lt @.> Sent: Sunday, June 13, 2021 9:45 PM To: thomasjacquin/allsky @.> Cc: EricClaeys @.>; Mention @.> Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)

It won’t try to adjust the exposure beyond the value in asiMaxExposure so it should be stable once beyond twilight.

It might struggle a bit at twilight I’ve got some updates that should smooth it out a bit that I’ll send along tomorrow. It’s a bit of a challenge relating the histogram peak to exposure values but I think we can probably fine tune it some.

— You are receiving this because you were mentioned. Reply to this email directly, https://github.com/thomasjacquin/allsky/issues/363#issuecomment-860328663 view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AT2PYK3C5EI24ODCTUV4KC3TSVUJHANCNFSM43UTXRIQ unsubscribe. https://github.com/notifications/beacon/AT2PYK5EEV7V6AIOCE5IB2LTSVUJHA5CNFSM43UTXRI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGNDZFVY.gif

[EricClaeys]

Has anyone tested the daytime exposure issue on oaCapture? ZWO support asked about that. Eric

[ac4lt]

I'm not familiar with oaCapture.

One thing I've noticed when it isn't very cloudy and the scene has huge dynamic range because the sun is in the frame is that making a change of a few microseconds in exposure can send the histogram from a peak in the 80's to a peak of 255 indicating overexposure. It seems to indicate that either ZWO's microsecond timing is not as precise as the numbers would lead you to indicate (that is the step from say 73 to 74 microseconds actually indicates a larger change in exposure than you would think and conversely the change freom 74 to 75 might be less than you think and perhaps not really a change) or my histogram code is not quite doing what I think.

I really need to bring the camera inside to test that under controlled conditions but in the meantime I've been tweaking the exposure algorithm. I'll try to take the file you sent and include my tweaks and send it back later today.