AutoDev

Top: traditional Digital Development curve (via FilmDev module), Bottom: AutoDev. Notice the vastly better dynamic range allocation, with more detail visible in the shadows and highlights, while not compromising on detail in midtones or blowing out stars. The AutoDev image is the perfect starting point for enhancing local detail.

AutoDev is an advanced image stretching solution that relies on detail analysis, rather than on the simple non-linear transformation functions from yesteryear.

To be exact, in StarTools, Histogram Transformation Curves (DDP, Levels and Curves, ArcSinH stretch, MaskedStretch etc.) are considered obsolete an non-optimal; AutoDev uses robust, controllable image analysis to achieve better, more objective results in a more intuitive way.

When data is acquired, it is recorded in a linear form, corresponding to raw photon counts. To make this data suitable for human consumption, stretching it non-linearly is required. Historically, simple algorithms were used to emulate the non-linear response of photographic paper by modelling its non-linear transformation curve. Later, in the 1990s because dynamic range in outer space varies greatly, "levels and curves" tools allowed imagers to create custom histogram transformation curves that better matched the object imaged so that the most amount of detail became visible in the stretched image.

Creating these custom curves was a highly laborious and subjective process. And, unfortunately, in many software packages this is still the situation today. The result is almost always sub-optimal dynamic range allocation, leading to detail loss in the shadows (leaving recoverable detail unstretched), shrouding interesting detail in the midtones (by not allocating it enough dynamic range) or blowing out stars (by failing to leave enough dynamic range for the stellar profiles). Working on badly calibrated screens, can exacerbate the problem of subjectively allocating dynamic range with more primitive tools.

Not a bug, but a feature! Don't let a first result like this scare you. AutoDev is doing you a favor by showing you exactly what is wrong with your data. In this we can see heavy light pollution, gradients and stacking artifacts that need taking care of before we can go any further.

StarTools' AutoDev module uses image analysis to find the optimum custom curve for the characteristics of the data. By actively looking for detail in the image, AutoDev autonomously creates a custom histogram curve that best allocates the available dynamic range to the scene, taking into account all aspects and detail. As a consequence, the need for local HDR manipulation is minimised.

AutoDev is in fact so good at its job, that it is also one of the most important tools in StarTools for initial data inspection. Using AutoDev as one of the first modules on your data will see it bring out problems in the data, such as stacking artifacts, gradients, bias, dust donuts, and more. Precisely per its design goal, its objective dynamic range allocation will bring out such defects so these may be corrected, or at the very least taken into account by you during processing.

Upon removal and/or mitigation of these problems, AutoDev may then be used to stretch the cleaned up data, bringing out detail across the entire dynamic range equally.

Usage

Great allocation of dynamic range by AutoDev after taking care of the stacking artifacts, gradients and light pollution using the Wipe module.

AutoDev is used for two distinct purposes;

1. To visualise artifacts and problems in your dataset.
2. To stretch the real celestial signal in your dataset
   

Using AutoDev is typically one of the first things a StarTools user does. This is because AutoDev, in the presence of any issues, brings out those issues, just like it would with real detail. Any such issues, for example stacking artifacts, gradients, dust donuts, noise levels, oversampling, etc., can then first be addressed by the relevant modules.

Once the issues have been dealt with to the best of your ability, AutoDev can be used again to stretch your final image to visualise the detail (rather than any artifacts). Do not attempt to use AutoDev for the purpose of bringing out detail if you have not taken care of forementioned artifacts and issues.

Improvements over basic histogram stretching

To be able to detect detail, AutoDev has a lot of smarts behind it. Its main detail detection algorithm analyses a Region of Interest ("RoI") - by default the whole image - so that it can find the optimum histogram transformation curve based on what it "sees".

Understanding AutoDev on a basic level is pretty simple really; its goal is to look at what's in your image and to make sure as much as possible is visible, just as a human would (try to) look at what is in the image and approximate the optimal histogram transformation curves using traditional tools.

The problem with a histogram transformation curve (aka 'global stretch') is that it affects all pixels in the image. So, what works in one area (bringing out detail in the background), may not necessarily work in another (for example, it may make a medium-brightness DSO core harder to see). Therefore it is important to understand that - fundamentally - globally stretching the image is always a compromise. AutoDev's job then, is to find the best-compromise global curve, given what detail is visible in your image and your preferences. Of course, fortunately we have other tools like the Contrast, Sharp and HDR modules to 'rescue' all detail by optimising for local dynamic range on top of global dynamic range.

Being able to show all things in your image equally well, is a really useful feature, as it is also very adept at finding artefacts or stuff in your image that is not real celestial detail but requires attention. That is why AutoDev is also extremely useful to launch as the first thing after loading an image to see what - if any - issues need addressing before proceeding. If there are any, AutoDev is virtually guaranteed to show them to you. After fixing such issues (for example using Crop, Wipe or other modules), we can go on to use AutoDev's skills for showing the remaining (this time real celestial) detail in the image.

If most of the image consists of a background and just a small object of interest, by default AutoDev will weigh the importance of the background higher (since it covers a much larger part of the image vs the object). This is understandable and neatly demonstrates its behavior. It will always look for the best compromise stretch to show the entire Region of Interest ("RoI" - by default the entire image). This also means that if the background is noisy, it will start digging out the noise, taking it as "fine detail" that needs to be "brought out". If this behaviour is undesirable, there are a couple of things you can do in AutoDev.

1. Change the 'Ignore Fine Detail <' parameter, so that AutoDev will no longer detect fine detail (such as noise grain).
2. Simply tell it what it should focus on instead by specifying an ROI and not regard the area outside the ROI just a little bit ('Outside ROI influence').

You will find that, as you include more background around the object, AutoDev, as expected, starts to optimise more and more for the background and less for the object. To use the RoI effectively, give it a "sample" of the important bit of the image. This can be a whole object, or it can be just a slice of the object that is a good representation of what's going on in the object in terms of detail. You can, for example, use a slice of a galaxy from the core, through the dust lanes, to the faint outer arms. There is no shame in trying a few different ROIs in order to find one you're happy with. What ever the case, the result will be more optimal and objective than pulling at histogram curves.

There are two ways of further influencing the way the detail detector "sees" your image;

• The 'Detector Gamma' parameter applies - for values other than 1.0 - a non-linear stretch to the image prior to passing it to the detector. E.g. the detector will "see" a darker or brighter image and create a curve that suits this image, rather than the real image. This makes the detector proportionally more (< 1.0) or less (> 1.0) sensitive to detail in the highlights. Conversely it makes the detector less (<1.0) or more (> 1.0) sensitive to detail in the shadows. The effect can be though of as a "smart" gamma correction. Note that tweaking this parameter will, by virtue of its skewing effect, cause the resulting stretch to no longer be optimal.
  
• The 'Shadow Linearity' parameter specifies the amount of linearity that is applied in the shadows, before non-linear stretching takes over. Higher amounts have the effect of allocating more dynamic range to the shadows and background.
  

Understanding AutoDev's behavior

In AutoDev, you are controlling an impartial and objective detail detector, rather than a subjective and hard to control (especially in the highlights) bezier/spline curve.

Having something impartial and objective taking care of your initial stretch is very valuable, as it allows you to much better set up a "neutral" image that you can build on with the other local detail-enhancing tools in your arsenal (e.g. Sharp, HDR, Contrast, Decon, etc.). For example, when using Autodev, it will quickly become clear that point lights and over-exposed highlights, such as the cores of bright stars, remain much more defined. The dreaded "star bloat" effect is much less pronounced or even entirely absent, depending on the dataset.

However, knowing how to effectively use Region of Interests ("RoI") is crucial to making the most of AutoDev. Particularly if the object of interest is not image-filling, a Region of Interest will often be necessary. Fortunately the fundamental workings of the RoI are easy to understand.

Confining the Region of Interest ("RoI") progressively to the core of this galaxy, the stretch becomes more and more optimised for the core and less and less for the outer regions.

Detail inside the RoI

Let's say our image is of galaxy, neatly situated in the center. Then confining the RoI progressively to the core of the galaxy, the stretch becomes more and more optimised for the core and less and less for the outer rim. Conversely, if we want to show more of the outer regions as well, we would include those regions in the RoI.

Detail outside the RoI

Shrinking or enlarging the RoI, you will notice how the stretch is optimised specifically to show as much as possible of the image inside of the RoI. That is not to say any detail outisde the RoI shall be invisible. It just means that any detail there will not (or much less) have a say in how the stretch is made. For example, if we would have an image of a galaxy, cloned it, put the two image side by side to create a new image, and then specified the RoI perfectly over just one of the cloned galaxies, the other one, outside the RoI would be stretched precisely the same way (as it happens to have exactly the same detail). Whatever detail lies outside the RoI, is simply forced to conform to the stretch that was designed for the RoI.

It is important to note that AutoDev will never clip your blackpoints outside the RoI, unless the 'Outside RoI Influence' parameter is explicitly set to 0% (though it is still not guaranteed to clip even at that setting). Detail outside the RoI may appear very dark (and approach 0/black), but will never be clipped.

Bringing up the 'Outside RoI Influence' parameter will let AutoDev allocate the specified amount of dynamic range to the area outside the RoI as well, at the expens of some dynamic range inside the RoI. If 'Outside RoI Influence' set 100%, then precisely 50% of the dynamic range will be used to show detail inside the RoI and 50% of the dynamic range will be used to show detail outside the RoI. Note that, visually, this behavior is area-size dependent; if the RoI is only a tiny area, the area outside the RoI will have to make do with just 50% of the dynamic range to describe detail for a much larger area (e.g. it has to divide the dynamic range over many more pixels), while the smaller RoI area has much fewer pixels and can therefore allocate each pixel more dynamic range if needed, in turn showing much more detail.

When you have two objects of interest in your image, choose the one that exhibits the widest dynamic range continuum (magnitude 6.9 M81 in this case).

Choosing the RoI in case of multiple objects of interest

All the RoI needs, is the best possible example of the dynamic range problem it should be solving for. Therefore, you should always give an example that has the widest dynamic range (e.g. has features that run from most dark to most bright). For example, when using AutoDev for the M81 / M82 galaxy pair, it is recommended you choose M81 (a brighter magnitude 6.9) as your RoI and not M82 (with a dimmer magnitude of 8.4).

In the above example, should you use M82 rather than M81 as a reference for the RoI, then you will notice M81's core brightening a lot and any detail contained therein being much harder to see. Of course, under no circumstances will the M81 core over-expose completely; a minute amount of dynamic range will always be allocated to it thanks to the 'Outside RoI' Influence parameter (possibly unless set to 0).

Choosing an object that is not representative of the dynamic range continuum of all objects, will result in some objects having their shadows or highlights "squashed" (as can be seen in M81) as they are "not of interest", and therefore will only be allocated a very small amount of dynamic range.

Keeping in mind AutoDev's purpose

The purpose of AutoDev is to give you the most optimal global starting point, ready for enhancement and refinement with modules on a more local level. Always keep in the back of your mind that you can use local detail restoration modules such as the Contrast, HDR and Sharp modules to locally bring out detail. Astrophotography deals with enormous differences in brightness; many objects are their own light source and can range from incredibly bright to incredibly dim. Most astrophotographers strive to show as many interesting astronomical details as possible. StarTools offers you various tools that put you in absolute, objective control over managing these enormous differences in brightness, to the benefit of your viewers.

Color retention

Please note you should completely disregard the colouring in AutoDev (if coloring is even at all visible).

Non-linearly stretching an image's RGB components causes its hue and saturation to be similarly stretched and squashed. This is often observable as "washing out" of colouring in the highlights.

Traditionally, image processing software for astrophotography has struggled with this, resorting to kludges like "special" stretching functions (e.g. ArcSinH) that somewhat minimize the problem, or even procedures that make desaturated highlights adopt the colours of neighbouring, non-desaturated pixels.

While other software continues to struggle with colour retention, StarTools Tracking feature allows the Color module to go back in time and completely reconstruct the RGB ratios as recorded, regardless of how the image was stretched.

This is one of the major reasons why running the Color module is preferably run as one of the last steps in your processing flow; it is able to completely negate the effect of any stretching - whether global or local - may have had on the hue and saturation of the image.

Because of this, AutoDev's performance is not stymied like some other stretching solutions (e.g. ArcSinH) by a need to preserve colouring. The two aspects - colour and luminance - of your image are neatly separated thanks to StarTools' signal evolution Tracking engine.