StarTools

AT130EDT at f/7. Went with 90s subs, but I'm having trouble keeping M81's core under control.
Tried various ways to control the stretch in Optidev. Here, the RoI was M82. That seems better at keeping the M81 core from having a sharply defined, unnatural-looking disk.

Bin50
Crop
Wipe 90
Contrast default
HDR Highlights 1.08, both Details Boost at 40%
SVD
Color Artistic/Detail Aware, jacked up Blue and Dark Sat to make the arms purty
SS dim small at 50% just to get rid of the blue background cast caused by abusing the Color module
NR

Anyway - unsure if I am OK or if I should start over with 60s subs.

Really rather impressive detail in both galaxies for 3 hours. And a little Holmberg action too.

Color balance looks appropriate to good (so I think) versions I've seen.

What did things look like with an M81 ROI?

Here I don't find stuff looking too bad in the core. Maybe some artifact clean up. I suppose I would de-ring that little black (brown) eye in there. And if you feel it's still too powerful a very slight kernel blur in Layer can soften it, as an aesthetic change. It does not appear to be maxed out and oversaturated though.

I dug up my M81-82 from last year and composed that, just the LRGB 4 hours, no Ha for this test. Ugh, all my stars are triangles, so clearly I had some pinching issues at the time. Guess I need a new M81!

The orientations matched well (so I figure 0 or 90, my standard go-tos) so I cropped to the same FOV and also ran a 50bin and 90wipe. I seemed to get the opposite of what you describe in OptiDev, though. An M82 ROI makes a mess of the M81 core. I think you need that core brightness within the ROI, or at least grab a very bright star in there. Or jack up the outside-ROI contribution percentage. If using a ROI around M81, perhaps expand it to include one of the bright stars off to the right, to see if that helps tame the core.

Contrast default can also brighten up the M81 core, in case you were running into that as a problem. Tough call there though. Dropping the locality keeps it tamer, but bumping locality helps carve the swirling dust lanes better.

Hmm. I don't think I'm seeing anything here in the stars or M81 that would make me think 90s subs are a problem.

For comparison, though I think I have more LP for the extended objects, I would probably use 20s L and 60s RGB, at f/3.8. This also makes me think you are safe at 90s exposure at f/7.0 and through a Bayer grid.

I started with the M81 core in the RoI, of course. Kept getting what looked like a solid white pill, pretty sharply demarcated from the near-core. Went back and tried again with a core-RoI and found it less objectionable. Maybe I'm just getting used to the look of it. Not going to spend any more time trying to perfect the 3-hour stack. I'm bored, but not that bored

In unfortunate news - I was bored enough to go back to try dss Bayer drizzle again on my full 9 hours of the Deer Lick Group, only to get stopped in my tracks. I had ruthlessly purged my individual flat subs, keeping only the master flats. Discovered the hard way that dss won't use the master stack from Siril. Complains that "The checked pictures are not compatible". I'll remember that going forward - but that means I won't be able to use any of my existing M81 or M1 subs with dss, either.

Hi Ron,

not much to add to Mike’s remarks, as most times .

Maybe just that I would suggest to check one of your subs, whether the core of M81 is saturated, or not. That should be a fast, easy and reliable approach, I guess

I too don’t think that it is saturated.
I too like the colour balance – well done!

This galaxy pair is subject of the ST documentation. As already discussed above, M81 is the brighter object and should therefore be part of the ROI:

https://www.startools.org/modules/autodev

Other renditions often show an enlarged bright core without any details. Maybe the disc/pill like looking core is just a result of ST’s superior capabilities to reveal detail in this bright part?

This other question is, whether that ‘star’ or ‘eye’ (see Mike’s comment above) that shows up in the inner core is an artifact of processing. I would assume, that this is the case and that it should/could be mitigated using masks. Hopefully.

You also may want to have a look at Stefan’s great image of M81/82:
viewtopic.php?f=11&t=2539

Quite nice, your 3 hour stack. Why not work it out?

Best regards, Dietmar.

dx_ron wrote: ↑Tue Dec 26, 2023 3:38 pm Discovered the hard way that dss won't use the master stack from Siril. Complains that "The checked pictures are not compatible".

Too bad . I also discovered this some time ago and I remember being quite frustrated. I tried to convert the master flat using Gimp and some other tools into a format which is accepted by DSS. If I remember correctly, I succeeded that far, that DSS did not complain any longer. But I’m not sure, if that master flat worked correctly.

But maybe it’s worth a try, anyway.

decay wrote: ↑Tue Dec 26, 2023 6:38 pm

dx_ron wrote: ↑Tue Dec 26, 2023 3:38 pm Discovered the hard way that dss won't use the master stack from Siril. Complains that "The checked pictures are not compatible".

Too bad . I also discovered this some time ago and I remember being quite frustrated. I tried to convert the master flat using Gimp and some other tools into a format which is accepted by DSS. If I remember correctly, I succeeded that far, that DSS did not complain any longer. But I’m not sure, if that master flat worked correctly.

But maybe it’s worth a try, anyway.

It might help if I understood exactly what dss thinks is wrong. I tried opening the master flat .fit in Gimp, then exporting as a tiff. Tried a few variations of answers in the opening and saving dialogs, but no luck.

dx_ron wrote: ↑Tue Dec 26, 2023 7:34 pm

decay wrote: ↑Tue Dec 26, 2023 6:38 pm

dx_ron wrote: ↑Tue Dec 26, 2023 3:38 pm Discovered the hard way that dss won't use the master stack from Siril. Complains that "The checked pictures are not compatible".

Too bad . I also discovered this some time ago and I remember being quite frustrated. I tried to convert the master flat using Gimp and some other tools into a format which is accepted by DSS. If I remember correctly, I succeeded that far, that DSS did not complain any longer. But I’m not sure, if that master flat worked correctly.

But maybe it’s worth a try, anyway.

It might help if I understood exactly what dss thinks is wrong. I tried opening the master flat .fit in Gimp, then exporting as a tiff. Tried a few variations of answers in the opening and saving dialogs, but no luck.

Wait! I was thinking is was some subtle, complicated to fix thing. Then I remembered that the master is 32-bit fp. I re-saved it in Siril as 16-bit unsigned and dss appears happy.

Now to find out if shrinking it down to 16-bit mucks with calibration.

First step done ... Let us know, how you get on. Good luck!