PDA

View Full Version here: : ASI462 MC Color Balance


multiweb
12-10-2020, 08:33 PM
I'm struggling with the color balance with that camera. I don't know if I should use longer exposures or if my gain is too high. When I do an auto colour on the histogram I almost get a monochrome picture. Here's an example on Mars.

Sunfish
12-10-2020, 08:56 PM
Not sure about that camera or method. The recommendation on EAA live stacking with my ASI183mc is to manually set the histogram peaks . Seems to be be all wrong in auto in some settings but ok in others.

Camelopardalis
12-10-2020, 08:58 PM
Marc, I find that Jupiter gives a much better guide to a more natural colour balance, so you can port the settings you use for Jupiter over to Mars.

I prefer to capture using image settings 50:50:50 (R:G:B) and colour balance in processing, but I did experiment with getting natural colour out of the camera and it was approx. 64:50:93

FWIW your gain looks fine, those histograms look well exposed to me :thumbsup:

multiweb
12-10-2020, 09:03 PM
I think I know what I did wrong... The SER files are RGB. Somehow when I switched to FireCapture from Sharpcap it started recording in RGB. I must have stuffed the settings. Problem is between the keyboard and the chair :rolleyes:

mswhin63
13-10-2020, 10:50 PM
I always struggled with colour setting, it is possible that your first image maybe OK, just increase the saturation. Not sure it will work but worth a try.

multiweb
14-10-2020, 02:47 PM
Thanks for the feedback guys.
Here's a funny one I've just noticed in Registax 6.

There is a significant difference if you strecth the histogram levels before or after doing an automatic color balance. So it might be better to do the color balance before playing with the levels/blackpoint.

Maybe somebody can chime in and explain why. :question:

Then again is Saturn yellowish including rings or blueish with more color variations as in the right?

Camelopardalis
14-10-2020, 05:39 PM
I think the one on the right is closer. If you bump the saturation a bit the planet should go a bit sandy coloured with a dash or reds/browns.

I’ve read that the rings are slightly off-white because of dust particles tainting the ice, with the outer rings being whiter because they’re younger and less “dirty” :shrug:

multiweb
14-10-2020, 05:57 PM
I'm trying different things for the colors, zeroing in on a routine and taking notes. It's going to be different for each planet and also dependent on the number of usable frames I have collected. Once I have the camera settings downpat I should get some kind of repeatability in the results as well.

Tulloch
14-10-2020, 10:17 PM
Hi Marc, based on a previous colour balance test on Jupiter, I reckon the white balance values to use (in Firecapture) are Wred=69, Wblue=86.
https://www.cloudynights.com/topic/719778-some-musings-images-on-the-asi462mcs-noise-etc/?p=10376048

Also, you can't use Registax to "auto-balance" predominantly single colour planets like Mars, Uranus and Neptune (and probably Saturn), as it tries to equalise the colour channels (which these planets are not). Jupiter works pretty well.

Saturn has a yellow hue - we might try to "correct" it out to make a nicer looking image, but it's yellowish/green in real life.
https://solarsystem.nasa.gov/resources/17504/saturn-approaching-northern-summer/
https://www.cloudynights.com/topic/728631-accurate-colour-planet-images-the-final-report/

Andrew

multiweb
15-10-2020, 08:37 AM
Thanks for that Andrew. I also took note of the colors of Mars in the other thread and catching up on all your posts on CN. A treasure trove of good info. Kudos to you. :thumbsup:

Camelopardalis
15-10-2020, 10:27 AM
Yeah it's hard to know what's right, as you see so many different renditions.

The thing to take care with the nasa imagery is that their filters may have different bandpass to ours.

On top of that, our atmosphere creates a perception too...

multiweb
15-10-2020, 10:52 AM
I guess in the end if you have a color palette that approximates the real thing while still having a clear separation between features, clouds, etc... then you win.

Tulloch
15-10-2020, 10:58 AM
Absolutely, fully agree there. The Cassini filters are similar to ours (you can read about them in the link below, Fig 20), Hubble's are not.
https://www.researchgate.net/profile/Anthony_Delgenio/publication/227260429_Cassini_Imaging_Science_I nstrument_Characteristics_And_Antic ipated_Scientific_Investigations_At _Saturn/links/0c96052938da395850000000/Cassini-Imaging-Science-Instrument-Characteristics-And-Anticipated-Scientific-Investigations-At-Saturn.pdf

The atmosphere will also remove some of the blue from the planets, especially at lower elevations.
https://www.cloudynights.com/topic/727994-saturn-at-30-to-73-degrees-elevation/

Andrew

Camelopardalis
16-10-2020, 07:51 PM
Yeah the subtle blue in the Martian clouds could get a little challenging for the next few years :sadeyes:

Ittaku
12-11-2020, 08:06 AM
What was your final verdict on colour? I recently picked up the QHY version of this sensor and am curious too. Using the below graph the sensitivities in each colour translate to 1:1.23:1:28 but that's at wild odds from what's been recommended here, so obviously that's not how it works. Also firecapture 2.7β is giving me 0-255 ranges instead of 0-100. The manual says you have to white balance it but only gives example numbers without saying if that's a recommendation, citing 161:128:255, which should like the ballpark ratios more in line with what I'd expect based on other camera usage. Poor English in the rest of the manual makes it hard to understand just wtf they mean about biasing colour.

https://www.qhyccd.com/uploadfile/2020/0620/20200620050933812.png

https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=30&id=316


I'm having all sorts of other troubles with capturing in firecapture on linux, but that's another story, and almost certainly related to it being the QHY camera...

multiweb
12-11-2020, 11:40 AM
Good day Con, still getting some data on this. I used the settings in FC beta that Andrew recommended. Wred 68 and Wblue 86. Using a UV/IR cut made a big difference on Mars. Jupiter is easier to color balance.

I also started using the camera for deep sky at 1:1:1 in Nebulosity.

I measured the int mode in CCD Stack and after doing a quick pixel map ended up with those ratios:

Red: 1:00
Green: 0.98
Blue: 1.27

I have to get a wider FOV as this is far too close to get a background readout so I will try with the FSQ later on which gives me a nice field and an image scale close to 1asp.

Ittaku
12-11-2020, 12:26 PM
Thanks Marc. I wouldn't dream of using this without an IR filter as all channels would always be washed out with IR signal and effectively black and white in that range which it's more sensitive to than the visible range. That's why it's always sold with filters by QHY for example.

multiweb
12-11-2020, 02:12 PM
Here's an RGB and an IR/LUM blend. Response of the camera in IR is certainly a lot better than my QHY9. These are 12x5min in IR and 27x2min in color. It would have taken me a lot more integration time to get the noise down. Although it's perfect for planetary the pixel size and the field are too small for that FL (~2.6m) but on my FSQ at prime I should get an image scale of ~1asp and a really nice field, not too tight, not too wide. That will be my next test.

Ittaku
12-11-2020, 02:39 PM
Meanwhile the QHY linux sdk for the 462c is rather flaky and errors out madly with firecapture so I can't really use it to its full capability, but the QHY dev has said they're looking into it. Considering QHY normally charge more for their hardware than ZWO, I find ZWO's software side far more mature by comparison.

Tulloch
12-11-2020, 07:38 PM
Hi Con, as far as I know, FC treats ASI and QHY cameras differently due to the driver file it comes with. On ASI cameras you only get to choose Wred and Wblue, but in FC 2.7 Torsten added a Wgreen "offset" as a multiplier. Whereas (I believe) QHY allows you to set a value for all 3 colour parameters, which can be varied between 1 and 127 with a midpoint of 64. This is just my best guess, based on what I've seen on CN.

So, assuming that the ASI462MC's values are Wred=69 and Wblue=86 with the Wgreen offset of 0, then the QHY462 values might be
Wred = 88
Wgreen = 64
Wblue = 110

Torsten replied to this assumption of mine here
https://www.cloudynights.com/topic/735503-overexposing-with-autohisto-set-and-other-issues-with-jupiter/?p=10595485

Hope this helps, unfortunately I cannot help with your Linux issues though ...

Andrew

Ittaku
12-11-2020, 08:09 PM
Hi Andrew. The camera is working somewhat and it has sliders that go up to 255 for all three colours. My issue are clearly timing overruns due to a broken SDK they distribute with linux for what it's worth - the QHY dev himself said he'd look into it. As for the green offset when there is no real green control for ZWO cameras, I found that a risky thing to use - the reason is it offsets what it's getting but can't prevent clipping. So if you set it to say -30 you could easily be clipping but it only showing 70 maximum value - I've seen the huge spike at the right end of the green histogram when you do that. Positive offset is okay but I found that's rarely required with green in particular. I'm hoping the true fine grained control of each colour in the QHY camera comes in useful.

Tulloch
12-11-2020, 08:25 PM
Yep, I've never used the green offset on my ASI224MC, even though I'm probably the reason why it's there. When I was trying to achieve "correct" colour balance (whatever that is :)), I found that I couldn't get the Wblue value high enough, so ended up setting Wblue to 99 and adding a 1.1 multiplier in Registax to the blue channel. I believe that the Wgreen value in FC 2.7b modifies the green channel so that the blue level could be higher by comparison.

Since I don't have a QHY camera, I don't know how FC balances the colours using the W values - I had seen in another post on CN there the "default" values for the QHY cameras was 64,64,64 which I assumed was the halfway point for 0-127. I reckon the ratios from above are correct (or at least close), but I don't know what actual values you need - might be a case of trial and error?

Ittaku
12-11-2020, 08:28 PM
It's okay, based on the manual I should be running blue at 255 and scale everything down from there... if and when the skies clear up and this stupid SDK bug is fixed. I see no sign of hidden clipping occurring with green when experimenting at home with daylight objects which is reassuring!

Ittaku
12-11-2020, 08:43 PM
Here's something that demonstrates the problem with green offset being negative without true green control. This is looking at a bright green card. The colour values aren't equivalent so ignore the histogram peak discrepancies. First is with ZWO green offset to very negative. Second is with QHY and the green set so low that it registers only about as much as the blue channel, yet it's still a smooth graph without the abrupt cut off. I picked this up the hard way on the ZWO the first time with a whole lot of stuffed Mars captures.

multiweb
12-11-2020, 10:08 PM
Another thing I have noticed is that the 462MC will not connect to Neb 4 with the native drivers. Only ASCOM. No such issue with 120MM which connects fine both ways.

Tulloch
13-11-2020, 09:14 AM
Not knowing exactly how you tested this it's difficult to comment, but I would have expected that the green signal would be very high if your were imaging a bright green card. However, it appears to me that the gain on the ZWO ASI224 is set too high if you are seeing clipping in the green, and no amount of offset in FC can fix this. A better test would be a colour checker chart (if you have one) or a colourful shirt (even the old ABC test pattern :)).
https://www.redbubble.com/i/sticker/Test-Pattern-Shirt-by-RatRock/23011194.EHVJB

Ittaku
13-11-2020, 09:17 AM
I guess you missed the point then? That's exactly what I'm trying to say, the offset can make you set the gain too high if you try to compensate for there not being enough blue. The offset is entirely artificial and green is maxing out at 82%. To me that means the whole negative offset feature is useless.

Tulloch
13-11-2020, 10:39 AM
Oh sorry, I did miss the point :)

My understanding of the offset is to help get a correct white balance direct from the camera during imaging, similar to the way commercial digital cameras have a "white balance" feature. The issue with the ASI224MC in particular is that the sensitivity in the blue region is too low, even with the offset set to 99, I find I still have to increase the blue level in post processing to get the colours to look "correct". In the ZWO cameras, there is no ability to set a "Wgreen" in the driver, the blue and red levels are set relative to the green level. I believe that what the Wgreen offset in FC does is perform a software reduction in the green channel, so that the red/green and blue/green ratios can be increased (above 99/50) because now the ratio is (say) 99/45 so the blue cannel is effectively higher straight out of the camera.

With the QHY cameras, all three colour components can be set individually so the white balance setting is slightly easier.

Ittaku
13-11-2020, 10:41 AM
Yep, you've just described one of the reasons I bought a QHY camera.

Tulloch
13-11-2020, 11:20 AM
Interestingly, the 462 doesn't need any Wgreen adjustments, the ASI462MC's values are Wred=69 and Wblue=86.

Nikolas
14-11-2020, 10:58 AM
Are you using an ircut filter? I found the ircut filter when used with my 224 mc sorted out a lot of the colour balance issues, especially for planetary and some deep sky

multiweb
19-11-2020, 10:19 AM
Good day Nik, yeah definitely use an UV/IR cut when doing straight RGB. Only in IR do I equalize all channels visually then work out the gain not to saturate anything.

multiweb
11-12-2020, 01:33 PM
I did some IR on the flame the other night then slew to the horse head. The SNR was so bad on the HH that I didn't get much at all even after 12x900s.

These are 15x600s with an FSQ106N at 540mm FL. So it is a fast scope. Captured in Neb4. The camera is very noisy for long exposures as it is uncooled. I don't think if it's practical to do IR with it. Lot of walking noise as in uncooled DSLRs. Ambient temperature was around 19c. Camera temp as registered in ASCOM was 29c. Maybe if they do a cooled version of that SONY sensor one day it will be a viable IR camera.

The crop is stacked as is.

The full field was calibrated with darks which helped with walking noise mostly due to hot pixels.

Camelopardalis
11-12-2020, 02:25 PM
Nice effort Marc :thumbsup:

QHY have produced a 4K version of the 462 (which is basically 1080p), so 4x the area but basically the same technology and, presumably, characteristics.

That'd probably be an interesting candidate for cooling too.

My suspicion is that the camera makers are more interested in selling us their larger chipped cooled cameras with greater margins...