Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Full Frame Mono Camera Coming Soon - QHY600 (IMX455)

  • Please log in to reply
689 replies to this topic

#601 smccully

smccully

    Vostok 1

  • *****
  • Posts: 142
  • Joined: 25 Dec 2018
  • Loc: Florida

Posted 17 May 2020 - 04:59 PM

1.Please wait a moment, I have contacted the engineer, he will give an explanation.

 

2. You may be required to mail the camera to QHY maintenance point in Hong Kong, and we need to modify it.

 

Yang

 

I just wanted to follow up on my question about Dark Frame Calibration for the QHY600 with overscan region. I suppose maybe their are two questions here,

 

1. Dark Calibration with just the overscan regions.

2. Dark Calibration with overscan regions and MasterDark, Bias frames. 

 

 

Appreciate the support. 

Sean



#602 QiuHY

QiuHY

    Vendor (QHYCCD)

  • -----
  • Vendors
  • Posts: 142
  • Joined: 19 Apr 2004
  • Loc: Beijing CHINA

Posted 19 May 2020 - 12:30 PM

I just wanted to follow up on my question about Dark Frame Calibration for the QHY600 with overscan region. I suppose maybe their are two questions here,

 

1. Dark Calibration with just the overscan regions.

2. Dark Calibration with overscan regions and MasterDark, Bias frames. 

 

 

Appreciate the support. 

Sean

 

 

Hello, 

 

          The overscan area used to do the "Overscan Trim"   There is some topic on the basic concept of it , You can search "Overscan Trim" and you can find may useful infomation.

 

https://users.astro....andouts/ccd.pdf

 

 

And Here I think we can simpfied it for astrophotograhy :

 

 

Calibrate results = (L-D)/(F-B)

 

L: LIGHT FRAME

D: DARK FRAME

F: FLAT FRAME

B: BIAS FRAME

 

and we always use the dark flat frame (DF) to instead of bias frame .   so it is 

 

(L-D)/(F-DF)

 

 

The overscan calibrate is to correct the "base line" of a image, or we can say  that each frame may has a drift . Ths drift can be regards as each pixel been add a constant.  Ths constant is the same to all the pixel in one frame, But each frame the constant is not the same.  If we calculate the average of the overscan area, we can get this constant of each frame. The goal of the calibration is to let each frame has the same constant .

 

And I think we do not need to do overscan calibraton for light frame and dark frame. Because they are in numerator of it. It will not cause any problem for astrophotograhy. (but for obsolutely meassurement it will cause something) . What we need to do is for the (F-DF) since it is in the denominator.  So we must calbrate the Flat frame and Dark Flat frame to let same has the same constant (overscan value).

 

 

So the method is :

Get the master flat frame

get the master dark flat frame

 

Measure the average of the overscan area of the master flat frame and master dark flat frame.  For example , the master flat is 500,  the mast dark frame is 600. Then , you can add a constant 100 to the whole master flat .  Then , the master flat 's overscan value will become 600. Then you can use (F-DF) to get the calibrated master dark frame.

 

 

Best regards,

Qiu Hongyun


Edited by QiuHY, 19 May 2020 - 12:38 PM.

  • ccs_hello, Gene3 and ezwheels like this

#603 smccully

smccully

    Vostok 1

  • *****
  • Posts: 142
  • Joined: 25 Dec 2018
  • Loc: Florida

Posted 20 May 2020 - 02:20 AM

Hello, 

 

          The overscan area used to do the "Overscan Trim"   There is some topic on the basic concept of it , You can search "Overscan Trim" and you can find may useful infomation.

 

https://users.astro....andouts/ccd.pdf

 

 

And Here I think we can simpfied it for astrophotograhy :

 

 

Calibrate results = (L-D)/(F-B)

 

L: LIGHT FRAME

D: DARK FRAME

F: FLAT FRAME

B: BIAS FRAME

 

and we always use the dark flat frame (DF) to instead of bias frame .   so it is 

 

(L-D)/(F-DF)

 

 

The overscan calibrate is to correct the "base line" of a image, or we can say  that each frame may has a drift . Ths drift can be regards as each pixel been add a constant.  Ths constant is the same to all the pixel in one frame, But each frame the constant is not the same.  If we calculate the average of the overscan area, we can get this constant of each frame. The goal of the calibration is to let each frame has the same constant .

 

And I think we do not need to do overscan calibraton for light frame and dark frame. Because they are in numerator of it. It will not cause any problem for astrophotograhy. (but for obsolutely meassurement it will cause something) . What we need to do is for the (F-DF) since it is in the denominator.  So we must calbrate the Flat frame and Dark Flat frame to let same has the same constant (overscan value).

 

 

So the method is :

Get the master flat frame

get the master dark flat frame

 

Measure the average of the overscan area of the master flat frame and master dark flat frame.  For example , the master flat is 500,  the mast dark frame is 600. Then , you can add a constant 100 to the whole master flat .  Then , the master flat 's overscan value will become 600. Then you can use (F-DF) to get the calibrated master dark frame.

 

 

Best regards,

Qiu Hongyun

 

 

Thank you for this information, the reason this came up in a discussion was that the QHY600 has two overscan regions. So based on your response when measuring the average of the overscan regions should we

 

-- combine the two overscan regions and take the average?

-- combine the two averages of the overscan regions?

 

 

You also mention Flat Darks, I am currently not doing this but will change my calibration processes accordingly.



#604 QiuHY

QiuHY

    Vendor (QHYCCD)

  • -----
  • Vendors
  • Posts: 142
  • Joined: 19 Apr 2004
  • Loc: Beijing CHINA

Posted 20 May 2020 - 10:50 AM

Thank you for this information, the reason this came up in a discussion was that the QHY600 has two overscan regions. So based on your response when measuring the average of the overscan regions should we

 

-- combine the two overscan regions and take the average?

-- combine the two averages of the overscan regions?

 

 

You also mention Flat Darks, I am currently not doing this but will change my calibration processes accordingly.

You are welcome.  The overcan area is in bottom. The left area is not the overscan area . Actually it is optic black area.  The optic black area will includes the thermal noise. Like a "dark” and the overscan area does not includes the thermal noise, it is like the "bias).

 

 For flat frame calibraion. If the exposure time is not very long, you can use either of them.  But I think just one are is ok, no need to combine because there are enough pixels. For long exposure flat frame. If you use the “DARK FLAT FRAME (DF)”. I think you can use the overscan area. 

 

Normally speaking the Flat dark frames is better than bias frames for calibration the dark frame. Because it has the same exposure time with the flat frames. So all conditions is the same.  (some cmos/ccd sensor will change the work mode from short exposure to long exposure.  so if you  use a long expousre for flat frame and use short exposure (0sec) for bias frame. The work mode change will cause many behavior not the same. it will caue the flat frame calibration has problems.

 

Best reards,

Qiu Hongyun


  • rgsalinger and Gene3 like this

#605 Gene3

Gene3

    Viking 1

  • *****
  • Posts: 753
  • Joined: 02 Feb 2016
  • Loc: Del Mar, CA

Posted 21 May 2020 - 09:46 AM

This has been very informative as I did not understand the function of overscan area and have always turned it off.

From the discussion above by enabling overscan then each flat sub will have area at the bottom that produces dark flat frame data. Is that correct? Does this mean that I do not need to take separate dark flat frames?

Would I then just load these flats along with the light frames (overscan area enabled) into PI? No bias frames or separate dark frames needed?

 

Thank you,

Gene



#606 smccully

smccully

    Vostok 1

  • *****
  • Posts: 142
  • Joined: 25 Dec 2018
  • Loc: Florida

Posted 21 May 2020 - 10:07 AM

This has been very informative as I did not understand the function of overscan area and have always turned it off.

From the discussion above by enabling overscan then each flat sub will have area at the bottom that produces dark flat frame data. Is that correct? Does this mean that I do not need to take separate dark flat frames?

Would I then just load these flats along with the light frames (overscan area enabled) into PI? No bias frames or separate dark frames needed?

 

Thank you,

Gene

https://www.qhyccd.c...catid=30&id=260

 

I don't think that's accurate, there are two overscan regions on the QHY600 bottom and left. The Left Overscan region is the optic black area and contains dark thermal noise (i.e. dark) and the bottom does not contain thermal noise and as mentioned by Qiu is like bias.

 

The catch, I suppose if your using PixInsight at least does not differentiate from multiple overscan regions (they are treated the same). Which is why I asked this question how should we handle calibrating the overscan regions. 

 

If you're inclined, you could write your own code to manually do operations on your Lights with the overscan regions to calibrate dark and bias out on the fly as I understand. 


  • Gene3 likes this

#607 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 513
  • Joined: 10 Jun 2007

Posted 21 May 2020 - 10:21 AM

Having just put the ability to include the overscan and optical black areas in images in NINA at the request of a QHY600 user, I've been more interested in how these are actually utilized since I also have a QHY600 of my own on the way, and my QHY294C also has such areas. Curiously, the QHY183M I have lacks both overscan and optical black areas.

 

There's a recent thread on the PixInsight forums that concerns this very subject and might be worth reading and watching:

https://pixinsight.c...rocedure.14469/


  • rgsalinger likes this

#608 smccully

smccully

    Vostok 1

  • *****
  • Posts: 142
  • Joined: 25 Dec 2018
  • Loc: Florida

Posted 21 May 2020 - 10:25 AM

You are welcome.  The overcan area is in bottom. The left area is not the overscan area . Actually it is optic black area.  The optic black area will includes the thermal noise. Like a "dark” and the overscan area does not includes the thermal noise, it is like the "bias).

 

 For flat frame calibraion. If the exposure time is not very long, you can use either of them.  But I think just one are is ok, no need to combine because there are enough pixels. For long exposure flat frame. If you use the “DARK FLAT FRAME (DF)”. I think you can use the overscan area. 

 

Normally speaking the Flat dark frames is better than bias frames for calibration the dark frame. Because it has the same exposure time with the flat frames. So all conditions is the same.  (some cmos/ccd sensor will change the work mode from short exposure to long exposure.  so if you  use a long expousre for flat frame and use short exposure (0sec) for bias frame. The work mode change will cause many behavior not the same. it will caue the flat frame calibration has problems.

 

Best reards,

Qiu Hongyun

 

Thank you for this explanation it helps, out of curiosity though. If we were interested in absolute measurements, how should the overscan regions be calibrated differently than might we do if just for a quick solution like astrophotography? 

 

Should the optic black area and overscan be treated differently when subtracting from Calibration (Darks, Flats)? Lights?


  • hahied likes this

#609 n2068dd

n2068dd

    Viking 1

  • *****
  • Posts: 563
  • Joined: 24 Jun 2012
  • Loc: Sapporo

Posted 23 May 2020 - 12:23 AM

Hi,

 

overscan area = out side of the pixel count area     O.K.?

 

I've heard that of out side area is used by the genuine camera software to use with some applications.

Nikon use there to investigate the chromatic aberration of magnification to correct. And most of the company use there to debayer. A debayer needs to use 10*10 pixel kernel ( from canon documents), if you need to determine the edge pixel, about 5*10 more pixel beyond the boarder will be needed. Or SONY use there to Image stabilize or stacked high dynamic range photo. It depends on the customer who can use there. Maybe, no need for monochromatic camera.

 

Regards



#610 wrcooney

wrcooney

    Lift Off

  • -----
  • Posts: 8
  • Joined: 08 Dec 2013
  • Loc: Cypress, TX

Posted 26 May 2020 - 01:40 PM

Dennis di Cicco reviewed the QHY600M in the July S&T and had a lot of favorable things to say.  He also mentioned that darks not taken within a few nights of the light frames did not "work as expected."  Has anyone else seen a similar issue and could you expound on it?  Since the camera doesn't have a mechanical shutter, being able to use a dark library over some weeks or months is important.

 

Thanks,

Walt



#611 smccully

smccully

    Vostok 1

  • *****
  • Posts: 142
  • Joined: 25 Dec 2018
  • Loc: Florida

Posted 26 May 2020 - 03:04 PM

Dennis di Cicco reviewed the QHY600M in the July S&T and had a lot of favorable things to say.  He also mentioned that darks not taken within a few nights of the light frames did not "work as expected."  Has anyone else seen a similar issue and could you expound on it?  Since the camera doesn't have a mechanical shutter, being able to use a dark library over some weeks or months is important.

 

Thanks,

Walt

 

Ive not read the review, so I am not sure what the comment is based off of. But I am using Darks that are over 6 months old at this point, though I do match temp., and exp. times for every captured light. I have built a dark library with varying temps. and exp. times. There appears to have been some discussions that dark frame scaling does not really work with the IMX455 sensor. 


  • psandelle likes this

#612 Morefield

Morefield

    Mariner 2

  • -----
  • Posts: 200
  • Joined: 01 Jun 2014
  • Loc: Portland, OR

Posted 26 May 2020 - 05:45 PM

Dennis di Cicco reviewed the QHY600M in the July S&T and had a lot of favorable things to say.  He also mentioned that darks not taken within a few nights of the light frames did not "work as expected."  Has anyone else seen a similar issue and could you expound on it?  Since the camera doesn't have a mechanical shutter, being able to use a dark library over some weeks or months is important.

 

Thanks,

Walt

I have not seen any issues with darks on my QHY600M.  There is a problem with bright stars causing dark rows.  This was explained to me as something similar to (but opposite) blooming on CCDs.  It is a nuisance, but since it only affects the background it is not too difficult to fix in post-processing.  I'm hoping there is a solution though.

 

Walt, I am using an 8 position FW with a dark filter to act as a shutter.  This allows me to shoot darks remotely - albeit only at night.



#613 wrcooney

wrcooney

    Lift Off

  • -----
  • Posts: 8
  • Joined: 08 Dec 2013
  • Loc: Cypress, TX

Posted 27 May 2020 - 10:47 AM

Thanks for the replies.  Dennis mentions in the review that dark frames can't be scaled so he is aware of that issue.  In addition to your comments that you haven't seen darks go stale quickly, no one has replied that they are seeing the issue so I take it there isn't a problem.  Good news.  Morefield, I haven't purchased one of the cameras yet, but I'll have to do the same with a dark filter for a shutter taking darks.  I do photometry so the bright star dark rows will be a bit of a problem at times, but something I can work around I think by placing too-bright stars off chip and/or adjusting exposure times.

 

Clearest skies,

Walt



#614 Morefield

Morefield

    Mariner 2

  • -----
  • Posts: 200
  • Joined: 01 Jun 2014
  • Loc: Portland, OR

Posted 28 May 2020 - 12:55 AM

Thanks for the replies.  Dennis mentions in the review that dark frames can't be scaled so he is aware of that issue.  In addition to your comments that you haven't seen darks go stale quickly, no one has replied that they are seeing the issue so I take it there isn't a problem.  Good news.  Morefield, I haven't purchased one of the cameras yet, but I'll have to do the same with a dark filter for a shutter taking darks.  I do photometry so the bright star dark rows will be a bit of a problem at times, but something I can work around I think by placing too-bright stars off chip and/or adjusting exposure times.

 

Clearest skies,

Walt

I would not scale darks with this camera, too easy to just shot the matching dark exposure time.  Oddly enough, just this morning I downloaded data from last night and had the darks not fully remove the dark noise.  I tried skipping the bias and sure enough the darks then worked.  Didn’t have time to fully research but it looked like the darks were somehow being scaled when they shouldn’t be.   Possibly some glitch with CCDStack applying the wrong file?  I’ll look further at tomorrow’s subs.

 

It’s odd the Dennis would go as far as putting the dark frame issue as the “con” on this camera without actually saying what the problem was that he saw.  I also thought it off that he said he felt the images were noisier and yet much deeper those observations seem at odds with each other.  My experience comparing 16803 data to QHY600 data is that the QHY data is much cleaner.


  • psandelle and Gene3 like this

#615 S70IP

S70IP

    Sputnik

  • -----
  • Posts: 36
  • Joined: 31 Aug 2016

Posted 03 June 2020 - 05:37 AM

Has anyone notice that the camera doesn’t expose for the full time? Both in Sharpcap and NINA if I set 600s it finishes at 593s?



#616 Gene3

Gene3

    Viking 1

  • *****
  • Posts: 753
  • Joined: 02 Feb 2016
  • Loc: Del Mar, CA

Posted 03 June 2020 - 11:15 AM

I just tested my 600M out at 450s and it did expose for the full time.

I use SB SkyX Pro and the ASCOM driver for the camera.


  • Ken Sturrock likes this

#617 QiuHY

QiuHY

    Vendor (QHYCCD)

  • -----
  • Vendors
  • Posts: 142
  • Joined: 19 Apr 2004
  • Loc: Beijing CHINA

Posted 07 June 2020 - 12:30 AM

Has anyone notice that the camera doesn’t expose for the full time? Both in Sharpcap and NINA if I set 600s it finishes at 593s?

Normally the sdk is designed to begin to download about some seconds before the end of the exposure. In some old camera like QHY163 and the CCD cameras, this is to prevent the download too lately than the end of the exposure, which will cause the amplifer light (the amplifer light control will stop after the exposure, so after ending of exposure and computer does not readout ontime, it will cause the amplifer light effect the exposured image)

In QHY600 the sensor has no amplifer and also the DDR can buffer the image without the computer readout. But even we still ask the computer to begin to readout a little early .

 

The actual exposure is till 600sec. The camera just end of showing the exposure progress bar at the 593sec.  

 

Best regards,

Qiu Hongyun


Edited by QiuHY, 07 June 2020 - 08:50 AM.

  • psandelle likes this

#618 S70IP

S70IP

    Sputnik

  • -----
  • Posts: 36
  • Joined: 31 Aug 2016

Posted 07 June 2020 - 01:01 AM

Ok thank you Qiu, as long as the behaviour is constant that’s is fine.

Thank you for your reply.

 

Has QHY done something more testing on the QE of the camera? In the application notes it mentions that QHY were going to do some more testing around the QE.



#619 bortle2

bortle2

    Mariner 2

  • -----
  • Posts: 204
  • Joined: 18 Sep 2019

Posted 07 June 2020 - 01:35 AM

Thank you for the information, Qiu.

 

In QHY600 the sensor has no amplifer and also the DDR can buffer the image without the computer readout. But even we still ask the computer to begin to readout a little early .

 

I understands the reasons, but that's still a bug.

 

Do you plan to fix it? (IMO you absolutely have to do something about it).



#620 QiuHY

QiuHY

    Vendor (QHYCCD)

  • -----
  • Vendors
  • Posts: 142
  • Joined: 19 Apr 2004
  • Loc: Beijing CHINA

Posted 07 June 2020 - 08:46 AM

Thank you for the information, Qiu.

 

I understands the reasons, but that's still a bug.

 

Do you plan to fix it? (IMO you absolutely have to do something about it).

But the actual time is still 600sec. Computer is just go ahead to begin the download thread, but the data will not come till 600sec exposure ending. So it should not a bug.

 

Best regards,

QIu Hongyun


  • psandelle likes this

#621 QiuHY

QiuHY

    Vendor (QHYCCD)

  • -----
  • Vendors
  • Posts: 142
  • Joined: 19 Apr 2004
  • Loc: Beijing CHINA

Posted 07 June 2020 - 08:52 AM

Ok thank you Qiu, as long as the behaviour is constant that’s is fine.

Thank you for your reply.

 

Has QHY done something more testing on the QE of the camera? In the application notes it mentions that QHY were going to do some more testing around the QE.

We have not yet. We found a sony data shows the 89% peak QE in the new full frame sensors. so that our test data is almost match the sony data.So we believe it is about >87% QE. 


  • psandelle likes this

#622 bortle2

bortle2

    Mariner 2

  • -----
  • Posts: 204
  • Joined: 18 Sep 2019

Posted 07 June 2020 - 04:04 PM

Computer is just go ahead to begin the download thread, but the data will not come till 600sec exposure ending.

OK... So what does the download thread do? Sits idle for 600 - 593 == 7 seconds? Or actually starts downloading captured data?



#623 rgsalinger

rgsalinger

    Fly Me to the Moon

  • *****
  • Moderators
  • Posts: 6,425
  • Joined: 19 Feb 2007
  • Loc: Carlsbad Ca

Posted 08 June 2020 - 01:46 PM

I have two questions -----

 

I use MaximDL to image and it shows be 300 seconds or 180 seconds as specified, etc every time. Not sure why other software would show something different. I am using the old driver for the time being as I do not understand the point about putting a dll from the SDK into a special directory to get it to work as an ASCOM camera. Is that really necessary?

 

Does anyone have a recommendation for narrow band (mine are 5nm) settings for the camera?

 

 

Rgrds-Ross


  • psandelle likes this

#624 Peter in Reno

Peter in Reno

    Voyager 1

  • *****
  • Posts: 10,893
  • Joined: 15 Jul 2008
  • Loc: Reno, NV

Posted 08 June 2020 - 02:04 PM

That's what QHY web site said:

 

In this ascom, please download the latest QHYCCD SDK (qhyccd.dll) of QHY600 and replace it in this path: C:\Program Files(x86)\ Common Files \ ASCOM \ Camera

 

https://www.qhyccd.c...=94&id=55&cut=2

 

Look under ASCOM Driver. 

 

Peter 


Edited by Peter in Reno, 08 June 2020 - 02:05 PM.


#625 rgsalinger

rgsalinger

    Fly Me to the Moon

  • *****
  • Moderators
  • Posts: 6,425
  • Joined: 19 Feb 2007
  • Loc: Carlsbad Ca

Posted 08 June 2020 - 03:15 PM

Thank you Peter. However, how hard would it be to just make it clear by saying - This ASCOM driver will not work unless the qhyccd.dll file from the latest SDK is place in the "named directory". 

 

This seems pretty bizarre to me. I'll pass until they clean up their drivers.

 

Rgrds-Ross


  • psandelle likes this


CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics