M 81 and M 82

[Stefan B]

Hi Dietmar,

AutoDev (redo global stretch)
As said, I think the most important point is to gain experience setting the right ROI. I often chose square shaped ROIs, but these rectangular shape like you did, may be better suited.

I think it's especially helpful with galaxies since you can focus on the dynamic range of interest by slicing the galaxy.
When processing frame filling nebulae I am always happy when I do not have to use a ROI at all. But your data has to be good then, since everything gets exposed...

Spatially Variant PSF Deconvolution
... It must be some kind of magic.

Definitely

Color
I noticed, that you set Cap Green to 100 % and Highlight Repair to 10 px, but with little (?) impact.

Mmhh...usually I do not use Highlight repair. Maybe I accidentally clicked while hovering over the slider?
The effect of Cap green might be barely visible especially when the color balance has already been okay. It might be more noticeable when using the MaxRGB view. If I remember correctly there were green dominant pixels in the galaxy core which is not plausible I guess. Thus I just capped green and the green dominant pixels went yellow. Probably not necessary...

Shrink
I never used this module before, but I surely will do that in future. Maybe cosmetic, but it really helps making the image looking more convenient.

It doesn't add much in images of regions like Ursa major since there aren't many stars anyway. But with nebulae within the milky way disc it makes a huge difference in my eyes when the star field is pushed back.

Super Structure
... It is important to use it with care, you did it by reducing the Strength parameter for 'DimSmall' and adjusting the Saturation parameter for the 'Saturate' run.

Yes, this is a pretty precise analysis ;

FilmDev
Have you noticed, that the image gets slightly darker, when the module it started, without setting Digitial Development or other parameters? I wonder why?

Maybe I noticed and forgot about...anyway, I don't remember Mike's explanation might apply... But to counteract this you might very carefully adjust the gamma slider.

With my next post, I would like to share my ASTAP stack and maybe you could take a look … but as said, only if you like ...

I would like to give it a try since I don't have new data of my own anyway

Regards
Stefan

[decay]

@Mike in Rancho thank you very much for your reply and your detailed remarks. My post was meant more as a monologue and as feedback for Stefan, but this was a nice surprise Much appreciated!
I will review your points one by one and then report back.

@Stefan B I did not intend for you to reply, but thank you once more! Some more valueable tips to consider

Best regards, Dietmar.

[decay]

Hi Stefan,

so here comes my ASTAP stack:

https://c.web.de/@334960167135216273/VW ... Uc3kpnN-wQ

First of all I have to mention, that my camera doesn’t seem to be supported. The resulting stack is green, not a little bit – I mean, _really_ green I had this problem with earlier versions of DSS as well, but it disappeared with version 4.2.6 - the underlying LIBRAW library was updated to snapshot 202101 with this release. I think both ASTAP and Siril use the stable (but older) version 0.20.2 instead. The cause for the green result is explained here (OK, this refers to the older DCRAW lib, but I guess, this is true for LIBRAW as well):

https://dechifro.org/dcraw/

“Why does dcraw output have a green tint and weak color?

Because dcraw doesn't have a color matrix for your camera model, it outputs raw color instead of sRGB.”

And … yes, there are obviously twice as many green pixels in this bayer matrix

Therefore I activated the “Auto levels” checkbox on the “Stack method” tab in the “stack menu” of ASTAP, contrary to the “Recommended ASTAP settings” for ST. The outcome seems to have a fairly reasonable colour balance, as far as I can judge.

The next problem, that drove me nuts : Where to put my bias frames? I did not take darks nor flat dark frames. It ended up putting the bias frames in both the “Darks” and the “Flat darks” tabs. And then, building the master flat, the flat darks disappeared from the list. Hmm … the resulting stack was not as flat as expected and in my desperation the next time after building the master flat I put the bias frames again into the “Flat darks” tab. Weird, but this obviously worked!

As I saw on AstroBin, you are taking flat dark frames (and no dark frames and no bias frames), right? Could you please tell me, where to put the flat dark frames? Certainly to the “Flat darks” tab, but what about the “Darks” tab? Do you leave it empty?

Could you please take a (short!) look at my ASTAP stack? What do you think about it, compared to the DSS stack?

Thank you very much!

Best regards, Dietmar.

P.S.: Next time I will post the Siril stack. For me, this could be the best result. I am curious about your findings!

[admin]

Therefore I activated the “Auto levels” checkbox on the “Stack method” tab in the “stack menu” of ASTAP, contrary to the “Recommended ASTAP settings” for ST. The outcome seems to have a fairly reasonable colour balance, as far as I can judge.

Never feed StarTools color balanced data! It means that the noise is no longer comparable between channels, and that any luminance derivative cannot be accurately weighed (weighting factors become unknown).

Always use the Color module for your color balancing, because this is designed to only affect color and not any luminance derivative. There is a good reason why StarTools processes luminance and color separately! FWIW, StarTools also comes equipped with most of DCRAW/LibRAW's matrices, if you are using a DSLR.

[decay]

Never feed StarTools color balanced data!

Ok, got it!
I know, you had a lot of effort to implement this fine design handling luminance and colour separately!

What I above wanted to point out, the stack looks like this:

green.png (52.81 KiB) Viewed 5105 times

Is it really OK to feed StarTools with such an imbalanced image? I wonder, if it is possible to create a reasonable luminance channel to work with up to the color module with green being twice as strong as red and blue?

Anyway, the color module does it’s job:

color-module.png (305.4 KiB) Viewed 5105 times

(As expected, green has to be reduced by two. And I noticed, that the Saturation Amount has to be pushed up quite high ...)

My camera is an EOS 2000D and it is unfortunately not listed in StarTools. I read somewhere that the sensor would be quite unusual for Canon cameras, reading out from bottom to top instead of the other way round and Bayer matrix would be unusual as well. That causes a lot of trouble and as said, only the latest _snapshot_ version (202101) of LibRAW solves this.

Best regards, Dietmar.

[Mike in Rancho]

Hi Dietmar!

I downloaded your ASTAP stack and will open it up and try it out a little later.

However, a few notes from just reading through your posts and some rudimentary research --

Yes you can put your Bias into both Darks and Dark Flats if you want to set up your calibration that way. Typically I think that is more of a Nikon (D5300 and up) technique, as Canons are better able to utilize real Darks, but the basic calibration formula should work. Though I am a bit confused by your description of a "second run" with the Bias reloaded into Dark Flats. AFAIK if the master flat is already created those ought to be ignored? But if not, the calibration would be incorrect as the flats would be double bias-subtracted. Hmmm.

If you want, take your time with ASTAP and just step through things manually, one-by-one. That'll help to learn it, and every bit of software has a learning curve. Even ST, which you know, is made for beginners.

If you load your dark flats and hit analyze you can see the statistics for each frame. Then, same with the flats. Then there's a button that says replace flats and dark flats with master flat. This happens automatically if you just load everything and hit stack (and that's why your files "disappeared.") Next, same thing with your darks (or whatever you loaded into the darks tab). Finally, lights can be so analyzed, and the stats reviewed to see if you want to cull any bad shots.

Do not worry about 2x G making your images green. They are averaged, not added. This improves the green SNR a bit, however, and that can be taken advantage of in Synth L creation. Ivo takes care of that math, of course, because he's Ivo! Just open or a proper OSC compose will do it. Anyway, the green cast typically found in OSC has more to do with the channel response of the sensor and bayer matrix, where green tends to be the strongest. You can see this if you look up a QE graph for your camera.

I am a bit confused by your equipment here. On page one, the link to your astrobin states you used a Canon 1100Da, so basically a T3, which is an older camera and I would presume fully supported. In fact the linked page states that it is. But, the FITS header in your ASTAP stack claims the camera is a 1500D (i.e. T7), which should also be fully supported (and says so on the list). There really shouldn't be a problem here, so I am a bit confused. If you want, go ahead and link a handful of subs of each type (light, flat, bias - whichever were used) and maybe we can check things out for you.

The FITS header also notes that the debayering pattern used was GBRG. Is that normal for you? Most cameras I am aware of use RGGB, especially common DSLRs, unless that needs to be switched up due to some kind of file or mirror flipping done in the acquisition stage. So, perhaps it is right, but just something to maybe double-check.

On a quick look at the stack, I think the auto-leveling you did may make it difficult to diagnose many things here (but I don't see any gridding or full color mismatches (usually purple) that are indicative of a bayer pattern error.

[Mike in Rancho]

Ah, just saw you post Dietmar, which must have come in while I was typing!

So now the camera is a 2000D (how many Canons do you have!?)...that may explain things?

Don't worry about the green -- it is entirely normal (unless something else went wrong - like camera settings that could be altering the RAW files?) and will be properly handled by Wipe (mandatory) and Color.

[decay]

Hi Mike!

wow! Don't know what to say. Thank you very much!
I will answer in detail tomorrow. Please do nothing until then

For now, just to clarify:

My camera is a 2000D. The 1100Da does belong to Stefan, as well as the AstroBin images. I probably will never be able to take such images I "hijacked" this thread from Stefan (sorry!), that was pretty stupid and is causing all this confusion. I will probably open a new topic tomorrow for further discussion. The ASTAP stack claims the camera would be a 1500D, I think, because ASTAP / LibRAW does not know about the "new" model 2000D. So, I only own one Canon camera - that's enough for me

Until tomorrow, Dietmar.

[Mike in Rancho]

D'oh!

Well that explains things then. I forgot the initial post was Stefan's. And as you say maybe the 2000D isn't supported within the raw reader being used, so called it a 1500.

Probably just a matter of not normalizing the channel levels then before getting to ST.

[Stefan B]

Hi Dietmar,

first things first:

Where to put my bias frames? I did not take darks nor flat dark frames. It ended up putting the bias frames in both the “Darks” and the “Flat darks” tabs. And then, building the master flat, the flat darks disappeared from the list. Hmm … the resulting stack was not as flat as expected and in my desperation the next time after building the master flat I put the bias frames again into the “Flat darks” tab. Weird, but this obviously worked!

As I saw on AstroBin, you are taking flat dark frames (and no dark frames and no bias frames), right? Could you please tell me, where to put the flat dark frames? Certainly to the “Flat darks” tab, but what about the “Darks” tab? Do you leave it empty?

I always use flat darks but when a software does not have a tab or something similar for them I use the software's corresponding Bias tab. The other way round should also work. Both flat darks and bias frames are for calibration of the flats (if you do not use any of them you'll probably get a master flat which leads to overcorrection, i.e. inverse vignetting/brighter instead of darker corners). And both do the job by subtracting the read noise/offset from the flats if I am not mistaken. Which one does a better job is a matter of debate and probably dependent on different factors like CMOS vs CCD but in my experience they do what they should do with my DSLR, no matter if bias or dark flat.

By the way, I use the flat darks as darks also. Of course they aren't exposed as long as the lights but I hope that thus I get rid of part of the fixed pattern noise.

I had a go at your ASTAP stack and this is the result:

m81_m82_astap.jpg (170.02 KiB) Viewed 5092 times

This is not scientific in any way since it was really a quick processing and I didn't focus on applying the same parameters than in the DSS processing. But I think it's comparable in some way. Have a look, e.g., at M 82:

M82 comparison.jpg (50.97 KiB) Viewed 5092 times

Not much difference in my world, which might show that the processing was pretty similar. Things change when looking at M 81:

M81 comparison.jpg (502.57 KiB) Viewed 5092 times

IMHO there are more details in the ASTAP version and the details visible in both renditions are more pronounced in the ASTAP version. I don't know the reason for this but it confirms my experience that I have a much easier time to get more and fainter details with ASTAP stacks than DSS stacks. This is even more true when processing faint nebulae.

What were your impression and results?

I "hijacked" this thread from Stefan (sorry!), that was pretty stupid and is causing all this confusion. I will probably open a new topic tomorrow for further discussion.

Don't worry, we can use this thread, no problem

Regards
Stefan