Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Juan Conejero

Pages: [1] 2 3 ... 260
1
It seems that high contrast areas (sharp edges) are hard to de-noise and not really indicative of how well an algorithm is suited for astro photography because they don't occur in a typical nebula or galaxy image.

Would it be possible to use a softer source image, add noise and then see how well each method does?

Here is a completely different noise reduction problem, this time with a synthetic image generated with the SimplexNoise tool in PixInsight:


Simplex noise is a texture generation algorithm created by Ken Perlin in 2001. It is similar to Perlin noise, but much faster. I implemented a barebones simplex noise generation tool in PixInsight back in 2007. If you are interested in this topic, this slide show from the author is very interesting to understand how all of this stuff works, with some historical background. By all means, exploring Ken Perlin's website is obligatory if you are interested in anything related to computer graphics.

Despite the fact that PixInsight's implementation of simplex noise is very basic, one can do things like this in a couple minutes with the SimplexNoise and CurvesTransformation tools, plus the Spherize script:


Returning to the subject of noise reduction, this is the simplex noise sample above with a mix of Gaussian and Poisson noise added with the NoiseGeneration tool, enlarged 2:1 without interpolation:


The noise has been added masked with the image itself. The result is an attempt to simulate the distribution of noise in a typical deep-sky image, with the purpose of testing the noise reduction algorithms on a smooth target. This simulation lacks small-scale image structures such as stars and ionization front edges, but my purpose is to provide a complimentary test to the first one with the double gradient image. Here are the results:

TGVDenoise

ATrousWaveletTransform

GREYCstoration

MultiscaleMedianTransform

ACDNR

Again, all tools have been applied without masks (not even ACDNR's built-in mask), trying to achieve the best possible result in each case.

The clear winner is again TGVDenoise. You may have to download the images and inspect them zoomed 4:1 to properly compare the results. As expected, ATWT performs extremely well for smooth targets. GREYCstoration also yields a very good result, but the strongest points of MMT and ACDNR definitely don't shine on smooth images without any edges like this one.

As happens with the double gradient image, this is a difficult target that tends to expose the weakest points of the most specialized algorithms. Some of these algorithms perform well for the double gradient and poorly for the simplex noise image (ACDNR), and vice versa (ATWT, GREYCstoration). I hope this will give you a more complete picture of the noise reduction tools that we have currently in PixInsight.

The bottom line is that TGVDenoise seems to outperform everything else that we have implemented in a variety of contexts. Does this mean that TGVDenoise will replace all of the other noise reduction tools? Well, not actually, and I have an example that shows this.

If you want to repeat this test yourself, I have uploaded the corresponding PixInsight project.

2
Quote
The cornermask is, a you mentioned, an offense against the PI philosophy.

It depends on how and why you apply it. If by "PI philosophy" you mean my philosophy, then here it is. If you:

- Analyze the data to find and outline the problem,

- Understand the problem and its causes (for example, an ampglow artifact or a light leakage issue in this case),

- Design a suitable solution to the problem (a local mask in this case),

- Evaluate the side effects and the risks of your solution (decreased SNR on the masked area in this case, and the risk of introducing a nonuniform illumination artifact),

- Make an informed decision as to whether the solution of the problem is worth the side effects and risks,

- Apply the solution strictly to solve the problem, preferably in a purely algorithmic way,

- Evaluate the result of the applied solution and its side effects,

then what you are doing is astrophotography: Turning data into information to communicate something from nature. However, if you do one or more of the following:

- Apply arbitrary manual retouching techniques without documentary criteria (example: create a layer mask, paint it with a brush by hand, then sharpen where you want because it looks nicer that way),

- Remove objects or image structures selectively, without documentary criteria (for example, removing all the stars in a wide-field image can be a nice way of revealing the true shape of a nebula, but removing a large blooming by cloning its adjacent pixels is like "inventing" that part of the image),

- Add artificial elements or artifacts "for aesthetic purposes" (example: artificial star spikes),

- Apply any process selectively without documentary criteria, i.e. without criteria based on a thorough analysis and understanding of the properties and nature of the data and of the objects represented (typically also for aesthetic reasons),

- Apply processes incorrectly, or without the necessary knowledge and common sense, (typically, trying to process an image beyond the reasonable limits imposed by the SNR of the data),

then what you are doing is, to a lesser or greater extent, painting. Downloading the image from the Internet to modify it, or painting it directly on a canvas, may be easier than acquiring it from the sky, and the results may be aesthetically better, too.

Astrophotography, as I understand it, is much more about the "how" and the "why" than about the results. When I look at an image, I need to be sure that I can trust what I am seeing. For this to happen, I need to know how the image has been processed and why. In essence, this is also the philosophy behind PixInsight, but everybody can use a tool as they want.

3
General / Re: Problem with image alignment
« on: 2013 May 20 10:58:01 »
Hi,

I'm sorry to say that these images cannot be registered with our StarAlignment tool. With default parameters, our star detection routine fails because it finds more than 25,000 false stars on each image. This is because the images have very high noise levels. I can work around this by adjusting star detection parameters, but then the problem is that the images are out-of-focus. Our star detection routine rejects most of the stars because they are 'concave' (brighter in their edges than in their cores).

4
Quote
previous releases allowed masking.

Scripts cannot be masked, neither in PI 1.8 nor in previous versions. ATrousWaveletTransform is the right tool to isolate image structures.

6
General / Re: pixinsight magazine
« on: 2013 May 20 10:14:37 »
True. I'll transform that article (updated) into a tutorial. Thanks for pointing this out.

7
Bug Reports / Re: 1.8RC7: No abort button
« on: 2013 May 20 10:13:16 »
Absolutely wonderful!  :D

8
Hi Evzen,

Quote
I'm a bit confused that DCRAW params are always dcraw -D -k 0 -t 0 -o 0 -4, no matter what is set in RAW format preferences.

The BatchPreprocessing script ignores your current DSLR_RAW module settings, to force loading of pure raw data with the above arguments.

Quote
Direct debayering (BatchDeBayer) seems to be working properly
Quote
using BatchFormatConversion - the resulting image has all pixels with level 0

This is very strange. I need one of these files from your camera to investigate what happens.

9
Bug Reports / Re: crash while saving project, 1.8RC7 macosx
« on: 2013 May 20 10:03:16 »
Have you been able to reproduce this problem? Have you configured multiple swap storage devices with Preferences?

10
Bug Reports / Re: Alt n for preview ...weirdness on osx
« on: 2013 May 20 09:56:43 »
i think this is a long-standing bug either in Qt on OSX or in the way PI interacts with Qt.

in all versions of PI, eventually some modifier keys stop working. for me notably it's command r,g,b,0 to see the different planes of an RGB image.

i usually use the new preview icon to create previews. it looks like a piece of paper with the top left corner notched off.

Are you using a compact Apple keyboard without numeric keypad? We only have wired keyboards with numeric keypads, and we cannot reproduce any of these problems. These days we are working hard with PI on the iMac, preparing processing examples and some videos, and all keyboard shortcuts work without problems all the time with PI 1.8..

I'll try to buy one of these small (and useless, IMO) keyboards as soon as possible, to see if I can understand why they work so weirdly.

11
Bug Reports / Re: 1.8RC7: No abort button
« on: 2013 May 20 09:46:01 »
So, after a reset of PI settings, the Abort button is now shown normally? Very weird, but happy to know it works now. Can we put this one also in the "strange things that happen" bag? :)

12
Bug Reports / Re: 1.8 RC7 OSX crash
« on: 2013 May 20 09:39:41 »
Quote
...only a mouse-down event with no mouse-up. i see this a lot of times if i click on a process icon - the mouse just "picks up" the icon and i can't release the icon with the mouse. pressing the escape key releases the process icon.

There were some similar issues in 1.7, but I cannot reproduce this with 1.8.0 on our Mac Pro 2008 and iMac 2013 machines. I admit that moving icons is much slower on the Mac OS X version of PixInsight than on the rest of platforms. It is real-time fast on X11 even if you move a selection of several hundreds of icons; somewhat slower on Windows but still reasonably fast.

I'm working to see if I can figure out where the problem is with moving icons on the OS X version of PI Core. If necessary, I'll rewrite the relevant code bypassing Qt completely. I hope this will be sorted out in the final 1.8.0 release.

I cannot reproduce the other crash while editing/moving a preview either. Considering the weirdness of the event, let's put it inside the "strange things that happen" bag for now :)

Quote
i did my 'undo/redo' thrash test and managed to get the segmentation violation dialog.

The undo/redo problem in previous RC versions was perfectly identified and fixed, so it cannot happen anymore in RC7 (it was a problem with non-reentrant event handlers; all of them are now reentrant).

Actually this line in your crash report tells us that something very different has happened:

Quote
non-virtual thunk to pi::ViewList::ImageCreated(pi::View const*)

This suggests that I have declared a virtual function but haven't implemented it. Definitely, this is not true for the ViewList class, so we have either a compiler and/or linker error, or something very very strange, such that after the initial segmentation violation, the executable image in memory got corrupted. Thank you for your report, I'll investigate this.

13
Bug Reports / Re: 1.8RC7: No abort button
« on: 2013 May 20 09:08:11 »
Pretty weird thing. Can you reproduce this? I have tried on all platforms and this doesn't happen with ImageContainer or any other process.

15
General / Re: pixinsight magazine
« on: 2013 May 20 08:59:49 »
Thanks for bringing this out. We'll remove the entire PI Magazine section during the next website update (which, after taking a quick look at the site, is becoming urgent since there's so much outdated material...)

Pages: [1] 2 3 ... 260