After doing Luminance levels transform the image is monochrome

[Nocturnal]

Hi,

I trying to follow the Zone System with my processing. The ZS uses Photo Shop so I'm translating the techniques into PI as I go. One thing is that the PS histogram is a luminance transform rather than the default RGB /K that PI uses. So I switched to L mode, turned on L readout in the options and entered points in the histogram based on the zones. When I hit apply however the whole image is now monochrome (I started with a color image). Why is this? Shouldn't an L transform simply shift brightnesses around without changing colors? I'll revert to RGB/K for now but I'd like to understand this better.

In a related note, is there a way to move a screen value straight into the curves dialog? That's what Photo Shop does and it seems like a good feature. Sort of like a 'sampler' or 'dropper' function.

[Juan Conejero]

Hi Sander,

Let's see first if I understand your questions.

I switched to L mode

From this I assume that you selected the luminance (CIE L*) display component (Image > Display > Luminance, or Ctrl+Shift+L). In this mode you have a grayscale rendition of the CIE L* component on the screen. Obviously you cannot see any color in this display mode.

turned on L readout in the options and entered points in the histogram based on the zones

So you set the shadows clipping, highlights clipping (heaven forbids), and midtones balance points based on direct readings on the image. If this is true, let me say that IMHO this is, in general, a wrong procedure. In general:

- The shadows clipping point must be accurately adjusted so that no significant data are clipped. The optimum clipping point is different for each image, and depends basically on statistical properties. The histogram functions (their shapes and relative positions), along with the statistics of the image, give you all the necessary information. Experience and knowledge of the subsequent processing steps are also good allies.

- The midtones balance point applies a nonlinear transformation. It must be applied only when you no longer need/want a linear distribution of brightness. This is the only "creative part" of a histogram adjustment.

- The highlights clipping point is the easiest part: never touch it. The *only* exception is when you know that there is a contiguous unused part of the histogram at the highlights end, which of course doesn't happen in a deep sky image containing at least one star.

When I hit apply however the whole image is now monochrome (I started with a color image)

This cannot happen --or I am missing something very important here; in such case, please correct me. The image will remain RGB color because HistogramTransform doesn't (cannot) change the color space of its target image.

Image display modes simply change the way images are represented on the screen. They don't "select" any image channels or components, and of course they don't change image data at all. When you visualize the CIE L* component, for example, PixInsight calculates the luminance of each pixel on the fly, then it converts the resulting luminance values to 8-bit grayscale values and sends them to the screen. This process is completely transparent to all processes and processing tools.

PixInsight and Photoshop are based on completely different paradigms (opposite paradigms, in fact, in most cases). While Photoshop is a document-centric application, PixInsight is a radically object-oriented environment. This means that in PixInsight processes and data (images) are isolated (processes don't depend on images, and vice-versa) and encapsulated (a process is a self-contained, independent entity). This is true from the innermost core of the platform to the outermost layers, including the whole graphical user interface. This is a fundamental design principle, and it's what makes PixInsight quite different from other imaging applications (and more powerful and versatile, too).

So you cannot expect a given tool to modify its operation or performance based on the current display mode of its target image.

In a related note, is there a way to move a screen value straight into the curves dialog? That's what Photo Shop does and it seems like a good feature. Sort of like a 'sampler' or 'dropper' function.

When you click (and optionally drag) on any view in readout mode (Image > Mode > Readout, Alt+R), image readouts are sent to all processing interfaces that declare themselves as readout clients. HistogramTransform and CurvesTransform are two readout clients. Both interfaces will show vertical lines corresponding to the current readout values. You can control generation of readout values with the ReadoutOptions global process (Edit > Readout Options), and also with a specific menu available by clicking the small blue arrow on the readout tool bar (bottom side of the main window).

The HistogramTransform interface also allows you to select four readout modes: normal mode (only display readout values; this is the default), black point mode, midtones mode, and white point mode. The last three modes set the shadows clipping point, midtones balance and highlights clipping point dynamically as readout values are being generated. In general, I don't recommend using these features with astronomical images.

One thing is that the PS histogram is a luminance transform rather than the default RGB /K that PI uses

I assume that you are referring to the HistogramTransform interface. A histogram is a direct representation of actual image data and as such, HistogramTransform shows you the true histograms of the R, G, B and alpha channels. If you want to see the histogram of the CIE L* component (luminance), then extract it as an independent image and select it on HistogramTransform.

If you refer to curves, we have much more components available than PS has. CurvesTransform includes a specific CIE L* curve, among others.

As a side note, PS and PI use different nonlinear histogram transformations. PS applies a gamma function (the raise function), while the midtones transfer function that PI implements is a rational interpolation. Rational interpolation is much more flexible and accurate than a gamma function. I can elaborate more on this if you want.

I trying to follow the Zone System with my processing

The zone system is based on sound principles (the relationship between signal-to-noise ratio and brightness as a base for filtering image processing techniques and procedures) that can teach you good practices and a basically correct way of doing things.

However, as happens with all processing methodologies, my advice is: learn the important and good things that the zone system has, then don't follow it. Image processing (signal processing in general) is a vast and wild territory. Following a methodology, especially when it is strongly biased toward a particular implementation and based on simple techniques, can easily limit you more than help you. These are my 0.02 euros for today

[Nocturnal]

Juan,

I understand the difference between the display method and the 'color' setting for a process. When I have some time I'll record a movie to show you what I did.

[Elle]

Hi, Juan Conejero,

I would very much like to understand what the quote below means:

"As a side note, PS and PI use different nonlinear histogram transformations. PS applies a gamma function (the raise function), while the midtones transfer function that PI implements is a rational interpolation. Rational interpolation is much more flexible and accurate than a gamma function. I can elaborate more on this if you want."

In particular, is there any kind of mathematical conversion between gamma in PS and midtones in PI?  Visually, 0.09615 (more or less) as a midtone correction (to lighten) looks a lot like moving the gamma slider to 2.2/0.45 in PS (depending on which PS function, levels or exposure, you happen to be using).  


Elle

[Juan Conejero]

Hi Elle,

The midtones transfer function (MTF) in PixInsight is the curve applied by the HistogramTransformation tool to perform nonlinear intensity transformations (midtones balancing).

As you know, in PixInsight pixel intensity values are expressed in the normalized real range, that is, from 0=black to 1=white. This is independent on the actual data type used by any particular image. For example, for a 16-bit unsigned integer image, the platform maps 0 to 0 and 1 to 65535 (= 2^16 - 1) automatically. This works in a completely transparent way.

The MTF is a smooth curve defined through the following three control points:

{0,0}, {m,0.5}, {1,1}

Each point is defined by a pair of values in the [0,1] range. The first number is an input value, or the pixel value before applying the transformation. The second number is an output value, resulting after the transformation.

The m variable above is the midtones balance value, which is the only parameter that defines an MTF. When m = 0.5, we have an identity function (no change), i.e. a straight line from {0,0} to {1,1}. When m < 0.5, we have a function that increases the midtones (brightens the image). When m > 0.5, the corresponding MTF decreases the midtones (darkens the image). As you see, an MTF does not change anything at the extreme points of the available range.

To build a smooth curve across the three defining points of an MTF, PixInsight uses rational interpolation. This kind of interpolation allows defining wild transformations while keeping a high numerical accuracy. For example, with the HistogramTransformation tool, try defining a midtones balance value of 0.00000005 and look at the resulting curve with 500x magnification

A gamma curve is just the raise or exponentiation function, where gamma is the exponent: x^gamma. When gamma is < 1, the function brightens the image. When gamma > 1, the function darkens the image.

To calculate the value of gamma corresponding to a given midtones balance m, you can use this relation:

0.5 = m ^ gamma_mtf

where gamma_mtf is the gamma exponent that emulates the MTF curve with m midtones balance. Hence,

gamma_mtf = log_m( 0.5 )

where log_m is the logarithm of base m. Applying a well-known logarithmic rule:

gamma_mtf = log_10( 0.5 )/log_10( m )

This expression clearly shows the main problem with the gamma function. Since the logarithm of zero is undefined, m values close to zero are problematic. Similarly, m close to one is also a problem because log( 1 ) is zero. This does not happen with rational interpolation, which is well behaved across the entire [0,1] range.

[Elle]

Hi, Juan and thanks for the math.  I'll need to mull on those word equations, til I figure out which keys to press on my calculator.

In the meantime, the reason for my question was:

First, as an aside, as of wine version 1, PixInsight LE works really well in linux under wine, using XP as the default windows version.  The only catch is that to get color-management to work, the registry needs to be reset before each use (yeah, I know, LE is old and core is great).

Second, I developed a raw image using dcraw at the command line, with multipliers of 1,1,1,1 (no color balancing).  Using PI-LE I color-balanced and "stretched" the image 3 times:

(i)just with pixelmath,
(ii)just with curves, and
(ii)just with histogram

In other words, three different PI-LE tools to produce the same end result, a color-balanced and properly stretched image.  All three output files looked essentially the same, with only very slight differences in average lightness.  

As you know, dcraw outputs a linear (gamma=1) file.  The camera profile I applied to dcraw's output assumes gamma=2.2.  So the dcraw output is very dark and needs to be "lifted" in the midtones with a gamma correction.  I don't see any easy way to do a gamma correction with curves.  But I used the appropriate power function with pixelmath and saved the result.  

On a different copy of the color-balanced/stretched image, I used the midtones histogram function (experimenting to find a value that more or less looked like the result of using 0.454545 power function from pixelmath on the previous image) and saved the result.

The midtone histogram version looks really nice, crisp and clear with nicely but realistically saturated colors and excellent tonality, but the shadows are blocked.  The pixelmath version has almost a hazy look, but the shadows are not blocked.  The results are the same regardless of which PI-LE tool - pixelmath, curves, or histograms - was used to color balance and stretch the original dcraw output.

Any ideas why the outcome of the two different ways of restoring the intended gamma of the original image turns out so differently, when using the pixelmath power function vs the histogram midtones function?

I've used pixelmath many times to gamma corect dcraw's linear gamma output.  Making the resulting image look good with some further processing is not at all difficult.  But I was really, really curious about how very nice the histogram-midtone correction looks without any further processing.

Elle Stone