AweSIM

@fifeskies you made some interesting observations and thank you for sharing your experience as well. You're right about the ROR blocking most artificial light sources in my neighborhood. But what surprised me the most was that even though the telescope will fit inside the room, it will still be able to see so close to the horizon.

For me, the most fun part was programmatically generating a horizon for the room itself. Also, now that I have the horizon image, I can also use it to program mount limits in EQMOD, although that might be an overkill. 🙂

I've been wanting to construct an observatory on top of my house for a long time and am finally almost ready to build one. I settled for a roll-off roof design with the observatory being almost 10 feet by 10 feet and 7 feet high. I'd park my telescope in a horizontal parking position. My main concern was that what if I construct the observatory room too small or too tall so that it blocks out a good portion of the sky that would otherwise be accessible to me without an observatory. This post is more of a blog about my journey thus far, in hopes that others might find it interesting or useful.

I came across an article online (don't remember the source, sorry) that showed how to show a custom horizon in Stellarium. I climbed onto the roof where the proposed observatory is supposed to be built and shot a 360 degree spherical panorama using Google Traffic app for Android. I exported the unwrapped 4096 x 2048 pixel image and edited it using Photoshop to make the sky transparent. An interesting problem I encountered in this process was that the horizon is not always in the middle of the image, so I needed to have a reference object in the same 360 degree panorama at the camera level. Being at the same level, it should touch the horizon, and this means that the top of this object should lie in the exact middle of the unwrapped image vertically. If it is not, the entire image can be shifted up or down till it is. Finally, I crafted a suitable "landscape.ini" file to reference the unwrapped image and define its Z-rotation and packed these assets into a zip file. Finally I imported it into Stellarium and viola! I could see my custom horizon perfectly. Stellarium now showed me views exactly as it would appear as if I stood at that spot myself. This step helped confirm if the spot I had chosen for my observatory was good or not (It was! Only 10 degrees above horizon was blocked, except south-east where almost 30 degress above horizon was obscured by trees).

However, the issue still remained whether the observatory, once constructed, would block significant portions of the sky or not, and there was no easy way to test this. So I decided to put my software development skills to the test to address this. The proposed observatory is about 10 feet by 10 feet in size and about 7 feet high, with the scope placed in the middle of the room. With the walls so close to the telescope, parallax plays an important role.

I created a quick programming project in TypeScript, included a good matrix maths base library, and created some 3D math classes on top of that to work with vectors, matrices and calculate ray-triangle intersections, etc. I created a basic 3D model of my telescope and mount such that the camera it looking out along the axis of the telescope, and can rotate like an equatorial mount along RA and DEC. I also created a very simple model of the proposed observatory with four walls, each made up of two triangles.

The code loops thru each possible value of RA and DEC and computes where the telescope is pointing in the sky. It then computes if there is a wall triangle in between the telescope and its target. If there is, the code converts the direction the telescope is pointed at into polar coordinates (alt-azimuth) and plots a point on a graph where horizontal axis is azimuth and the vertical axis is altitude. If there is no triangle between the telescope and its target, it means that the sky is visible in that direction.

This allows me to generate an 360 degree unwrapped panoramic image much like the horizontal I captured earlier. Using photoshop, I overlaid the custom horizon on top of the generated image to get the following image.

This image clearly shows that the walls of the observatory don't obscure any significant additional portion of the sky, and hence the design is perfect from the perspective of viewing angles. Furthermore, we can also create a custom horizon out of this image and import it into Stellarium.

Thank you for reading this. 😃

1 minute ago, vlaiv said:

Which part? That it needs collimation? That is kind of obvious - look at the star shapes:

Here is collimated RC scope (RC8):

Stars are tight and round.

Another telltale is that stars look different in different corners and they are not round even in center. If primary is not aligned properly but secondary is - then stars will be distorted in corners but not in center, a bit like this:

Close to center:

Corner

:

Thank you so much for the insight!

4 hours ago, vlaiv said:

Not quite good - you should collimate your scope for sure.

I think that even your secondary is not properly aligned - and that is rather easy to do.

How were you able to tell? 😮 And how is the secondary easier to adjust than the primary? I thought it was the other way around.

5 hours ago, Waldemar said:

deleted

FF distance to sensor.docx 77.68 kB · 4 downloads

I never knew that! Thanks for this document. I learnt something new today! 😃

23 minutes ago, vlaiv said:

Just had another idea to save some space / change distances:

https://www.aliexpress.com/item/1970984046.html?spm=a2g0o.detail.1000014.1.5911718bxAenmh&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.14976.165864.0&scm_id=1007.14976.165864.0&scm-url=1007.14976.165864.0&pvid=02f83b59-6244-42de-9763-8e13e3be81ce&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.14976.165864.0,pvid:02f83b59-6244-42de-9763-8e13e3be81ce,tpp_buckets:668%230%23131923%235_668%23808%234093%2312_668%23888%233325%2314_4976%230%23165864%230_4976%232711%237538%23362_4976%233223%2310815%238_4976%233104%239653%234_4976%233141%239887%237_668%232846%238111%23492_668%232717%237566%23809_668%231000022185%231000069217%230_668%233422%2315392%23292

 

Thank you for linking this item as well. I'll definitely keep an eye out for this item and I'm glad you picked the site I could actually purchase from. Thank you once again! 😃

15 minutes ago, vlaiv said:

I'm by no means expert on this, but here are my thoughts on the subject and hopefully it will help in one way or another.

Why do you need camera rotator in the first place?

Camera rotators are very useful if you have threaded connection to telescope - which means everything is screwed together and screwed in focuser. Once everything is screwed together - you cannot adjust camera angle any more by rotation in focuser - as any rotation will disassemble the whole thing.

As is, with your setup, you already have suitable mechanism for rotation - loosen focuser screws, rotate whole camera / CC assembly in focuser, tighten focuser screws. Simple as that. Although camera and CC are screwed together - that assembly is inserted into focuser rather than screwed onto it.

If you think that having numbers for orientation is helpful - just start plate solving - it will tell you exact orientation of camera in degrees so you can match it between sessions. You can also DIY some sort of dial do you know how much you are turning your camera (but you really don't need one - you'll quickly learn by feel how much to turn).

Even if you don't plate solve there are ways to orient your camera the same between imaging sessions - align X/Y to RA/DEC - either by slewing in exposure or drifting in exposure. You start exposure on a bright star and either slew telescope at low speed, or stop telescope tracking. Star will make a trail. Rotate camera until that line is horizontal (or vertical - depends how you want to frame your shot).

If you really want to add this part, then here are other tips that I can think of:

- longer male thread is a problem, longer female thread is not a problem. You calculate from "shoulder" to "shoulder". In your case you had 5mm female and 6mm male - so yes, there is a "gap" of 1mm that you should add to calculation. Don't worry about light leak - no way it will leak in the light

- I don't know about coma correctors (never used one), but field flatteners and reducers need to be "dialed" in for particular telescope in question. This usually means that prescribed distance is only a guideline - you actually need to try it out and adjust it for best results. For this, variable length extension tubes are very good solution, and so are shims. You can get either plastic or aluminum shims of 0.1 to 0.5mm and 1mm that you put on M42 or M48 threads (between parts to add some distance - opposite of above "gap")

- You can actually make different order of elements. Problem that you have is that you need to keep both female-to-female 11mm for camera since both camera and CC have male thread so you need to switch order at some point, and you need to keep T2/M48 adapter since you need to switch thread size as well. But you have some room to do things differently.

You can arrange it like this:

Camera - rotator (in reverse, it should not matter) - 11mm - whatever you need here - T2/M48 adapter

This gives you another option - you can combine 11mm and whatever you need to reach distance into single variable length extension female/female T2. This is for T2 version of rotator.

 

 

Hi @vlaiv, thanks a lot for your valuable suggestions and some great insights. I didn't know that the backfocus of 55mm was an approximate value. How should it be dialed in and how can it be tested to see if its improving things or not? As in, is there a non-subjective way other than take an exposure, add shim, take another and judge whether things look better or worse?

Thank you for understanding the constraints of my assembly as well. Indeed I need a female-to-female adapter and a M42-to-M48 adapter at some point in my assembly. Your suggestions about the solution make sense, and if I go ahead and purchase a rotator, I will act upon your advice definitely.

As for why am I opting for a rotator instead of simply rotating the assembly myself is this: I have tried doing it exactly like youve said many times: taking an exposure, plate-solving to find rough orientation, repeat. But it is time consuming to get it right and everytime I loosen the screws and fiddle with the assembly, my focuser inadvertedly slips a bit and I have to go through focusing again and again. So I was thinking maybe a rotator that allows rotation without any resistance (on bearings) will be more helpful than my current technique. I even marked angles on my assembly using a pencil.

Keeping your advice in view, perhaps a better option for me might be to ditch the rotator and fix my focuser first so it doesn't slip. Your thoughts?

Thanks a lot!

Asim Sohail

26 minutes ago, Waldemar said:

Hi Asim,

Camera and rotator take 19mm. The coma corrector needs 55. That leaves 39mm to bridge.
This: https://www.baader-planetarium.com/en/baader-varilock-46-lockable-t-2-extensiontube-29-46mm-with-spanner-tool-(t-2-part-25v).html
will solve your problems. 

Hi @Waldemar,

Thanks for the suggestion. I can see some problems with this that I hope you will address:

1. The variable adapter you proposed is almost EUR 63 which is a bit expensive for my budget at the moment.
2. My coma corrector has an M48 male thread whereas the camera has a M42 male thread. Since most spacers have a male thread at one end and a female thread at the other, I will have to use the stock 11mm M42 female-to-female extender supplied so that the camera + 11mm spacer exposes a female thread and the coma corrector exposes a male thread. Total spacing required in this case is 55 - 6.5 - 12.5 - 11 = 25mm. Since I have a stock 16.5mm M42-to-M48 spacer supplied with the camera itself, if I use it, the spacer required will be, once again, 25 - 16.5 = 8.5mm. I don't think there are many variable spacers within this range. Besides, as noted in #1, they are way more expensive.

Thanks a lot!

Asim

@vlaiv, I really look forward to your advice on this. 😃

Hi!

A while ago, I acquired a ZWO ASI294MC Pro and a SkyWatcher F/5 Coma Corrector for my SkyWatcher 8" Newtonian telescope. The coma corrector requires a backfocus distance of 55mm which was straight forward to achieve:

1. Camera (back focus = 6.5mm)
2. 11mm M42 (female to female) extender (11mm)
3. 21mm M42 (male) to M42 (female) extender (21mm)
4. 16.5mm M42 (male) to M48 (female) extender (16.5mm)
5. Coma corrector with a M48 (male) thread

This all adds up to exactly 55mm which was all perfect. However, I've been thinking of getting a M42 CAA 360 ° Rotator Camera Angle Adjuster or a similar M48 one. Both of these have an extension thickness of 12.5mm. Furthermore, the length of the male thread on the rotator is 3mm while the female thread is 5mm long.

If I opt for the M42 rotator, I have only 1 option:

1. it will have to replace the existing 21mm spacer with an additional 8.5mm (21 - 12.5) spacer which is a very odd spacing and I can find no satisfactory option on AliExpress (which is I'm forced to buy items from as only it ships to Pakistan). My new assembly should become:
   1. Coma corrector
   2. 16.5mm M42-M48 extender (16.5mm)
   3. M42 SPACER (8.5mm) (16.5 + 8.5 + 12.5 + 11 + 6.5 = 55) (I can break the 8.5 down into (4 + 4 + 0.5) or (5 + 3 + 0.5) but both seem odd
   4. M42 ROTATOR (12.5mm)
   5. 11mm extender (11mm)
   6. Camera

If I opt for the M48 rotator, I have only 1 option and that is even worse:

1. it will come between the coma corrector and the 16.5mm extender and the 21mm extender will be replaced by some other extender. This option is bad as the M42 female thread on the rotator is only 5mm long whereas the male thread on the coma corrector is 6mm long. This means there will be a gap of (not exactly) 1mm in the assembly. So my spacings become:
   1. Coma corrector (male M48 6mm)
   2. Empty space (1mm approx)
   3. M48 ROTATOR (female M48 5mm) (12.5mm)
   4. 16.5mm M48-M42 extender (16.5mm)
   5. M42 SPACER (7.5mm) (1 + 12.5 + 16.5 + 7.5 + 11 + 6.5 = 55)
   6. 11mm extender (11mm)
   7. Camera

Does my "spacer math" check out? How do I go about solving this problem? I don't see anywhere outside this assembly where the rotator can go. On one side is the camera, while on the other side beyond the coma corrector, there is the focuser entrance. Also, the coma corrector simply slides into the focuser and I don't see how I can attach the rotator outside this assembly area.

I would love to hear the thoughts of you awesome people who might have the same combo as this (Coma Corrector + Rotator + ZWO ASI294MC Pro) and would love to see how you guys have approached the problem.

Finally, if having these weird spacers is the only way, which option should I go for? And given 8.5mm or 7.5mm of spacing, is there a preferred way of building this spacing (4 + 4 + 0.5) or (4 + 0.5 + 4) or (3 + 5 + 0.5) or (8 + 0.5)?

Thanks a lot!

Asim Sohail
Pakistan

7 minutes ago, Jiggy 67 said:

Telegizmos 365 covers are designed to protect from rain etc......and sun, they have an inner layer to protect from sun

Thank you so much for sharing this. I will try to order one for my scope asap. It looks really effective. I just hope they ship to Pakistan. 😃

1 minute ago, Jiggy 67 said:

Hence the reason I leave my gear out 😀

I wish I couldve done that. In Pakistan the sun is very hot I dont have anything to shade my telescope from the sun or rain. =(

3 minutes ago, r3i said:

Hi Asim,

If you're using EQMOD then it's easy to define custom park positions.  See this link: 

I'm not sure what is possible with a SynScan handset as I've never used my NEQ6 with anything other than EQMOD.

Edit: Jiggy's post above answers the SynScan solution.

Hi @r3i! This is a very interesting video! It looks quite simple. I even had a go at it just now with the ASCOM simulator and it works! I'll test it out with my actual gear the next time I go out and report back (which may be a couple of days as I managed to injure my spine just recently carrying my gear back and forth between my house and the observation deck on my roof every night =( ). Thanks for sharing this! 😃

3 minutes ago, Jiggy 67 said:

Synscan has three options to park:

home position 

current position 

last saved park position 

so you can slew the mount to your preferred position, select park scope and choose current position from the menu. For future sessions just pick last saved position and the mount will park there. 
Obviously if you’re gonna move the mount that ain’t gonna work

Hi @Jiggy 67! Thanks for the heads up! I'll look into it. Can you also advise if using the parking feature can help avoid the hassles of alignment? Up till now, I've always had to polar align and then align after setting the scope up. But if I make an observatory so that I don't have to tear down my setup after every night, can I somehow reuse the previous night's alignment? I know having a permanent setup will help me avoid the hassles of polar alignment. But what about star alignment?

Thanks!

Hi!

I am planning to construct a small roll-off roof observatory for my telescope rig. I've found that when parked in its default home position, the top end of the telescope is almost 6 feet above the floor. This means that:

1. My construction cost would be a bit high since my observatory would need to be at least 6 feet tall.
2. For some viewing angles (like when the OTA is near horizontal, the observatory walls and roof might block some areas of the sky.

However, I've seen some pictures on the internet where people have parked their scopes such that the RA axis is horizontally pointing to either East or West, and the Dec axis is also horizontally pointing to either North or South. This is great! It means that if I can park my scope in this position, my observatory would need to be only about 4 feet tall instead of six feet. It also means that once taken out of this parked position, almost all areas of the sky would be accessible to me.

The issue is that I'm not aware if it's possible to change the default parking position on the SkyWatcher NEQ6 Pro mount. I can manually slew the telescope to this horizontal parked position and then switch the mount off. However, this means that when powering the scope up the next time, I wouldn't be able to allow the scope to resume from its parked position.

Is there any way that I can change the default parking position for SkyWatcher NEQ6 Pro?

Thanks!

Asim Sohail

----------

EDIT: Here is how I connect my telescope to my PC. I use a Serial-2-USB cable to connect the hand controller to my PC. I set my hand controller to PC Direct mode and then use CDC and PHD to connect to the mount via ASCOM EQMOD. And I'm looking for a way to modify the default parking position so that whenever I want to park my mount via the hand controller or the EQMOD software interface, it should always park in the horizontal position (RA and Dec axis horizontal).

34 minutes ago, vlaiv said:

Ah yes - everything is fine with your flats - they calibrate out ok, except one thing - dust is no longer where it used to be

This reminds me of a quote I read somewhere around here: Dust never sleeps. It keeps shifting.

Hi @vlaiv

Thanks a million for clarifying it all to me. When I took the subs, I pointed the scope to the west and later when I took the calibration frames, I swung the scope 180 degs around to face a lit wall and take flats there. So yes, there is a possibility that any dust would have moved inside. I guess I've been fretting over this stupid issue for a week, wasting night after night, when the simple (correct) solution was to clean my optical train. 😃

BTW, I'm amazed and inspired by how much you know your stuff. And not just that but the science and reasoning behind it. Thank you so much for not just telling me what I did wrong but also explaining and showing exactly what I did wrong. Thank you so much once again. 😃

Hi @vlaiv,

Apologies for re-awakening a resolved thread, but I have some follow up issues I'd like to hear your thoughts about. My earlier issues of white-balanced BIAS frames has been resolved. However for the past few days, I have been frustrated by FLATS. No matter what I do, my flats are not calibrating my LIGHTS correctly. I've tried both DSS and PI. Both are resulting in horrific images.

I used ZWO ASI294MC Pro cooled down to 0C for all frames. The telescope is an 8" F5 Newtonian with a coma corrector and Optolong L-Pro filter threaded into the camera. The imaging train was not touched at all during any exposure. I shot:

1. LIGHT frames of length 300s.
2. Capped telescope and shot BIAS frames of length 0s.
3. Capped telescope and shot DARK frames of length 300s.
4. Covered telescope with white t-shirt, pointed at an evenly-lit wall and shot FLAT frames of length 4s to reach an ADU of 3,500, and of length 40s to reach an ADU of 30,000.
5. Capped telescope and shot DARK_FLAT frames of length 4s and 40s.

I've tried a number of different workflows, but as soon as I stretch the final stacked image, I see clear vignetting and dust motes on the image. Here are the different approaches I've tried:

---[ DSS ]---

1. Loaded LIGHT (300s), DARK (300s), FLAT (4s, DARK_FLAT (4s) and BIAS (0s).

2. Loaded LIGHT (300s), DARK (300s), FLAT (40s), DARK_FLAT (40s) and BIAS (0s).

3. Loaded LIGHT (300s) and FLAT (4s).

4. Loaded LIGHT (300s) and FLAT (40s).

---[ PI ]---

5.1. Integrated BIAS into MASTER_BIAS.
5.2. Calibrated DARK (300s) with MASTER_BIAS.
5.3. Integrated calibrated DARK (300s) into MASTER_DARK.
5.4. Calibrated DARK_FLAT (4s) with MASTER_BIAS.
5.5. Integrated calibrated DARK_FLAT (4s) into MASTER_DARK_FLAT.
5.6. Calibrated FLAT (4s) with MASTER_BIAS and MASTER_DARK_FLAT.
5.7. Integrated calibrated FLAT (4s) into MASTER_FLAT.
5.8. Calibrated LIGHT (300s) with MASTER_BIAS, MASTER_DARK and MASTER_FLAT.

6.1. Integrated BIAS into MASTER_BIAS.
6.2. Calibrated DARK (300s) with MASTER_BIAS.
6.3. Integrated calibrated DARK (300s) into MASTER_DARK.
6.4. Calibrated DARK_FLAT (40s) with MASTER_BIAS.
6.5. Integrated calibrated DARK_FLAT (40s) into MASTER_DARK_FLAT.
6.6. Calibrated FLAT (40s) with MASTER_BIAS and MASTER_DARK_FLAT.
6.7. Integrated calibrated FLAT (40s) into MASTER_FLAT.
6.8. Calibrated LIGHT (300s) with MASTER_BIAS, MASTER_DARK and MASTER_FLAT.

7.1. Integrated DARK (300s) into MASTER_DARK.
7.2. Integrated DARK_FLAT (4s) into MASTER_DARK_FLAT.
7.3. Integrated FLAT (4s) into MASTER_FLAT.
7.4. Integrated LIGHT (300s) into MASTER_LIGHT.
7.5. Used PixelMath to implement (LIGHT - DARK) / (FLAT - DARK_FLAT).

8.1. Integrated DARK (300s) into MASTER_DARK.
8.2. Integrated DARK_FLAT (4s) into MASTER_DARK_FLAT.
8.3. Integrated FLAT (4s) into MASTER_FLAT.
8.4. Integrated LIGHT (300s) into MASTER_LIGHT.
8.5. Used PixelMath to implement (LIGHT - DARK) - (FLAT - DARK_FLAT).

In each of these cases, I'm left with images that have over-corrected or under-corrected vignetting and dust-motes after stretching the final image. Can you help me figure out what exactly is going wrong with my setup? I can say for sure that till about a week ago, both DSS and PI (first workflows of each category) were working perfectly fine for me and I didn't even need to inspect the frames since there were no flaws in the final images. For reference, here is what I ended up about a week ago: M42 Orion and NGC2244 Rosette. PS. You helped me solve the WB issue after these images. So there is something clearly wrong with my approach all of a sudden. Or something is wrong with the camera. =/

M42_Light_300sec_frame1_0C_20200201_231925.fit Calibration_Bias_0sec_frame1_0C_20200202_012654.fit Calibration_Dark_3.9sec_frame1_0C_20200202_011756.fit Calibration_Dark_40sec_frame1_0C_20200202_011910.fit Calibration_Dark_300sec_frame1_0C_20200202_002537.fit Calibration_Flat_3.9sec_frame1_3C_20200202_010618.fit Calibration_Flat_40sec_frame1_1C_20200202_010725.fit

Hi Vlaiv, I did as you suggested (set both B/R to 50/50) and sure enough, the FITS has been tamed.. =P

THANK YOU SO MUCH for helping me figure this out!!! You have been a GREAT help! Keep rocking!

Asim

50 minutes ago, vlaiv said:

I think this solves the problem. You need to use ASCOM driver to do your captures.

Once you install that driver, you will have option in SGP to choose ASCOM driver and there you will be able to set gain and offset.

Hi Vlaiv, I tried installing the ASCOM driver for ZWO but it started giving me issues. Frequently, no image would be downloaded from the ASCOM driver. So I uninstalled the driver and reverted back to the native driver. I checked out the ASICAP app that I also use to test the camera's live view for focus and stuff and found that there INDEED is a hidden setting about WB for this camera. And as you said, its set to R(52) B(95). Now I can change these values and the image updates accordingly. The issue is, what values do I set it to? I've tried setting both to 95 and then both to 52 and some other values as well. The issue is that now the bayer pattern seen in bias is such that R and B are of equal intensities, but there's a difference between G and R/B channels, What values should I set it to to achieve no WB?

21 minutes ago, AngryDonkey said:

Hi Asim,

Sorry I'm not sure, I did the test with my AllSkEye software in which I've implemented the white balance controls of the native driver. In SGP I'm sure you can just select ASCOM camera and then choose the ASI camera from the ASCOM camera chooser panel (provided you did install the ZWO ASCOM driver).

I'll try this next. I'm pretty sure I haven't installed the ascom driver and only installed the core zwo driver from its website 

1 minute ago, AngryDonkey said:

Sorry I've not read through the entire thread yet but have you tried 'not' using bias frames at all? I don't own such a camera so not 100% sure but I think some people prefer not using bias frames due to the amp glow in some CMOS cameras. Instead they do flat frames, flat darks (to calibrate the flat frames) and darks. Might be worth a shot.

I can try that next. 🙂

13 minutes ago, AngryDonkey said:

Hello

The native ZWO driver has two properties for white balance: red (default 52) and blue (default 95) and as you say they are fixed values. The ASCOM driver does not have them and DOES NOT use the values from the native driver. I've just done two test shots, one with the native driver and one with ASCOM and the ASCOM one comes out totally green and the native one fairly balanced.

Mike

Hi Mike!

Can you please tell how I can try doing the same? How do I choose which driver to use? I use SGP and ASICAP and both I think use the native driver. But I don't understand where and how can I change the WB. Is there a manual you can point me towards?

Thanks!

Asim

1 hour ago, vlaiv said:

This part got me worried as well. I could not find any reference of WB in ASCOM drivers online. In fact, I found one discussion on ZWO user forum that talks about WB settings - and there Sam stated clearly that ASCOM drivers don't have this setting.

I can think of only one possibility for changed White Balance. Have you used SharpCap by any chance at any point? I suspect that there might be issue between native and ASCOM drivers for this camera model. In native drivers you can set WB and it is set to something like 50/100 and 90/100. I remember that later is for blue, and former is perhaps for red channel, but I'm not 100% sure on that one. Next thing that I read in the same post on ZWO forum is that once you set those WB values - they will not change.

Maybe if you set WB values in native driver and ASCOM driver somehow works with native driver to produce images - it is quite possible that ASCOM results are impacted by native driver and remembered WB settings.

This is of course just a theory - maybe even a bit far fetched - but that is only explanation I can offer on this.

Above is taken from internet - it shows sharpcap with ASI294 camera and relevant controls have been marked with arrow.

You can't check for negative values - as you'll never get negative values out of camera. You can only conclude that there is histogram clipping to the left - by examining pixel ADU values and looking at the histogram.

Here are values for subs you posted:

1) Gain 1 offset 0

It has 0 as min - this is very strange. I think it is again consequence of that white balance thing (I have no other explanation for it). All other ASI cameras that I've seen behave like this - if they have less than 16 bit ADC - all ADU pixel values that come from camera will be multiplied with either 4 or 16 - depends if camera is 14bit or 12bit. This is because 12/14bit values are stored within 16bit word in MSB (most significant bit) with LSBs being 0. That makes number values - multiplied by 4 (2^2 for 14bit camera) or 16 (2^4 for 12bit camera). I have never seen 0 as ADU value.

On my ASI178 which is 14bit - lowest number I've seen is 4. On my ASI1600 which is 12bit - lowest number I've seen is 16.

In any case - histogram shows that there is clipping to the left and this combination of offset and gain is not good.

2) Offset 10 and Gain 1:

This clearly shows that histogram is separated from left side and minimum number is 476. Next to it is max number - which is odd number - 1533. You can't have odd numbers if every value is multiplied with 4. Again this shows that values have been altered from default format.

Now important bit - I can't tell if histogram is ok or not as it has been white balanced. I suspect it is ok - but look how far right is peak for blue. It is not that far right because it has that much offset - it is that far right because it has been multiplied with some value - white balanced. What if it was too left before multiplication.

Offset 64 is way too high for this camera - no need to go that high. Offset 10 is quite ok.

Use Gain 120 and offset 10 and I think you will be ok.

Big question remains - have you used SharpCap and if maybe WB settings were changed from that software?

 

 

Hi Vlaiv,

Thanks for getting back so quickly! I haven't used SharpCap before but I just downloaded to check it out and sure enough it does show what you showed. White balance set to R(52) B(95). I've tried fiddling with it in hopes of resetting the WB by setting both R and B to the same values (52/52) but the bayer pattern still shows. I'll look around on the internet for ways of reliably resetting the WB of this camera. Never thought it could give me this much of a headache! =P 😃

Also, thanks for identifying suitable gain/offset values for my camera. I wouldn't have figured that out myself. But now I'm starting to know how. 😃 Thanks.

Also, are you using FitsExplorer to inspect the FIT files?

PS. The only software that have ever connected to this camera are 1. SGP, 2. ASICAP (the capture software for ZWO). None of these software have any controls for WB so I'm not sure what or who set it. It could have been set from factory even. But I'll look into how I can go about resetting the WB. And I totally get now what you mean by that blue could have been too far left before being multiplied.

Thanks again!

Asim

3 hours ago, vlaiv said:

Ok, here are my findings:

1. There is no light leak so you are ok with that.

What I suspect is going on with bayer pattern in the darks / bias subs is some sort of white balance in drivers. I'm not familiar with drivers of this particular camera, but if you turned on automatic white balance in drivers - you might want to turn that off.

I'm suspecting AWB because this camera is 14bit ADC camera - that means that all values in recorded raw sub should be divisible by 4 (16 bit total, 14 bit used - remaining two bits set to 0 - same as number being multiplied by 4). It is not case with your bias and dark files - there are odd values as well as even. This can happen only if values have been changed once they were read out of the camera - for example AWB process in drivers could explain that. AWB could also explain bayer patter. Since there is some offset to pixel value (pixels in bias are not 0, but rather positive value roughly equal for each pixel) - multiplying that with different factors for each color will create different values. Even values in bayer matrix show this could be so - since strongest is blue then red and green is the weakest. If you look at ASI294mc QE curves - it is other way around - green is strongest, red is second and blue is the weakest - which means that they have to be multiplied with certain factors to "even out" giving strengths of pixels in bias/dark that we see.

In any case - I would recommend turning off auto white balance in drivers. With that turned on, I can't judge if offset of 10 is good value because I can't see actual read out values of pixels but only WB corrected values.

Another thing - AWB should not mess up your calibration and everything should work fine.

2. Your subs indeed work fine. Here is comparison on one sub between proper calibration and raw sub without calibration:

This is the same sub - left has been calibrated by (ligth - avg_dark) / (avg_flat - avg_flat_dark) while right one is without calibration. Both subs were binned x8 to get enough SNR to show features of the image. As you can see - you get pretty decent sub with calibration - no vignetting and it looks clean in comparison to raw sub.

As you see - another confirmation that above is probably AWB, as that is not going to affect calibration, and indeed calibration works fine.

3. I would just recommend you in the future to use Gain 120, to turn off AWB and check if offset has good value - and continue taking nice images

HTH

Hi Vlaiv!

First of all, thanks a lot for that in depth insight into the world of CMOS cameras. Thank you for looking at my subs and I'm amazed how well you were able to use just three frames of each type. No doubt, I'll be going over your post for a few days trying to understand everything you've mentioned. 😃

At the same time, thanks for clarifying the purpose of gain and offset, and I think you've pointed me towards the issue. In SGP, when you connect your camera, you have the option of specifying camera gain/offset, which by default is 10, 10. For my last good set of subs, I set it to 120, 10 but this time I used the default 10, 10. I've experimented a bit more about these and here are my findings:

1. I have no idea how to control the WB of this camera. I haven't changed anything in its driver, and honestly, I haven't even seen any GUI for the driver that lets you control anything about the camera. Just that there was a driver available from ZWO site and I downloaded and installed it and that's it. I'll dig around on the internet about how to control its WB and fix it there. I'll report back when I've figured it out.

2. If I set gain/offset to 10/0 or 120/0 and then take bias subs of 0s, and stretch it, then I get no bayer pattern. The entire stretched image appears almost black with just a few pixels of various shades of gray scattered about. Which is understandable after having read your posts that since I'm not adding any offset, all values should be around 0. If I set the gain/offset to ?/1 or ?/10 or ?/64, immediately I get a bayer pattern. I've attached FIT files for all of these cases as well. I can see that as I increase the offset, my histogram starts moving to the right. However there are two distinct peaks in the histogram and that's probably due to the WB you've mentioned. 😃

3. As you pointed out in your post, that probably having a bayer pattern in bias/dark subs is not an issue, since this is an offset added to all frames (bias/flats/darks/lights) and if calibration is done properly, this signal should be removed. Probably what mattered with my setup was that earlier on I was taking subs at 120/10 gain/offset and was very pleased with the result and then all of a sudden, I forgot to change it from the default value of 10/10 and got such a low signal in my frames that I got freaked out. 😃 I'll try shooting all the frames again as soon as the sky clears up at 120/64 and this time I'll pay special attention to the values inside the calibration frames as well. Your post has been very very very helpful in allowing me to understand how these cameras work. Thank you so much for the time you took to answer these questions! This forum has never once disappointed me in the past 10 years or so, and it's cuz of people like yourself who are willing to make time to answer naive/dumb questions of people like myself. 😃

4. Can you tell me how you inspected the values inside these FIT files? How can I check that none of the values inside my bias frames are not negative and adjust the offset accordingly?

Thank you so much for your insights. 😃

Asim

FIT_Gain1_Offset0.fit FIT_Gain120_Offset64.fit FIT_Gain1_Offset10.fit FIT_Gain1_Offset64.fit