1.5.9: Curves Transform mismatch between preview and result

[georg.viehoever]

Hi,

the attached screenshots show my attempt to get rid of excessive red noise from my Canonm by applying a curves transform that should clip the red noise. The preview helped me to determine a setting where the red noise is invisible. When I apply those settings to the real image, the result is clearly different from the preview: Most of the noise is still visible.

Georg

[Carlos Milovic]

I wouldn't say that this is a bug... Real Time previews are approximations of the image. In this case, you are using a smooth function, so the RTP image is softer than the real image, therefore shows less noise. This is the reason why we always say that one should check the result of a predicted RTP with an actual preview on the image.


PS: I think that this procedure is not the best to get rid of noise...

[Juan Conejero]

Hi Georg,

I second what Carlos has said. When performing these operations in real-time, you always must use a preview small enough as to allow a 1:1 screen representation, or even a magnified representation, when necessary, or the resampling made by the R-T interface will destroy the data you're trying to work with.

For example, you can use the real-time preview with histograms or curves working on the whole image, since these tools act strictly on pixel values. However, tools that modify small-scale contrast, or tools that correlate neighbor pixels, such as UnsharpMask, ATrousWaveletTransform or ACDNR for example, must be previewed at (at least) 100% scale to obtain accurate representations. Attempts to reduce artifacts such as Canon banding —irrespective of the idoneity of the methods applied to implement them— fall (indirectly in your case) into this category.

[David Serrano]

or the resampling made by the R-T interface will destroy the data you're trying to work with.

Which brings us to a feature request: zoom 1:1 on the RTP window (only selectable when the view has appropriate dimensions). I've looked for it a couple of times, and the only way to achieve it was to resize the RTP window to an approximate size.

[georg.viehoever]

Hi,
thanks for your answers. I need to check this with one of my images.

- Carlos: using this type of clippping was just one experiment to get rid of the noise. In the end, I used a masked ACDNR.
- David: I second your request for 1:1 zoom
- I would like to add that better documentation of PI features would certainly help to avoid such mismatched between expected and real behaviour. I also doubt that some bubble help would be the appropriate place for documenting it.

Kind regards,
Georg

[Nocturnal]

or the resampling made by the R-T interface will destroy the data you're trying to work with.

Which brings us to a feature request: zoom 1:1 on the RTP window (only selectable when the view has appropriate dimensions). I've looked for it a couple of times, and the only way to achieve it was to resize the RTP window to an approximate size.

Heck yeah!

[Nocturnal]

Oh, I always use small previews with ACDNR. It's not feasible to use it with the 1:1 RTP window as you can't see what effect it's having. Luckily the changes to the small previews seem reasonably representative of what happen on a full image.

[David Serrano]

Oh, I always use small previews with ACDNR. It's not feasible to use it with the 1:1 RTP window as you can't see what effect it's having. Luckily the changes to the small previews seem reasonably representative of what happen on a full image.

Or you can use PreviewAggregator  </shameless plug>

[Nocturnal]

I'm well familiar with that handy script, I use it all the time for color calibration. It leaves lots of black space though so if a preview isn't representative of what ACDNR will do to an entire image how will all that black space affect it?

Anyway, the point of using previews is to quickly check ACDNR parameters and see 1:1 or zoomed RTP. So far my results have been satisfactory with this method so I'll keep doing it even if ACDNR on previews isn't representative. It would be nice if PI could warn you that the current process applied to a preview (that is not the entire image) will not be representative of what will happen to the entire image. Certainly something that should be included in the documentation.

[Juan Conejero]

It would be nice if PI could warn you that the current process applied to a preview (that is not the entire image) will not be representative of what will happen to the entire image.

Currently you can expect this kind of problems with just a few processes in PixInsight (mainly multiscale algorithms):

- The HDRWaveletTransform algorithm requires the whole existing range of brightness values to be well represented on the preview. By well represented I mean that the entire range must be represented at all the scales involved in the HDRW transform (depending on the number of wavelet layers selected). In practice, this means that unless you have a relatively small galaxy surrounded by free sky background, your preview must be complete. This is by far the worst case of non-previewable algorithm.

- Regularized deconvolution can give similar problems, although they are usually much more avoidable/controllable, mainly because wavelet regularization acts at small scales.

- The wavelet-based noise reduction algorithm implemented in ATrousWaveletTransform can also be slightly inaccurate for the same reason, but usually the differences are negligible.

- UnsharpMask and other convolution-based algorithms, when applied with very large filters (for example, from 100 to 250 pixels) can also give some problems with relatively small previews. In this case, the reason is that fixing boundary artifacts with very large convolution filters may lead to inaccurate results. In PixInsight/PCL, boundary artifacts are fixed by padding with mirrored pixels from the borders of the image. When the padded regions are comparatively large, they may be very different from what actually exists around the preview on the whole image.

Other that these, there should be no problems with partial previews.