SharpCap Forums

Hi Robin,

As you surely know some QHY cameras offer all their complete frame to be used, including the calibration areas which are normally not used and not stored in new frames (I know you perfectly know ).

With my 268M camera I have this strange behavior:

If I use it in still mode the frame size is 6252X4176
BUT If I use it in live mode frame size is 6280X4210 (not cut)

How can I do to use the valid size in live mode too?

T&R

Hi,

my experience with the QHY294PROC is that in live mode the data is valid across the whole area, so I use the full resolution. In still mode you get junk in the calibration regions, which is bad for stacking programs, so I cut out the overscan area in still mode.

It may be that I need to cut out the overscan area in both modes - the problem is knowing as so many QHY cameras have their own individual behaviours that are not shared with other models

cheers,

Robin

Hi Robin,

I understand that you are making different requests to the QHY API on live and still modes, And QHY is the one deciding the frame size?

Sorry I thought that you were making the same request in both cases (and handling the live behavior) so I did not understand why you were choosing different frame sizes.

In any case this was not the previous behavior in the camera, QHY must have changed something in their drivers then

T&R

Hi,

so the previous behaviour (SC 3.2) was that SharpCap ignored the overscan setup entirely - that had problems in other areas, so I tried to take account of overscan in 4.0 for still mode, but ended up with the problem you are encoutering that you must not mix live and still mode

Essentially, the QHY SDK/driver is almost too flexible - you can make it do lots of things, some of which are not the best of ideas...

I will try to find something that is reliable and consistent.

cheers,

Robin

Thank you Robin,

Meanwhile ... when needed I make a global crop in PI that fully solves it ... so it's not a major issue for me

T&R

Hmm,

I just tried setting the size in video mode to be the same as the one used in still mode on my 294PROC... Although that works and gives the correct output area, it's even worse from an end user point of view because there is a 2 pixel horizontal offset between the two images (as measured using fixed hot pixel positions). As far as I can tell there is no way to work out from the SDK that the offset is 2 pixels, so it may be different for different cameras/modes/binning/resolution.

To me it looks like the cure is worse than the original problem. At least with the current setup, your stacking program will tell you that the darks and lights are not compatible if you take them in different modes. If I change to make the resolution the same but there is an unknown offset then the darks/flats will apply, but give poor results.

I think my recommendation for now is going to be either

1) Don't flip between live and still mode when capturing images for a project on QHY cameras

or

2) Set the 'Force still mode' control to 'on' and leave it on all the time, meaning that live mode will just be a sequence of still frames and everything will match. Probably best to set that up in a default capture profile for the camera.

cheers,

Robin

Aaaaaaaaaah... I fell in to this trap. Couldn't figure out why my calibration frames wouldn't register with half my light frames. Eventually realized they had slightly different dimensions, and remembered seeing something about image size mentioned here in the forum. Also explains why some sequences have a camera settings file for each frame (still mode), while others have a single settings file for all frames in the sequence (live mode).

I had completely forgotten about this issue, and was switching back and forth between live and still mode as needed. I switch to still mode to reduce resource overhead on my system while I focus on other setup tasks, like getting guiding up and running. I switched back to live mode to check focus after the meridian flip, but forgot to switch back to still mode until I started capturing calibration frames.

I'm not sure what to do with that data now. I'm using Astro Pixel Processor to stack and process my images, but I'm relatively new to the software. So not sure how to go about cropping if that's an option. I set it aside for now.

Thanks for the suggestions, Robin. Will keep this in mind moving forward.

Hi,

in theory you should be able to crop the larger frames (captured in live mode) down to match the smaller ones. You can do this processing in PIPP where it is fairly simple to process a folder full of images to a new folder of cropped images. What you need to do is work out the offset needed, which may vary from camera model to camera model...

The way to work out the offset is as follows:

1) Cover sensor, set high gain, maybe 1s exposure
2) Use image histogram stretch in SharpCap to make hot/warm pixels very visible
3) Use the pixel position tool in SharpCap so you can read off pixel co-ordinates
4) Compare the hot/warm pixel patterns in live and still mode to work out the offset (in X and Y) needed to go from the locations in live mode to the locations in still mode

For instance, you might work out that the hot pixel co-ordinates would match up if you add 16 to the X co-ordinate and 4 to the Y co-ordinate when going from live to still mode.

16 and 4 are then *probably* the offsets you need for cropping, but do check, since SharpCap counts pixels from the top left, but maybe PIPP does from the bottom left (which is strictly the standard for FITS files).

cheers,

Robin

Thank you, Robin!

I'll give that a try, and let you know how it goes.

Much appreciated,

Nikko

Hi,

if you do find the offset in pixels that lines up the two images, please can you share it with me - unfortunately the SDK gives no way for me to find this value out, but if I can find the values for a range of cameras, maybe I can spot a pattern and then I can program SharpCap to take care of this problem.

cheers,

Robin