Author Topic: 1.5.9: Curves Transform mismatch between preview and result  (Read 7349 times)

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2132
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
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Carlos Milovic

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2172
  • Join the dark side... we have cookies
    • http://www.astrophoto.cl
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #1 on: 2009 November 01 19:56:17 »
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...
Regards,

Carlos Milovic F.
--------------------------------
PixInsight Project Developer
http://www.pixinsight.com

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #2 on: 2009 November 02 01:20:57 »
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.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline David Serrano

  • PTeam Member
  • PixInsight Guru
  • ****
  • Posts: 503
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #3 on: 2009 November 02 03:02:56 »
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.
--
 David Serrano

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2132
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #4 on: 2009 November 02 03:36:27 »
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
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Nocturnal

  • PixInsight Jedi Council Member
  • *******
  • Posts: 2727
    • http://www.carpephoton.com
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #5 on: 2009 November 02 06:05:11 »
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!
Best,

    Sander
---
Edge HD 1100
QHY-8 for imaging, IMG0H mono for guiding, video cameras for occulations
ASI224, QHY5L-IIc
HyperStar3
WO-M110ED+FR-III/TRF-2008
Takahashi EM-400
PIxInsight, DeepSkyStacker, PHD, Nebulosity

Offline Nocturnal

  • PixInsight Jedi Council Member
  • *******
  • Posts: 2727
    • http://www.carpephoton.com
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #6 on: 2009 November 02 06:07:30 »
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.
Best,

    Sander
---
Edge HD 1100
QHY-8 for imaging, IMG0H mono for guiding, video cameras for occulations
ASI224, QHY5L-IIc
HyperStar3
WO-M110ED+FR-III/TRF-2008
Takahashi EM-400
PIxInsight, DeepSkyStacker, PHD, Nebulosity

Offline David Serrano

  • PTeam Member
  • PixInsight Guru
  • ****
  • Posts: 503
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #7 on: 2009 November 02 07:09:13 »
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  O0</shameless plug>
--
 David Serrano

Offline Nocturnal

  • PixInsight Jedi Council Member
  • *******
  • Posts: 2727
    • http://www.carpephoton.com
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #8 on: 2009 November 02 10:20:15 »
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.
Best,

    Sander
---
Edge HD 1100
QHY-8 for imaging, IMG0H mono for guiding, video cameras for occulations
ASI224, QHY5L-IIc
HyperStar3
WO-M110ED+FR-III/TRF-2008
Takahashi EM-400
PIxInsight, DeepSkyStacker, PHD, Nebulosity

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: 1.5.9: Curves Transform mismatch between preview and result
« Reply #9 on: 2009 November 02 10:48:04 »
Quote
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.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/