Enhancements to the Histogram Display - Incorporating 'Statistics' and LINEAR transformations

[Niall Saunders]

Hi All,

Here are a couple of 'wishes' that would have helped me over the last few weeks . . .

(A)
On the Histogram window, along the top edge of the display, present small markers (little 'upside down' triangles ??), perhaps with a 'dropped line' down on to the main histogram display.

Each of these markers (which could maybe have a mnemonic next to them ??) would represent the statistical summary analysis for the image in question.

In other words, a given image could have its MIN, AVG (i.e. MEAN), MED and MAX points shown by these 'markers' and 'drop=lines'. Perhaps even the STDEV could also be shown, by using more than one 'drop-line' for the likes of MED and AVG, for example.

This would certainly help in achieving basic colour balance, At the moment I tend to use a PixelMath statement such as
[  $T +(0.1 - med($T))  ]
to get my (single-modal) peaks lined up. Having the markers would just help me understand what was going on.

(B)
The second 'wish' involves the ability to apply LINEAR transforms to the image data. In other words, I would like to be able to 'shift' my histograms 'peaks' to the 'left' and 'right' WITHOUT having to invoke a Mid-Tones Transfer Function (MTF) - which is a NON-LINEAR translation.

Similarly, the ability to apply a (multiplicative) SCALE function would also be useful

I have been using the following PixelMath expression (for individual Rd, Gn and Bu channels) to help me both neutralise the background and the cores of galaxies, yet without causing any NON-linear transformation of the image data :-

Rd : (($T - med(bak)) * (mean(core[0]) / mean(core[0])) * 0.975) + 0.01
Gn : (($T - med(bak)) *  (mean(core[0]) / mean(core[1])) * 1.000) + 0.01
Bu : (($T - med(bak)) *  (mean(core[0]) / mean(core[2])) * 1.250) + 0.01

Where 'bak' is an image created by using Dynamic Crop to 'grab' a section of the image that is 'pure' background (and then dragging a copy to the Workspace, before using CTRL-Z to reinstate the original image), and where 'core' is a similarly created image, this time being an extraction of the galaxy core (the idea being that, on average, the galaxy core should be 'neutral white').

The three 'constant multipliers' just allow me to move things around, and the three constant 'additions' just keep the data away from the '0' point.

===========================

Is there any mileage in these thoughts of mine, or am I missing some non-trivial point ?

Cheers,

[Juan Conejero]

Hi Niall,

Interesting questions and suggestions.

In other words, a given image could have its MIN, AVG (i.e. MEAN), MED and MAX points shown by these 'markers' and 'drop=lines'. Perhaps even the STDEV could also be shown, by using more than one 'drop-line' for the likes of MED and AVG, for example.

Yes, of course this is an excellent idea. I've been thinking on something similar since some time ago. The only problem is that the HistogramTransformation interface is quite complex indeed, and adding this feature requires some refactoring. Not a high priority, but you can count with this being implemented in some 1.5.x.

Code: [Select]

$T +(0.1 - med($T))

I assume you apply this expression with rescaling disabled --or the pedestal would be useless. Perhaps by adding a 0.1 pedestal you're losing too much dynamic range. By adding 0.1 to all pixels you are in the risk of saturating star cores and other very bright features. If you apply the expression above to a linear image, your median will probably be much less than 0.1, and you may safely use something like:

Code: [Select]

$T - Med($T) + 0.005

If you can afford rescaling, then a pedestal isn't necessary and you can just apply:

Code: [Select]

$T - Med($T)

with rescaling enabled. Of course rescaling is a linear operation. No data are lost because PixelMath stores all intermediate results using the full range of float (double if the "Use 64-bit working images" option is selected), and rescaling is carried out at the very end of the process.

The second 'wish' involves the ability to apply LINEAR transforms to the image data. In other words, I would like to be able to 'shift' my histograms 'peaks' to the 'left' and 'right' WITHOUT having to invoke a Mid-Tones Transfer Function (MTF) - which is a NON-LINEAR translation.

The best and more accurate way to apply these transformations is using PixelMath, just as you're doing.

Rd : (($T - med(bak)) * (mean(core[0]) / mean(core[0])) * 0.975) + 0.01
Gn : (($T - med(bak)) * (mean(core[0]) / mean(core[1])) * 1.000) + 0.01
Bu : (($T - med(bak)) * (mean(core[0]) / mean(core[2])) * 1.250) + 0.01

This seems basically correct. However if you sample the galaxy well, you shouldn't need the three multiplicative constants. These constants make this technique nonanalytic, which is contrary to its main principle

My recommendation is to include more than just the galaxy cores. If you're applying the integrated galaxy light as your reference white --which is IMO an excellent color balancing technique--, then I think you should include more stellar populations, which requires extending the galaxy probe to include spiral arms, and probably the outer halo as well. This is what has given us the best results. The fact that you are sampling just the core might explain why you need to apply an increasing factor to the blue channel.

Where 'bak' is an image created by using Dynamic Crop to 'grab' a section of the image that is 'pure' background (and then dragging a copy to the Workspace, before using CTRL-Z to reinstate the original image)

You don't need DynamicCrop / Ctrl+Z. Just define a preview comprising your region of interest, and make an image from it (by dragging its view selector, or by selecting Preview > Make Image).

You're getting into the kind of image processing PixInsight is intended for. This is the PixInsight way, and I'm glad to know you're acquainting with it so well

[Niall Saunders]

Hi Juan,

Yes - I have been using the 'pedestal' purely to allow me to move data around to suit. I showed the PixMath expressions 'as is' , having copied and pasted from one of my earliest PSM files.

The same applies to the three 'multiplicative constants' - normally I have them set to '1.0' - but I pasted a version to show that the three colours 'could' be shifted 'sideways'.

The reason for asking for 'linear' transformations within the Histogram window was to allow the otherwise 'cumbersome' PixMath process to be 'simplifed' - almost by using 'sliders' within the Histogram window.

After all, most users are probably trying to 'colour balance' by using a combination of clipping shadows and applying an MTF.

Which is fine if they are willing to apply a non-linear transformation at that stage of their processing.

I realised that, naturally, the MTF was affecting the 'width' of my histogram 'peak', and just wasn't happy with that idea.

In other words, I would prefer to be able to hold off the transition to a non-linear image until AFTER all the processes I might wish to apply (deconvolution, etc.) have been performed. Yet, at the same time, it can be advantageous to be working with an image, right from the outset, that is - more or less - colour balanced, thus giving you a 'better feel' for the results of early processing stages.

I accept what you said about the fact that your Histogram interface already being highly complex - but, at the same time, I know that YOU (like me) also like a challenge  

Cheers,