StarTools

Hi

Here is a crop from the galaxy centre when processed in StarTools. However I work it, I seem to get this pinkish annulus around the bright core.
Now my immediate reaction was that this is caused by the bright regions being saturated, but I don't think this is so as the very centre seems appropriately coloured. Furthermore, if I examine an individual sub, the brightest part of the core is not saturated. If I examine a tiff created from the DSS fits output file after stacking, this too is not saturated at the brightest part. If I use the Artistic (Detail Aware) rendition instead of the Scientific one, it appears to go, but as it's necessary to increase the saturation it then becomes visible again. I've tried all options for stacking in DSS, but the result is the same. Even if I knock back the core using HDR, it is still apparent.

Any idea as to what's going on, and how to avoid it please?

Ian

Hi Ian,

If i inspect the core with a dropper in The GIMP, it appears to me the coloring is close to balanced (but not quite!). Going by what we know about the core of galaxies similar to M31, we'd expect a yellowish core (less star formation and hence fewer blue giants and more older/redder stars). There is indeed a higher red value than blue for pixels in the core, but not a higher green value (red+green makes yellow, which is what we're after). Bumping up the green in the Color module and/or reducing blue should help.

(see here for more information about color balancing)

Do let me know if this helps.

Thanks for your reply Ivo, but I'm struggling with this. The issue for me is that it is such a stark annulus of magenta, trying to rid it by colour balancing ends up upsetting the overall colour balance. I guess that one could start masking but I can't help feeling that shouldn't be necessary. The fact that it is an annulus about the core, rather than all of the core, I find odd. All of which makes me wonder if there is something else going on?

I reprocessed in v1.4.324 using the log of my original processing in v1.3.5.289 (oh! I do wish this could be automated), and this is what I got by the straight application of the colour module after using HDR (though trying without the HDR step makes no difference)
Saving the image and checking the RGB values gives the following:
Clearly, the green component in the magenta region is too low. I realise that I'm not really significantly adding any more to my earlier post, except to say that I don't see how I can 'correct' the appearance of the annulus without messing up the rest of the image. Now I use the Fuji-X Trans sensor and this isn't a true Bayer array, so I'm always wary that there might be some unintended consequence of this. I have to pre-convert the RAFs to DNGs in Adobe DNG converter before using them in DSS. I am toying with using different stacking software which will read the RAFs directly. May be that will improve things, I don't know. What do you think?

Ian

Is there any chance you could post a crop of the linear version of the core?

RAW converters (such as dcraw) can deal with clipping channels differently. If one or more channels were clipping in the highlights in the linear data, then this can cause color skew, depending on how the data is clipped.
For example, from the dcraw manual; As the first step of color calibrating, StarTools Color module tries to recover color ratios from the linear data for every pixel (as - just like the objects in outer space - these should not change and are independent of brightness). It then uses these ratios as an input to calculate what colors to apply independent of how the data was stretched.

If some channels were clipping for some pixels, these color ratios will be off (one or more channels have indeterminate overflowing levels). ST tries to detect such clipping channels (e.g. it assume the scenario under dcraw's -H 0 parameter), but if something has made them no longer clip (e.g. they are no longer at unity such as under - H2 or -H 3), they will be treated as "complete" pixels that can be used to calculate ratios from.

This is the only scenario I can think of that would give you incorrect coloring in some parts of your image...

Hi Ivo,

I use DSS for stacking and I've currently a demo of AstroArt. I don't think I can use DSS to crop the fts, after the event, and AA demo doesn't allow me to save. So, I've opened the fts in StarTools v1.4, cropped it, and re-saved as a tiff. Is that adequate?

One small bug I've found with v1.4 running on W7 is that when you come to save a file, the drop-down box doesn't give you any save formats, and unless you include the extension in the file name it doesn't save anything.

I must admit that the magenta pink is very reminiscent of what some raw developers give when one or more channels is saturated, which is what initially prompted my concern. Both DSS and AA use DCRaw to decode the raws, and of course I've no way of knowing what setting for saturation is used. The as-stacked files with this camera do have a very strong red bias, and so I wouldn't have been surprised to find the red channel clipped. However, I've looked at the region in various ways and I've not come up with anything positive. So any pointers will be much appreciated.

A link to my One-drive is below.

Just to add, AA will read the Fuji RAFs properly, so there is no need to pre-convert to DNG. Even there, stacking the subs without any correction and splitting RGB channels, I can't find a saturated channel in the region.

Ian

https://1drv.ms/i/s!AvKIwoquJkPPgVSeG82hTLSUAwOV

I've now tried stacking with Astroart, with the same result.

Any ideas Ivo?

Ian

AA also uses dcraw internally (a lot of of software does).
Would you be able to upload one RAW sub?

admin wrote:AA also uses dcraw internally (a lot of of software does).

Indeed it does Ivo, as does Pixinsight (a working copy of which I no longer have). The only thing is that unlike AA and PI, DSS doesn't seem to work with Fuji RAFs, although it should, necessitating an additional step of converting all the RAFs to DNGs using the Adobe DNG converter. So, by using AA, I believe I've shown that the DNG converter isn't to blame.

As requested, I've uploaded a single RAW sub to:

https://1drv.ms/u/s!AvKIwoquJkPPgVXSNOVmrJCT_95M

Regards, Ian

Admiral wrote:

admin wrote:AA also uses dcraw internally (a lot of of software does).

Indeed it does Ivo, as does Pixinsight (a working copy of which I no longer have). The only thing is that unlike AA and PI, DSS doesn't seem to work with Fuji RAFs, although it should, necessitating an additional step of converting all the RAFs to DNGs using the Adobe DNG converter. So, by using AA, I believe I've shown that the DNG converter isn't to blame.

As requested, I've uploaded a single RAW sub to:

https://1drv.ms/u/s!AvKIwoquJkPPgVXSNOVmrJCT_95M

Regards, Ian

Hi Ian,

Sorry for the belated reply (the lead up to Christmas is a crazy time of year for the business I'm in...)

I had a look at the RAW file and converted it to TIFF using dcraw v9.19 (note that this is with color balancing done by dcraw, which is not recommended for best results, however it is closest to what DSS would do).
Specifically I used -T -4 as parameters.
The resulting single-sub TIFF does not yield the pink/magenta annulus that I can see;
Note that the above is the default that the Color module comes up with, except for boosting the Dark Saturation in an attempt to tease out any large area color anomalies.

I'm not sure at this stage what is causing your issue...

Thanks for taking the time out of your busy schedule for checking the sub for me Ivo. So if I understand correctly, what you are saying is that an individual sub doesn't appear to show any colour discrepancies, whereas the stacked image does?

For what it's worth I've attached a fits of a crop of the stacked core, using the stack made in AstroArt.

Obviously, if any other thoughts come to mind I'd be pleased to hear of them.

Best wishes for the New Year.

Regards
Ian