This costs me a third to half of all my images..
Thanks in advance..
Derek
- Image_Problem.png (575.91 KiB) Viewed 1916 times
ASI178MM Image problem??
ASI178MM Image problem??
I was wondering if anyone has seen anything similar and knows what the cause is.. ??
This costs me a third to half of all my images..
Thanks in advance..
Derek
This costs me a third to half of all my images..
Thanks in advance..
Derek
-
admin
- Site Admin
- Posts: 13287
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: ASI178MM Image problem??
Hi,
There have been some reports of image corruption issues with the January update from QHY on certain cameras if the USB traffic is set to low values - QHY described the problem as
"some cameras (qhy174, qhy5iii174, qhy5iii290, etc.) will have image dislocation when usbtraffic is small in 16 bit live mode"
They have just (yesterday) released an update that hopefully fixes the problem (if that is the problem that you are experiencing). I expect to have that in the new version of SharpCap within the next week.
Cheers, Robin
There have been some reports of image corruption issues with the January update from QHY on certain cameras if the USB traffic is set to low values - QHY described the problem as
"some cameras (qhy174, qhy5iii174, qhy5iii290, etc.) will have image dislocation when usbtraffic is small in 16 bit live mode"
They have just (yesterday) released an update that hopefully fixes the problem (if that is the problem that you are experiencing). I expect to have that in the new version of SharpCap within the next week.
Cheers, Robin
Re: ASI178MM Image problem??
Hello Robin..
First off.. ASI178MM.. ZWO question in the ZWO Forum..
Sorry.. I couldn't resist..
But I have narrowed down the issue to a problem with the 32 bit SharpCap, as in indoor testing with 5 second images, and switching back and forth between 32 bit and 64 bit SharpCap, I had zero bad frames in a couple hundred samples w/ the 64 bit version.. roughly 50% of the images were bad in the 32 bit version.. Something is wrong with the 32 bit version..
SharpCap 3.2 version 3.2.6194.0 - 1/3/2020.. Verified it says the same for both 32 and 64 bit.. I don't mind using the 64 bit version, but I thought I read somewhere that the 32 bit version was preferred.. I also have never seen this issue with the One Shot Color version.. I have (also) always used the native driver..
I will make another post that explains how I found it..
Derek
First off.. ASI178MM.. ZWO question in the ZWO Forum..
Sorry.. I couldn't resist..
But I have narrowed down the issue to a problem with the 32 bit SharpCap, as in indoor testing with 5 second images, and switching back and forth between 32 bit and 64 bit SharpCap, I had zero bad frames in a couple hundred samples w/ the 64 bit version.. roughly 50% of the images were bad in the 32 bit version.. Something is wrong with the 32 bit version..
SharpCap 3.2 version 3.2.6194.0 - 1/3/2020.. Verified it says the same for both 32 and 64 bit.. I don't mind using the 64 bit version, but I thought I read somewhere that the 32 bit version was preferred.. I also have never seen this issue with the One Shot Color version.. I have (also) always used the native driver..
I will make another post that explains how I found it..
Derek
Re: ASI178MM Image problem??
Here is a copied email to my buddy's trying to diagnose this issue..
***
I was outside for about ten minutes and quickly saw my simple ideas were having no effect, so I packed it in and tested indors for the last hour.. And I have problem comprehending how this could USB OR computer related, as I have never had any problem saving the same size frames at high frames per second.. How can it work fine at well over 30 frames per second, but fail with 1 image every 2 minutes?? The 16bit 1600x1200 FITS images are only about 3 MB each..
*Almost* nothing I do makes any difference whatsoever.. To wit it doesn’t make a Hills bit of difference if I..
Use a different cable.. (I have 5 of them)..
Use the powered hub..
Have mount control via Ethernet, Guide on one USB 2 connection, and image on the other, or if I have JUST the imaging camera attached..
8 bit or 16bit.. No difference..
Use a different file format.. SER, PNG, FITS.. All the same..
Change any setting in Sharpcap.. GAIN, USB Traffic, Banding suppression, makes zero difference..
While I haven’t tried EXACTLY (as in I haven’t entered an exact number), but using the slider to set exposure has yielded (pretty much) that the problem occurs at 2 seconds.. i.e. an exposure of 1955ms has no problem, but at an exposure of 2011ms, the problem appears..
***
HERE IS WHERE I Figured it out..
***
Tried FireCapture.. Apparently I hated that so much I uninstalled it some time ago.. Oh well.. That leaves me the ability to try “just” the SharpCap 64bit version, as there is supposedly some reason we were supposed to be using the 32bit version..
So.. 200 5 second frames w/ the 64bit version yields apparently “perfect” frames everytime.. Opened up the 32bit version and almost all 10 5 second frames were bad.. Back to the 64 bit and a dozen good frames / no bad frames.. back to 32 bit, and half the frames are bad..
Granted these are quick tests indoors with dark frames that leak light where I manually select the filter, but it does yield a peak in the middle of the histogram.. There seems to be a problem – for me at least – with the 32 bit SharpCap that doesn’t exist with the 64 bit version..
***
I HAVE done this half a dozen times since, and the results are always the same..
Thanks for reading..
Derek
***
I was outside for about ten minutes and quickly saw my simple ideas were having no effect, so I packed it in and tested indors for the last hour.. And I have problem comprehending how this could USB OR computer related, as I have never had any problem saving the same size frames at high frames per second.. How can it work fine at well over 30 frames per second, but fail with 1 image every 2 minutes?? The 16bit 1600x1200 FITS images are only about 3 MB each..
*Almost* nothing I do makes any difference whatsoever.. To wit it doesn’t make a Hills bit of difference if I..
Use a different cable.. (I have 5 of them)..
Use the powered hub..
Have mount control via Ethernet, Guide on one USB 2 connection, and image on the other, or if I have JUST the imaging camera attached..
8 bit or 16bit.. No difference..
Use a different file format.. SER, PNG, FITS.. All the same..
Change any setting in Sharpcap.. GAIN, USB Traffic, Banding suppression, makes zero difference..
While I haven’t tried EXACTLY (as in I haven’t entered an exact number), but using the slider to set exposure has yielded (pretty much) that the problem occurs at 2 seconds.. i.e. an exposure of 1955ms has no problem, but at an exposure of 2011ms, the problem appears..
***
HERE IS WHERE I Figured it out..
***
Tried FireCapture.. Apparently I hated that so much I uninstalled it some time ago.. Oh well.. That leaves me the ability to try “just” the SharpCap 64bit version, as there is supposedly some reason we were supposed to be using the 32bit version..
So.. 200 5 second frames w/ the 64bit version yields apparently “perfect” frames everytime.. Opened up the 32bit version and almost all 10 5 second frames were bad.. Back to the 64 bit and a dozen good frames / no bad frames.. back to 32 bit, and half the frames are bad..
Granted these are quick tests indoors with dark frames that leak light where I manually select the filter, but it does yield a peak in the middle of the histogram.. There seems to be a problem – for me at least – with the 32 bit SharpCap that doesn’t exist with the 64 bit version..
***
I HAVE done this half a dozen times since, and the results are always the same..
Thanks for reading..
Derek
-
admin
- Site Admin
- Posts: 13287
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: ASI178MM Image problem??
Hi,
Sorry for going off on the wrong track regarding Qhy cameras rather than ZWO ones. It's a habit I'm afraid – I'm always trying to chase down issues with QHY cameras and hardly ever have to deal with a problem from a ZWO cameras!
It sounds like you already have a workaround sorted out in using the 64-bit version of SharpCap with your camera. There's no real problem in doing that – the real reason that I suggest preferring the 32-bit version is that some camera brands are not supported in the 64-bit version, so if people started downloading the 64-bit version by default there would be lots of cases where people find that their camera doesn't work.
Cheers, Robin
Sorry for going off on the wrong track regarding Qhy cameras rather than ZWO ones. It's a habit I'm afraid – I'm always trying to chase down issues with QHY cameras and hardly ever have to deal with a problem from a ZWO cameras!
It sounds like you already have a workaround sorted out in using the 64-bit version of SharpCap with your camera. There's no real problem in doing that – the real reason that I suggest preferring the 32-bit version is that some camera brands are not supported in the 64-bit version, so if people started downloading the 64-bit version by default there would be lots of cases where people find that their camera doesn't work.
Cheers, Robin
Re: ASI178MM Image problem??
Very Good..
Yes, I bought the QHY178MM-Cool for Christmas, but it *would not work*.. Period.. So I "had" to trade it back for the camera I should have bought originally, this ASI178MM..
I was *seriously* bummed when I thought I had another defective camera and was equally ecstatic when I found a work around.. Now I have to redo the sensor analysis since it had some of these bad frames in it and said the chip was linear to 41%..
Anyho.. Thanks for reading..
Derek
Yes, I bought the QHY178MM-Cool for Christmas, but it *would not work*.. Period.. So I "had" to trade it back for the camera I should have bought originally, this ASI178MM..
I was *seriously* bummed when I thought I had another defective camera and was equally ecstatic when I found a work around.. Now I have to redo the sensor analysis since it had some of these bad frames in it and said the chip was linear to 41%..
Anyho.. Thanks for reading..
Derek