Day Time Image Corruption with ASI178MM #363
Comments
|
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. |
|
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 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.
|
|
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 |
|
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. |
|
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). THOMAS, |
|
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? ;) |
|
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.. |
|
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. Thomas |
|
Astro-Pete, 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). Is this a known problem? Is there a new Linux driver and/or firmware release? Thanks - Eric_ |
|
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.
|
|
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. |
|
Hi! |
|
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 🙏 |
|
Yes, that’s exactly what I thought, when I wrote the post! |
|
|
Bill, Ati, |
|
Hi, |
|
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? |
|
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. |
|
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. |
|
ZWO's reply: 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. |
|
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. |
|
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. |
|
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. |
|
@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. |
|
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? |
|
@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? |
|
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. |
|
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 Yes, the histogram is only looking at a 500x500 box from the center of the image. I think there are two ways to handle that. One is a larger box but what is suitable might vary from camera to camera and lens to lens so it might need to be configurable. The other would be to set an absolute minimum exposure. The last version I sent had this set to 100 microseconds which seemed to help with that but I'm not sure what the current state of the code is. However, my guests have returned home (first guests in 15 months!) and I have the day off so I can spend some time on looking at this. I did notice that I had to reboot the pi a few times over the weekend. I'm wondering if the live view issue Jim reported might be the cause of that. I'll update my live view also and see what happens. |
|
@EricClaeys I think the logic for live view might need to be tweaked. Using daytime delay makes sense for daytime but at night the exposure time probably makes more sense. My nighttime delay was 10 which would result in a lot of needless refreshing when the image is only changing once every 20 seconds once it settles down. What do you think? |
|
ac4lt,
I'm not in front of the capture.cpp code, but I believe for nighttime pictures the time between exposures is (max_exposure + delay) when auto exposure is enabled, and (specified_exposure + delay) when manual exposures are used. So perhaps liveview should use those times, so every refresh should get a new picture. The only downside is that pictures will on average be old by half the inter-picture time.
The exposure time on the admin page in auto exposure mode is just a starting point so isn't accurate, and liveview doesn't have access to actual auto exposure times.
If the histogram box were to be configurable I assume we'd need 4 numbers: width, height, x offset, y offset? That would be easy to add to the .json file if you let me know the capture.cpp variable names. FYI, the file I posted a couple days ago is the lastest.
I got my first professional haircut last week in over a year. What a joy.
If you don't mind me asking, is there something you'd rather be called than ac4lt?
Eric
…________________________________
From: ac4lt ***@***.***>
Sent: Monday, June 21, 2021 9:59:36 AM
To: thomasjacquin/allsky ***@***.***>
Cc: EricClaeys ***@***.***>; Mention ***@***.***>
Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)
@EricClaeys<https://github.com/EricClaeys> I think the logic for live view might need to be tweaked. Using daytime delay makes sense for daytime but at night the exposure time probably makes more sense. My nighttime delay was 10 which would result in a lot of needless refreshing when the image is only changing once every 20 seconds once it settles down.
What do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#363 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2PYK6KLD3YM6OPSAK3YJTTT5HVRANCNFSM43UTXRIQ>.
|
|
@EricClaeys AC4LT is my amateur radio callsign. I'm Linda...pleased to meet you and the others here. I brought my camera inside today to line the interior box with reflectix to try to keep some heat out of the box. While I have it inside I'm running a sequence of exposures to see how linear the histogram response is to aid in the autoexposure algorithm. Perhaps half that exposure + delay value or even a quarter would be fine. Should still be fairly responsive and not constantly refreshing. Something one of us has done recently is making things act quite strange. My browser starts becoming unresponsive and sometimes the pi seems to crash or at least become unresponsive. I'm curious if anyone else is experiencing this. Right now the compute histogram function has the +/- 250 hardcoded into it from the center, but we cold add a parameter (or two if we wanted to separate the horizontal from vertical value) that got passed into that function for controlling the area sampled for the histogram. I'd suggest staying away from the edges of the actual fisheye view as vignetting will tend to bring down the histogram average making the middle bright if used. I'll be digging into this some for a while...my loop to write out the exposure values will take a while...should have commented out the debug statements...that's slowing it down a fair amount, but when it finishes I'll have a table from which we can see how linear the response is. |
|
Reflectix?! dangit!! now i need to save up a few more bucks haha I haven't had my Pi4/8gb crash or hang since putting in y'alls changes (i've got a script that says 'if file older than 120s, reboot', and a @reboot 'i just rebooted' email), as far as I can see its stable on this end. I have noticed twice that I've had to hard boot (remove power) to reset the USB/camera, but other than that, its pretty stable. I'm temped to install the code on my 2nd AllSky today (same version Pi & 178MC) to see if it stays happy too (after i do a hot-clone of the card). |
|
Linda, glad to meet you and thanks for the work you're doing.
Please make sure you update liveview.php with the version I posted last night after Jim mentioned the high CPU usage. I have not rebooted my Pi sine I installed the camera in my observatory a couple weeks ago.
I will look at the refresh time.
Jim,
Did you have to reset USB power before Linda and my changes? I have restarted the software a gazillion times and sometimes allsky.sh can't find the camera although the USB connection is there, and other times the USB connection isn't even there. I modified allsky.sh to do a USB reset which fixes the problem. No need to reboot the Pi. That and the change to exit the capture program if there are two image-related errors in a row have resolved the problem, although it sometimes takes a few tries.
Normal users that aren't constantly restarting the software likely won't have these issues.
I'll post my allsky.sh.
Eric
…________________________________
From: Jim ***@***.***>
Sent: Monday, June 21, 2021 12:44:35 PM
To: thomasjacquin/allsky ***@***.***>
Cc: EricClaeys ***@***.***>; Mention ***@***.***>
Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)
Reflectix?! dangit!! now i need to save up a few more bucks haha
I haven't had my Pi4/8gb crash or hang since putting in y'alls changes (i've got a script that says 'if file older than 120s, reboot', and a @reboot<https://github.com/reboot> 'i just rebooted' email), as far as I can see its stable on this end. I have noticed twice that I've had to hard boot (remove power) to reset the USB/camera, but other than that, its pretty stable. I'm temped to install the code on my 2nd AllSky today (same version Pi & 178MC) to see if it stays happy too (after i do a hot-clone of the card).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#363 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2PYKZM6EJ6DBG3KWDBEPTTT53AHANCNFSM43UTXRIQ>.
|
|
Eric, I do have the new version. I also put a remote controllable power switch in the box that contains the camera so I can reboot it remotely if it does crash because, well, mostly laziness. :) If live view change was causing high CPU usage it's certainly possible my Pi overheated. Once it goes back outside in an hour or two I'll have a better handle on that. Might be nice for capture to display the CPU temp in its info display so that if it did crash from heat I'd have some idea of where the temperature was when it died. Not on the critical path though. My all sky camera box is somewhat large as I needed to put a power strip and trade lrouterinside so I could also power and put a sky quality meter attached to the same mast online. I'll post some pictures in a bit. But, I suspect because of that, I was more subject to heat issues than others. |
|
I did a reboot after re-making the capture.cpp the first time, so that throws off the data a little bit, prior to that It'd been up and running for 17 days. But what I noticed was it was trying to connect to the camera and just sit there... everything else ran normal, just no camera activity, a soft (sudo reboot) didn't bring it back, after that a shutdown & hard power woke it back up - i stuck a wifi-connected plug inside the camera box, so its easy to hard-boot with my phone. Is there a way to check USB functionality while the box is still up on my roof to do some testing if/when it happens again? For note, I'm using a smaller Pelican case (hand-gun size) with 120v coming in, going through a wifi power controller, into an Anker USB hub.. creates some heat from the conversion loss, but the current/amperage is reliably solid, so I don't think the USB drop is caused by a low voltage/amp drop. |
|
Here's a new capture.cpp with what I think is a more robust auto exposure algorithm. It's overcast and rainy here this afternoon so I'm not sure how this will behave in sunny weather and it hasn't been through twilight yet but I think the latter should behave substantially as before. Let me know if it isn't. I updated the printf's in the autoexposure loop to use Thomas's debug function so set debug level to 1 to see all the auto exposure info. It should hunt less and hopefully at least end up fairly close. Because of this the first time through it may not quite get where it needs to go but should settle down within an attempt or two. I am seeing navigation away from the live view page be very sluggish while navigation away from other pages is snappy as it was before. I'm using Eric's latest liveview.php and his earlier changes. |
|
@ac4lt - in full sunlight it seems to be workig ok. with the debug @ 1 it's showing about 3 exposures till it finds one it likes. will let it keep running and see what the results look like in a little while. While i'm waiting, I'm gonna get my 2nd Allsky files swapped up and see how it likes it. |
|
Jim, thanks for the feedback! Can you tell me what your CPU temperature is? My reflection idea may be backfiring and keeping more generated heat in i more than keeping external heat out. |
|
More than welcome Linda. Still working on the 2nd Allsky, fixing the live-view flicker. here in Boise, ID it's currently 97f outside, and my CPU temp is hovering at 75-76c (167f). |
|
@EricClaeys - been playing with the newest liveview.php - its still giving me fits and doing the constant refresh. I went back to the previous, before you added the 'sunwait', and its more stable. @ac4lt - I got the 2nd Allsky up and running with your updated capture.cpp, feels stable, although images a little darker than before your update (on both cameras). I'm sticking the current modified files into a zip on my website to avoid confusion for others, in case I made a mistake with the timestamps. You two have done some great leg-work!! Here's a list of the files in the zip that seem 'stable' at the moment, and the post time stamps (in MST).
also, if anyone is curious of the images they're both snapping right now for comparison against yours - |
|
Found a problem at/near line 1651. the expression "actualExposureMicroseconds - (asiNightMaxExposure * US_IN_MS)" should be reversed to "(asiNightMaxExposure * US_IN_MS) - actualExposureMicroseconds" or you end up with a negative value to usleep. I also added in at 1471 the line: Will send a new capture.cpp tomorrow morning assuming all goes well tonight. |
|
@EricClaeys that new live view.php does seem to burn a lot more CPU cycles than the original. Reverting to the old one definitely brings the CPU load down. Haven't really investigated what is going on in there but wanted to let you know. |
|
Jim, Linda, Attached also is my allsky.sh file with the change to reset the USB 3.0 bus if the camera isn't found. I haven't figured out why the camera sometimes disappears, but this file works around it nicely. Linda, not surprised you found a bug in the sleep code. I had a feeling there was something wrong but never looked. Will you please fix it in the file you send tomorrow? Thanks. Jim, in your shot with the house in it, you can see a reflection from either the lens or the camera in the center of the picture. I had to paint the top of my camera black to get rid of the reflection. May I suggest the three of us take our posts off-line, to avoid cluttering up this thread? If you agree, you can email me at AstroEric at eccssw.com. |
|
Sounds like a good idea to continue in email. I'll send an email out this morning. In the meantime I'll update to your latest versions and here is the capture.cpp with the changes I mentioned earlier. Seems like we are pretty close to having something that works well. Hopefully we can get the last kinks worked out and send a pull request to Thomas. |
|
Hi there! I was curious if this "branch" was still being worked on. I have a 178mm and 178mc and the changes you have made are quite fantastic! |
|
pengsloth, Eric |
|
Absolutely! It happens that the 178mm is the one I can actually experiment with. |
|
pengsloth, |
|
I installed Jim's previous "stable" collection (21.06) for my 178MC camera. |
|
Ati, |
|
Thanks Eric! Ati |
|
Night Time Operation I never ever update the PI OS as it causes too many other problems so my OS is 2-3 years old. |
|
Bill,
Did you install the camera settings ZWO.json file along with the new capture.cpp? Many of the settins names changed
…________________________________
From: Bill P. ***@***.***>
Sent: Saturday, July 10, 2021 1:24:03 PM
To: thomasjacquin/allsky ***@***.***>
Cc: EricClaeys ***@***.***>; Mention ***@***.***>
Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)
The problem is in the newer ALLSKY because I have not updated in two years (until last night 7/9/2021) and the ZWO ASI178MC works perfect on an old Pi3b , never an issue but after updating last night 7/9/2021 the very same hardware creates mostly dark images, maybe the software is ignoring the gain which at first load is set to 50 but I run at 175 to 195. It seems the new software is ignoring the GAIN setting. I will restore the old ALLSKY, my reason to upgrade was only for the DARKS implementation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#363 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2PYKYIIM3P6PZIOOISWZDTXCF4HANCNFSM43UTXRIQ>.
|
|
Oops, hit "send" too soon.
You need both files for the settings to work, otherwise you get the defaults. You can tell by looking in the logs at the top where the settings are displayed.
Eric
…________________________________
From: ***@***.*** ***@***.***>
Sent: Saturday, July 10, 2021 3:31:53 PM
To: thomasjacquin/allsky ***@***.***>; thomasjacquin/allsky ***@***.***>
Cc: Mention ***@***.***>
Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)
Bill,
Did you install the camera settings ZWO.json file along with the new capture.cpp? Many of the settins names changed
________________________________
From: Bill P. ***@***.***>
Sent: Saturday, July 10, 2021 1:24:03 PM
To: thomasjacquin/allsky ***@***.***>
Cc: EricClaeys ***@***.***>; Mention ***@***.***>
Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)
The problem is in the newer ALLSKY because I have not updated in two years (until last night 7/9/2021) and the ZWO ASI178MC works perfect on an old Pi3b , never an issue but after updating last night 7/9/2021 the very same hardware creates mostly dark images, maybe the software is ignoring the gain which at first load is set to 50 but I run at 175 to 195. It seems the new software is ignoring the GAIN setting. I will restore the old ALLSKY, my reason to upgrade was only for the DARKS implementation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#363 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2PYKYIIM3P6PZIOOISWZDTXCF4HANCNFSM43UTXRIQ>.
|
|
Yes of course everything that install installs in a new directory.
…Sent from my iPhone
On Jul 10, 2021, at 13:35, EricClaeys ***@***.***> wrote:
Oops, hit "send" too soon.
You need both files for the settings to work, otherwise you get the defaults. You can tell by looking in the logs at the top where the settings are displayed.
Eric
________________________________
From: ***@***.*** ***@***.***>
Sent: Saturday, July 10, 2021 3:31:53 PM
To: thomasjacquin/allsky ***@***.***>; thomasjacquin/allsky ***@***.***>
Cc: Mention ***@***.***>
Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)
Bill,
Did you install the camera settings ZWO.json file along with the new capture.cpp? Many of the settins names changed
________________________________
From: Bill P. ***@***.***>
Sent: Saturday, July 10, 2021 1:24:03 PM
To: thomasjacquin/allsky ***@***.***>
Cc: EricClaeys ***@***.***>; Mention ***@***.***>
Subject: Re: [thomasjacquin/allsky] Day Time Image Corruption with ASI178MM (#363)
The problem is in the newer ALLSKY because I have not updated in two years (until last night 7/9/2021) and the ZWO ASI178MC works perfect on an old Pi3b , never an issue but after updating last night 7/9/2021 the very same hardware creates mostly dark images, maybe the software is ignoring the gain which at first load is set to 50 but I run at 175 to 195. It seems the new software is ignoring the GAIN setting. I will restore the old ALLSKY, my reason to upgrade was only for the DARKS implementation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#363 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2PYKYIIM3P6PZIOOISWZDTXCF4HANCNFSM43UTXRIQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Version 0.8 addresses this issue, and lets users choose between the old 0.7 exposure method and the newer more efficient 0.8 method. |
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.
The text was updated successfully, but these errors were encountered: