Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - pmwolsley

Pages: [1] 2 3 ... 6
Please accept my apology for taking so long to reply. Having too much fun using my QHY294C (I do not own a QHY294C Pro).

I got a chance last night to use the driver you provided.  The camera performed well.  I think giving the user some control over the start-up condition for the cooler is a great idea but I think it needs a little more work.

Last night the air temperature was 25C when I powered up the camera.  Because the cooler setpoiint was 15C it still turned the cooler on at full power which is the main complaint here.  I have written my own program which uses the qhyccd.dll to control the camera.  I also implemented a cooler control algorithm which immediately sets the cooler mode to manual with a PWM reference of 0 when it first runs.  The cooler still spikes to 100% but my program brings to cooler power back to zero within a few seconds.

My suggestion would be to give the user a choice of OFF or ON for the initial state for the cooler.  OFF would mean that the CONTROL_MANUPWM parameter would be set to 0. ON would mean that the cooler is in AUTO with a temperature reference of 0.  Any 3rd party program that can control the cooler should be able to control the cooler and slowly ramp the temperature as needed.


I own a QHY294C and it's cooler behaves the same as Sergio's. It turns on at full power to drive the temperature down to zero Celsius as quickly as possible. Please look into having this modification available to all QHY cameras equipped with coolers.  I can expect that some users would like to keep things as they are so you may need to offer some method of allowing the user to choose.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: April 07, 2021, 02:51:58 PM »
Looks good. QHY SDK and driver are working well.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: April 05, 2021, 03:03:56 PM »

Lots to reply to...

Very nice astropic.

-My stock QHY294C camera has a heater element for the camera objective glass. I have not seen any fogging. I don't think you need the heater band as shown in your picture. I have to believe that the factory QHY294CPRO also has an objective glass heater.

-Offset=29 I use an OFFSET of zero for all GAINs. I would like it if QHY allowed OFFSET to be negative. Using a positive value is OK but it takes away from dynamic range. You need to look at BIAS frames with different values for OFFSET and decide what is the smallest value to use with minimal clipping at zero. That's how I decided on an OFFSET of zero. Dark Current and Light Pollution will push up the average pixel values so clipping at zero is not a concern for me.  I have a very dark site that I image at and I always use an OFFSET of zero.

Take a look at my photos www.astrohobby.ca

GAIN=1601  This is fine. The camera actually switches to HGC mode at GAIN=1600...I've proven this. Once you get comfortable with the camera you can experiment with other gains[advanced topic].

-I don't know where you live but if the weather is cold then the cooler will be barely working. The power supply will be cold. Don't expect the same if you use the camera inside your house. At -15C it will be working hard.
More on this later...

-DARKs at the same temperature/GAIN/OFFSET/EXPOSURE as your LIGHT frames are vital for the QHY294 cameras.  Dark current is significant with this camera.

-I struggle with FLATs also. Can you put a sample FLAT on dropbox and also let me know how you took the FLAT? If you take FLATs and DARKFLATs using the same conditions then it does not matter at what GAIN or COOLING you used.

I have a B4 light panel that I just started using. To soon to tell if it is better. My light panel seems to be pure white. The histograms look like white light with no strong blue hue.

-Panda Eyes...that's the first time I heard that description. Can you get me a link to a website that has good information on panda eyes?

As for your sensor analysis images. The first one is rubbish. That must have been when the SDK and driver were messed up.

The second one is not much better. It does show the read noise dropping as the camera switched from LGC to HGC. The e/ADU, Read Noise(e), Full Well(e), Relative Gain, Rel Gain(db) values are rubbish. Only the Gain Value and the Dynamic Range (Stops) values are useful.

Also...The cooler target was set to -15 and the temp feedback was -13.6.  The cooler was operating at 100%!!! You must avoid running the cooler continuously at 100% power. It significantly decreases the operating life of the cooler. This is important to remember when you are taking DARKs inside the house. Try to put the camera in a cool environment if your are going to be taking -15C DARKs...otherwise you will shorten the life of the cooler and the camera temperature may not be constant because the cooler is running hard. You want constant temperatures for all of your imaging...including DARKs.

P.S. If you want to discuss FLATs for the QHY294C can you start another topic in a section not specific to SDK and driver issues.  A lot of what it already here is not easy for anyone else to find.

Image Issue Q&A / Re: QHY294C Grid pattern on the image
« on: March 29, 2021, 04:10:57 PM »
    We modified a new version SDK,it support color mode in 47 MP read mode.You need use this 32 bits SDK replace old one, and select RGB24 in SharpCap,don't select RAW8 and RAW16.
Best Regards,
My understanding of this 32b SDK is that when the QHY294CPRO camera is configured for 47M mode there will now be a working version of the RGB24 image format.  This means that the camera driver will debayer the 47M RAW image into a 47M RGB image where the red, green and blue values are 8 bit [0-255].  When you say "don't select RAW8 and RAW16" is this because they have not been modified to support a RAW color image?

It's a good first step. Suitable for planetary video work?


Image Issue Q&A / QHY294CPRO grey image
« on: March 28, 2021, 09:12:45 AM »
I know that the 47M mode for the QHY294CPRO has two interesting features.  The first being a 47M color image. The second being a High Dynamic Range 11M image.  QHY offers the QHY294CPRO because there is a camera modification required to unlock the 47M mode.  I have to send my camera back to have it modified...your camera is already modified. I don't know how much it's going to cost to have my camera modified. I am waiting until QHY comes out with updates to enable either the 47M color or the 11M HDR image capability.

In the meantime, there is little use for the 47M mode for the QHY294CPRO right now.  The QHY294MPRO can use the 47M mode to full advantage right now. This situation is a marketing strategy that QHY believes is appropriate.


P.S. If you are interested...I have been involved with another topic on this forum that deals with this same issue.  Here is a link to it.

Image Issue Q&A / Re: QHY294C Grid pattern on the image
« on: March 27, 2021, 10:00:59 AM »
Because you mentioned 47M mode I assume you have a QHY294CPRO camera.  The original version of this camera, which I own, is called a QHY294C and it is not capable of 47M mode unless I send the camera back to have the camera modified.

The image you provided looks like a monochrome (greyscale) image. There is a QHY294MPRO which is a greyscale camera but I believe yours is the color version because of the checkboard pattern you are seeing.  The checkerboard pattern tells me that your software is not debayering the image from your camera.  You should check that your software(APT/Sharpcap/Ezycap) is debayering the image.  Please understand that, right now, there are no programs available that can debayer a 47M image from your camera.  QHY is working on this.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: March 23, 2021, 09:19:45 AM »
You are certainly learning lots about digital cameras.  A few concepts to understand.
1)The Whitebalance values should be set to the default (16) for all of your work.  [The only exception is when you are displaying a live video and you wish to have the colors "look nice". For this exception you will want to have the red whitebalance set to 32, the green whitebalance set to 16 and the blue whitebalance set to 24.]
2)All of the programs you are going to use to digitally develop your astrophotos will prefer that the whitebalance values be equal. This is both for the pixel values and for the noise content in the image [advanced topic for later]
3)This equal whitebalance philosophy is built into virtually all cameras and it can be a real "can of worms" if you mess with it.

The end result of all of this is that the red pixel values are virtually always less than the green pixels. It's not uncommon to see that the red pixel values are 1/2 the value of the green pixels...this is normal and all of your software understands this situation.  Your blue pixels values will be less than your green pixels and typically larger than your red pixels...this is also normal and all of your software understands this situation.

Your histograms display exactly what I just described which means everything is working just fine.  The red histogram is significantly less than the green histogram.  The blue histogram is larger than the red histogram but less than the green histogram.

These histogram relationships are typical when you are imaging a white object like the moon.  If the object is reddish then the green and blue histograms which shift to the left and may be less than the red histogram.  When the object has color then the histogram shift around so you are lucky that you did this test using the moon.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: March 15, 2021, 08:33:38 AM »

Here is what the histogram looks like with my custom bayer algorithm.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: March 14, 2021, 12:27:00 PM »

I invented a very simple custom bayer scheme for the 47M images.  It certainly is not perfect but it might be a way for QHY294PROC owners to begin experimenting with 47M images. I converted your 47M TIFF images into FITS images and used Deep Sky Stacker(DSS) to display the resulting images.  I zoomed in to a very stylish bird poop in your image of the neighbor's roof.

47M Original.jpg
This is what your original image looks like.  DSS does not understand the custom bayer pattern in 47M images so you end up with a checkboard pattern on a grey image.  The darker squares of pixels are the red pixels.

47M Custom Bayer.jpg
This is what this same close-up looks like using my custom bayer algorithm. My algorithm just shuffles the pixels around to achieve a standard RGGB bayer pattern.  Every red pixel in the original is treated as a red pixel in the custom bayer image.  This is also true for the green and for the blue pixels. The image is not perfect but if several astro images were stacked, the result might have smooth transitions.

47M Legend.jpg
This is what the entire image looks like using my custom bayer algorithm.  The arrow points to the stylish bird poop.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: March 12, 2021, 08:44:40 AM »
I have not had the FPGA updated for my QHY294C.  When I use Sharpcap with the latest all-in-one drivers and SDK there are two mode available in Sharpcap.  They are 11M and NOT EXIST.  I never bothered testing whether the camera would function in the NOT EXIST mode.  If you study the screen captures from QHYceced you can tell that he is able to select a 47M mode for his camera so Sharpcap believes that QHYceced's camera supports the 47M mode.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: March 11, 2021, 01:39:56 PM »
Thanks very much for your images.  I can clearly see the quad bayer pattern in the data when you zoom in on the data.  The dark spots are the clusters of red pixels. I also looked at the individual data and my bet is that the correct whitebalance value for your camera is 16 in 47M mode. Here is my reasoning.

When the QHY294PROC generates a 47M image it does this using a 12b A/D converter.  QHY scales this data up so that it fills the full 16b.  This results in the data being multiplied by 16. The A/D converter generates values that increase as 0, 1, 2, 3, 4... The corresponding values in the image file increase as 0, 16, 32, 48, 64...  This only happens when the whitebalance parameters are set to the default values.  The values in the first image 2021-03-11-1523_3-Capture_00001.tif increase by 16.  This is the image where you said the whitebalance values were set to 16.

When I look at the second image you sent the values increase by a modulated amount.  Most of the values increase by 32 but every seventh value increases by 16. This happens when the whitebalance values are increased above their default values. For this second image you said that the whitebalance value was set to 30.

If you set the whitebalance to something less than 16 you will find that the values continue to increase by 16 because this is the minimum change allowed for a 12b camera.  If you switch back to 11M mode the A/D converter is operating in 14b mode.  In 14b mode the minimum allowed change drops to 4.

So, my opinion is that the default whitebalance value for the QHY294PROC is 16 regardless of whether the camera is operating in 11M or 47M mode. 16 is also the default whitebalance value for the QHY294C.  Hopefully QHY will confirm this.


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: March 08, 2021, 10:46:22 AM »
Can you put up a 47M image you took during the daytime...maybe of your neighbor's roof. It will be huge so if you could put it up on dropbox or something similar and post a link to it here.

I would love to take a look at it.  Use the 120 whitebalance values as per QinXiaoXu.

Many thanks


QHYCCD SDK FOR WINDOWS / Re: ONE page for drivers etc.
« on: March 07, 2021, 09:11:19 AM »
When I did my testing of my QHY294C (no firmware update) the whitebalance values were all set to 16. I use my own custom software and it uses the default values provided in the QHY driver.  I know that within the last year I had posted to Robin at Sharpcap about his program changing the whitebalance values to 64 which he corrected.  It may be that this same problem has creeped back in because of the new camera designation.  I suspect that if you modified the whitebalance values back to 16 you will see that the spikeyness of the histogram will go away.  Also the image will be darker by the ratio of 16:120.

QHY needs to confirm that the default whitebalance values for a QHY294PROC are 16 and not 120.

Can you post an 47M image where you deselect the debayer preview.  When Sharpcap provides the debayer preview it is assuming the classic bayer pattern which is not true for the 47M image.  At present, the 47M image is a greyscale image.


Image Issue Q&A / Re: QHY294C LGC/HGC characteristics
« on: March 05, 2021, 10:11:12 AM »
I finally had a chance to test the 20210226 AllInOne update and the fullwell limitation issue is fixed.  Here are my findings.

1)I was able to run the Sharpcap 32b sensor analysis and it shows that the camera performs correctly.  The LGC/HGC modes work correctly.  I had to take care when performing the sensor analysis because it would fail right after it tested the read noise characteristic.  You need to watch and when it asks to remove the lens cap you need to do this as quickly as possible otherwise the routine will time-out claiming the exposure time is too large.  I will contact Robin about this issue. The results of this test are shown in [Sharpcap32.jpg].

2)I did some BIAS frames at GAIN=1599 and GAIN=1600.  The drop in mean values and noise are in keeping with the reduction of read noise that happens at GAIN=1600.

3)The fullwell issue originally looked like [10 seconds at GN=1600.jpg] This is what the histogram did look like if an overexposed image were taken.  Now the values are clamped at 65,535 which is perfect.

Thank-you for all your efforts


Pages: [1] 2 3 ... 6