Author Topic: Noise evaluation problems  (Read 20264 times)

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: Noise evaluation problems
« Reply #15 on: 2011 August 13 04:40:39 »
Hi Rüdiger,

Quote
1: noise evaluation obviously takes the black areas into account, which are meaningless for the final result (see the changing green noise value)

Bear in mind that MRS noise evaluation is a multiscale (wavelet-based) algorithm. Black areas are large-scale structures and as such are being taken into account for noise evaluation (as noise-free regions). However, as you note their influence in the final noise estimate is very small or negligible. It is true that the existence of these large-scale structures may prevent convergence of the MRS algorithm in critical cases only.

Quote
2: sigma-based rejection algorithms need a normalized background value. Is the black area disturbing the normalization process?

Not at all. Black pixels are always ignored by ImageIntegration. You can also define two custom ranges of exclusion by enabling the Clip low range and Clip high range options in the Pixel Rejection (1) section, then specifying custom clipping points with the Range low and Range high parameters under Pixel Rejection (2). The default clipping points exclude all pixels equal to zero or greater than or equal to 0.98.

Quote
Do you recommend to crop before stacking in PixInsight?

No cropping is necessary with our tool set. Cropping doesn't hurt but is optional.

Quote
But the black areas can't be the only reason to make MRS fail.

Black areas are not a reason for MRS failure. It just happens that in critical cases where MRS is about to fail anyway, some large-scale structures may force failure.

The actual reason with your images is that they don't follow anything similar to a Gaussian noise distribution. If you inspect the individual RGB channels with STF enabled (and the Link RGB channels option disabled), you'll see that the noise (better visible on background regions) is composed by relatively large structures that tend to group contiguous pixels following regular patterns... the Bayer pattern:

http://pixinsight.org/images/forum/20110813/01.jpg

If you downsample the images with IntegerResample (downsample 1:2) there will be no problems with the MRS algorithm. A nice solution would be writing a little script to compute noise estimates:

- Open one image
- Create a working duplicate
- Apply IntegerResample to downsample 1:2 the duplicate
- Compute noise estimates with the MRS algorithm for the downsampled duplicate
- Dispose the duplicate
- Save the noise estimates to custom FITS keywords in the original image
- Save the image

Then you can use these custom keywords with ImageIntegration.

Juan Conejero
PixInsight Development Team
http://pixinsight.com/

ruediger

  • Guest
Re: Noise evaluation problems
« Reply #16 on: 2011 August 13 05:36:47 »
- Open one image
- Create a working duplicate
- Apply IntegerResample to downsample 1:2 the duplicate
- Compute noise estimates with the MRS algorithm for the downsampled duplicate
- Dispose the duplicate
- Save the noise estimates to custom FITS keywords in the original image
- Save the image

Then you can use these custom keywords with ImageIntegration.
Hi Juan,
thanks for the detailed answer, I guess, now I understand what's going on. I will write a script like suggested (wanted to experiment with some other EXIF data -- temperature etc. -- as custom FITS keywords anyway).
Regards,
 Rüdiger

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2132
Re: Noise evaluation problems
« Reply #17 on: 2011 August 13 06:55:54 »
Hi,

I wrote a little script that takes an image, rotates it by increasing angles, and does the noise estimate. I found the same behaviour with several images, both astro and natural images that were made noisy: noise estimates vary considerably with rotation angle, and at some point noiseMRS fails. See screenshot for setup and result.

The script is attached below. Maybe I have a bug in it?!?

Georg


Code: [Select]
#include <pjsr/StdIcon.jsh>
#include <pjsr/StdButton.jsh>
#include <pjsr/SampleType.jsh>
#include <pjsr/UndoFlag.jsh>

#define TITLE "TestScript"

function show(image)
{
  var wtmp = new ImageWindow( 1000, 1000, image.numberOfChannels,
                    image.bitsPerSample, image.sampleType == SampleType_Real, image.isColor,"RotImage" );
   var v = wtmp.mainView;

   v.beginProcess( UndoFlag_NoSwapFile );
   v.image.assign( image );
   v.endProcess();
   wtmp.bringToFront();
}

function doit(targetView)
{
   var image=targetView.image;

   for(angle=0.0;angle<100.0;angle+=5.0){
      // create copy and convert to float
      var newImage=new Image( image.width, image.height,
                                 image.numberOfChannels, image.colorSpace,
                                 (image.bitsPerSample < 32) ? 32 : 64, SampleType_Real );
         image.resetSelections();
         newImage.resetSelections()
         newImage.assign( image );
         newImage.rotate(angle/180.0*Math.PI,newImage.width/2,newImage.height/2);
//         show(newImage);
         noise=newImage.noiseMRS();
         Console.writeln(angle,",",noise);
         processEvents();
         gc(true);

   }
   Console.writeln("done");
}

function main ()
{
   var window = ImageWindow.activeWindow;
   if ( window.isNull ){
         var msg = new MessageBox(
         "<p>No active window. Terminating script.</p>",
         TITLE, StdIcon_Warning, StdButton_Ok);
         msg.execute();
         throw new Error( "No active window" );
   }
   if ( window.currentView.isNull ){ // ### This cannot happen - but testing doesn't hurt ;)
         var msg = new MessageBox(
         "<p>No active image. Terminating script.</p>",
         TITLE, StdIcon_Warning, StdButton_Ok);
         msg.execute();
         throw new Error("No active image");
   }
   var targetView=window.currentView;
   doit(targetView);
}

main();
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: Noise evaluation problems
« Reply #18 on: 2011 August 13 12:42:52 »
Hi Georg,

Thanks for an interesting experiment. Try with this modification of your script:

Code: [Select]
#include <pjsr/StdIcon.jsh>
#include <pjsr/StdButton.jsh>
#include <pjsr/SampleType.jsh>
#include <pjsr/UndoFlag.jsh>
#include <pjsr/Interpolation.jsh>

#define TITLE "TestScript"

/*
 * Routine copied from NoiseEvaluation script v1.1
 */
function NoiseEvaluation( img )
{
   var a, n = 4, m = 0.01*img.bounds.area;
   for ( ;; )
   {
      a = img.noiseMRS( n );
      if ( a[1] >= m )
         break;
      if ( --n == 1 )
      {
         console.writeln( "<end><cbr>** Warning: No convergence in MRS noise evaluation routine - using k-sigma noise estimate." );
         a = img.noiseKSigma();
         break;
      }
   }
   this.sigma = a[0]; // estimated stddev of Gaussian noise
   this.count = a[1]; // number of pixels in the noise pixels set
   this.layers = n;   // number of layers used for noise evaluation
}

function show(image)
{
  var wtmp = new ImageWindow( 1000, 1000, image.numberOfChannels,
                    image.bitsPerSample, image.sampleType == SampleType_Real, image.isColor,"RotImage" );
   var v = wtmp.mainView;

   v.beginProcess( UndoFlag_NoSwapFile );
   v.image.assign( image );
   v.endProcess();
   wtmp.bringToFront();
}

function doit(targetView)
{
   var image = targetView.image;
   for ( var i = 0; i < 25; ++i )
   {
      var angle = 5.0*i;
      var newImage = Image.newFloatImage( 64 );
      newImage.assign( image );
      newImage.interpolation = Interpolation_BicubicSpline;             // best detail preserving interpolation
      //newImage.interpolation = Interpolation_Bilinear;                // second best
      //newImage.interpolation = Interpolation_BicubicBSpline;          // smoothing interpolation
      //newImage.interpolation = Interpolation_MitchellNetravaliFilter; // smoothing interpolation
      // newImage.interpolation = Interpolation_NearestNeighbor;        // noise distribution preserved, no subpixel accuracy
      if ( i != 0 )
         newImage.rotate( Math.rad( angle ), newImage.width/2, newImage.height/2 );
      newImage.selectedRect = new Rect( newImage.width*0.25, newImage.height*0.25,
                                        newImage.width*0.75, newImage.height*0.75 );
      newImage.crop();
//     show(newImage);
      var noise = new NoiseEvaluation( newImage );
      newImage.free();
      Console.writeln( format( "%.0f %.4e", angle, noise.sigma ) );
      processEvents();
   }
   Console.writeln("done");
}

function main ()
{
   var window = ImageWindow.activeWindow;
   if ( window.isNull ){
         var msg = new MessageBox(
         "<p>No active window. Terminating script.</p>",
         TITLE, StdIcon_Warning, StdButton_Ok);
         msg.execute();
         throw new Error( "No active window" );
   }
   if ( window.currentView.isNull ){ // ### This cannot happen - but testing doesn't hurt ;)
         var msg = new MessageBox(
         "<p>No active image. Terminating script.</p>",
         TITLE, StdIcon_Warning, StdButton_Ok);
         msg.execute();
         throw new Error("No active image");
   }
   var targetView=window.currentView;
   doit(targetView);
}

main();

Your original script had two problems: Image.noiseMRS() returns an array (whose elements are noise sigma and number of noise pixels), and black canvas regions generated by rotation prevent MRS convergence. To fix the latter problem, I simply crop the center of the image after rotation and before noise evaluation.

As you can see, noise distribution variations are independent on rotation angle. The amount of change in the standard deviation of the noise is only a function of the applied pixel interpolation algorithm. This validates noise evaluation as a plausible image weighting criterion (the best criterion in my opinion) for image integration. The best algorithm for small-scale detail preservation is bicubic spline. Bilinear is the second best, and filter-based interpolations are too smooth. Nearest neighbor preserves the noise distribution, but lacks subpixel accuracy. This is an interesting experiment that shows --I don't hesitate to say this-- that PixInsight's pixel interpolations are very good.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2132
Re: Noise evaluation problems
« Reply #19 on: 2011 August 13 15:05:40 »
Hi Juan,

yes, the low noise variations are impressive. Two remarks though:

- I created a graph of the noise estimates for rotation angles between 0..370 degrees in 1 degree steps using your script. The result is attached below. While the fluctuations are generally quite low, I was surprised by the results for 90,180,270,360 degrees. I would have exprected noise equivalent to 0 degrees. This is not the case.
- In ImageIntegration, we also do have "black" areas after StarAlignment. Especially with messy mounts like mine these can be quite significant, probably invalidating (or making impossible) any MRS noise estimates. I think black areas should be ignored during the noise estimates in the ImageIntegration process.

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

ruediger

  • Guest
Re: Noise evaluation problems
« Reply #20 on: 2011 August 13 23:31:35 »
The actual reason with your images is that they don't follow anything similar to a Gaussian noise distribution. If you inspect the individual RGB channels with STF enabled (and the Link RGB channels option disabled), you'll see that the noise (better visible on background regions) is composed by relatively large structures that tend to group contiguous pixels following regular patterns... the Bayer pattern:

http://pixinsight.org/images/forum/20110813/01.jpg
Hi Juan,

I picked the already mentioned IMG_5466.CR2 and checked two other debayering algorithms from Fitswork, namely "Debayer, astro" and "Debayer, modified Kimmel". No large scale noise structures where visible.

I then compared the noise evaluation on these two files with the PixInsight "Debayer, linear fit" version.

Result:
Both Fitswork debayered files are converging on layer 4 during MRS noise estimates. I guess this is what we want?!
The linear fit debayered file is not converging (R and B).

What puzzles me, are the very different values for the green channel, which in all three file versions converges on layer 4.

Regards,
 Rüdiger

Code: [Select]
IMG_5466_RGB   -- PixInsight debayered linear fit

* Channel #0
** Warning: No convergence in MRS noise evaluation routine - using k-sigma noise estimate.
?R = 2.611e-004, N = 14414265 (95.09%), J = 1
* Channel #1
?G = 4.233e-004, N = 5016267 (33.09%), J = 4
* Channel #2
** Warning: No convergence in MRS noise evaluation routine - using k-sigma noise estimate.
?B = 2.515e-004, N = 14408609 (95.05%), J = 1
===================================================
RGB_IMG_5466_astro  -- Fitswork debayer,astro

* Channel #0
?R = 1.868e-003, N = 4014797 (26.48%), J = 4
* Channel #1
?G = 1.370e-003, N = 5429587 (35.82%), J = 4
* Channel #2
?B = 2.143e-003, N = 3395579 (22.40%), J = 4
===================================================
RGB_IMG_5466_kimmel -- Fitswork, debayer modified Kimmel

* Channel #0
?R = 2.836e-003, N = 7013621 (46.27%), J = 4
* Channel #1
?G = 2.586e-003, N = 9485781 (62.57%), J = 4
* Channel #2
?B = 2.916e-003, N = 5435059 (35.85%), J = 4
« Last Edit: 2011 August 13 23:46:33 by ruediger »

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: Noise evaluation problems
« Reply #21 on: 2011 August 14 02:38:35 »
Quote
I was surprised by the results for 90,180,270,360 degrees. I would have exprected noise equivalent to 0 degrees. This is not the case.

Just the opposite. Ideally, noise distribution variations should be constant for all rotation angles in the ]0,360] range (0 degrees is an exception because it doesn't modify the input image by design). So there should be no significant differences between 89, 90 and 91 degrees for example.

The inverse peaks at 90, 180, 270 and 360 degrees are due to quasi-total lack of aliasing at these rotation angles because the corresponding transformations are orthogonal. Note that there are also slight decrements at 45, 135, 225 and 315 degrees, also due to improved aliasing at these angles.

If you repeat the graph using some filter-based interpolation (Mitchell-Netravali for example), the corresponding variations should be much smaller.

Quote
- In ImageIntegration, we also do have "black" areas after StarAlignment. Especially with messy mounts like mine these can be quite significant, probably invalidating (or making impossible) any MRS noise estimates. I think black areas should be ignored during the noise estimates in the ImageIntegration process.

Unfortunately constant areas cannot be ignored in the MRS algorithm. The only solution is cropping them before noise evaluation. This can be implemented as an automatic feature (see if each side begins with a row (column) of constant pixels and stop cropping at the first row (column) with nonconstant pixels). Count on this implemented in the next version of ImageIntegration.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: Noise evaluation problems
« Reply #22 on: 2011 August 14 03:01:41 »
Quote
What puzzles me, are the very different values for the green channel, which in all three file versions converges on layer 4.

This is a consequence of the fact that there are twice more green pixels than red and blue in a Bayer CFA. Green is much better sampled spatially and hence its noise distribution is more like a Gaussian distribution at small scales.

Quote
Both Fitswork debayered files are converging on layer 4 during MRS noise estimates. I guess this is what we want?!

I'm not sure. From your data we have the following noise estimates for the green channel:

Debayering with linear interpolation: 4.233e-04
Debayering with 'modified': 2.586e-03

Note that the difference is nearly of one order of magnitude, so the image debayered with the second algorithm is nearly ten times more noisy. This looks somewhat strange to me (I'd had expected just the opposite), although I don't know which algorithms are being implemented by FITSWork so I can't say anything.

Could you make a little experiment? Debayer the image with the VNG, PPG and AHD algorithms in PixInsight (you'll have to change DSLR_RAW preferences and load the CR2 images directly to do this) and run the noise evaluation script (v1.1 from this thread) to see what happens.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2132
Re: Noise evaluation problems
« Reply #23 on: 2011 August 14 04:56:18 »
Hi Juan,

I repeated the experiment using Interpolation_MitchellNetravaliFilter, see screenshot 1. The noise values after rotation are much more reducded than with Interpolation_BicubicSpline (smoothed by roughly a factor of 10, the original value at 0 degrees is off-scale in the graph, indicating substantial loss of detail). So your assumption about the superior quality of BicubicSpline seems to be justified. Your expectation that the fluctuations would be smaller for a filter based interpolation seem to be correct in terms of absolute values, but certainly not in terms of smoothness.

Ruediger,

I think the noise patterns that Juan noticed in your fits files may partially be cause by the Debayer interpolation algorithms. I usually process my DSLR files using the "Create super-pixels..." setting, which appears to suffer much less problems.

All,

I did an FFT analysis of Ruediger's debayer_IMG_5486_c_r.fit image. The results can be seen in screenshot 2. I wonder if the patterns I see here are helpful to analyze the kind of noise that these images contain, and maybe to remove it. Advice welcome.

Georg
« Last Edit: 2011 August 14 05:14:26 by georg.viehoever »
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

ruediger

  • Guest
Re: Noise evaluation problems
« Reply #24 on: 2011 August 14 07:41:20 »
Could you make a little experiment? Debayer the image with the VNG, PPG and AHD algorithms in PixInsight (you'll have to change DSLR_RAW preferences and load the CR2 images directly to do this) and run the noise evaluation script (v1.1 from this thread) to see what happens.
I did this for two different files. For comparison, I included VNG and PPG algorithms from Fitswork also.
In PixInsight, debayering when opening CR2 images leads to other (correct?!) noise values than loading undebayered files first and using the debayer process later. These two different methods are marked with "linearOpen" and "linearProcess".

Code: [Select]
No. Fits file                         RAW file ISO sec °C R-noise              G-noise              B-noise
  1 IMG_5466_AHD_PixInsight           IMG_5466 800 120 33 4.439e-003 [20% J=4] 3.167e-003 [55% J=4] 3.516e-003 [39% J=4]
  2 IMG_5466_Kimmel_Fitswork          IMG_5466 800 120 33 2.836e-003 [46% J=4] 2.586e-003 [63% J=4] 2.916e-003 [36% J=4]
  3 IMG_5466_PPG_PixInsight           IMG_5466 800 120 33 4.584e-003 [23% J=4] 2.964e-003 [57% J=4] 3.323e-003 [38% J=4]
  4 IMG_5466_VNG_Fitswork             IMG_5466 800 120 33 2.657e-003 [44% J=4] 2.190e-003 [52% J=4] 2.868e-003 [35% J=4]
  5 IMG_5466_VNG_PixInsight           IMG_5466 800 120 33 3.769e-003 [16% J=4] 3.167e-003 [54% J=4] 3.334e-003 [41% J=4]
  6 IMG_5466_astro_Fitswork           IMG_5466 800 120 33 1.868e-003 [26% J=4] 1.370e-003 [36% J=4] 2.143e-003 [22% J=4]
  7 IMG_5466_linearOpen_PixInsight    IMG_5466 800 120 33 3.269e-003 [95% J=1] 2.232e-003 [33% J=4] 1.662e-003 [95% J=1]
  8 IMG_5466_linearProcess_PixInsight IMG_5466 800 120 33 2.611e-004 [95% J=1] 4.233e-004 [33% J=4] 2.515e-004 [95% J=1]
  9 IMG_5466_linear_Fitswork          IMG_5466 800 120 33 2.041e-003 [95% J=1] 2.236e-003 [33% J=4] 2.639e-003 [95% J=1]

 10 IMG_5549_AHD_PixInsight           IMG_5549 800 180 30 4.485e-003 [16% J=4] 3.171e-003 [47% J=4] 3.485e-003 [33% J=4]
 11 IMG_5549_Astro_Fitswork           IMG_5549 800 180 30 2.190e-003 [23% J=4] 1.581e-003 [30% J=4] 2.419e-003 [20% J=4]
 12 IMG_5549_Kimmel_Fitswork          IMG_5549 800 180 30 2.901e-003 [40% J=4] 2.636e-003 [53% J=4] 2.970e-003 [32% J=4]
 13 IMG_5549_PPG_PixInsight           IMG_5549 800 180 30 4.630e-003 [19% J=4] 2.970e-003 [49% J=4] 3.300e-003 [33% J=4]
 14 IMG_5549_VNG_Fitswork             IMG_5549 800 180 30 2.750e-003 [39% J=4] 2.252e-003 [44% J=4] 2.934e-003 [31% J=4]
 15 IMG_5549_VNG_PixInsight           IMG_5549 800 180 30 3.791e-003 [13% J=4] 3.173e-003 [45% J=4] 3.323e-003 [35% J=4]
 16 IMG_5549_linearOpen_PixInsight    IMG_5549 800 180 30 2.422e-003 [ 4% J=4] 2.235e-003 [27% J=4] 1.181e-003 [ 3% J=4]
 17 IMG_5549_linearProcess_PixInsight IMG_5549 800 180 30 1.930e-004 [39% J=2] 4.236e-004 [27% J=4] 1.788e-004 [ 3% J=4]
 18 IMG_5549_linear_Fitswork          IMG_5549 800 180 30 1.512e-003 [ 3% J=4] 2.241e-003 [27% J=4] 2.614e-003 [94% J=1]

I don't really know how to interpret all these values, especially the exceptionally low value of green noise from the "debayer linear" process from PixInsight. All other algorithms are a magnitude apart from this.

Besides that, my first GUI tool makes some progress, screenshot attached. It allows for finding the RAW files from where a FITS file was derived by some regular expression, reads EXIF data by the help of "exiftool", computes noise and (later, not implemented) adds some custom keywords to the FITS files. Primary goal is to precompute optimal weights in these cases where the noise evaluation partly fails on the input images.

The only question I have so far: how to get that nifty triangle in a dialog for storing the configuration as a process icon?

@Georg:
I sometimes use the SuperPixel method for even more noisy, more "large scale" structures. However, when shooting a globular cluster with only 400mm focal length, I guess I need every pixel available :)

Regards
 Rüdiger


ruediger

  • Guest
Re: Noise evaluation problems
« Reply #25 on: 2011 August 17 10:13:46 »
Hi all,

I spent some time during the last days to read about demosaicking algorithms and tested some of them on an artificial starfield, which was generated with Photoshop and then bayered.

It turns out, that bilinear debayering tends to render very small white stars green and introduce false color spots in the halo of larger stars, getting worse the sharper the edges are. Other algorithms, e.g. "Hamilton Adams" did a much better job on this artificial starfield.

So I implemented the Hamilton Adams algorithm in JavaScript and compared it with the PixInsight bilinear debayering process. The noise evaluation now converges on layer 4 and gives very promising values:

HamiltonAdams_PJSR
Calculating noise standard deviation...

* Channel #0
?R = 3.672e-004, N = 2995845 (19.76%), J = 4

* Channel #1
?G = 4.237e-004, N = 4926432 (32.50%), J = 4

* Channel #2
?B = 3.602e-004, N = 3109787 (20.51%), J = 4


The R and B colorplanes look much more "natural" than the PixInsight ones which show clearly visible labyrinth like artefacts, see screenshot.

Maybe (time permits) I will implement and compare more algorithms over the next days. The sourceforce project eLynx [1] and [2] are a great help and good starting point.

Regards
 Rüdiger

[1] eLynx: http://elynx.cvs.sourceforge.net/viewvc/elynx/eLynx/src/Image/Bayer/
[2] Demosaicking: Color Filter Array Interpolation in Single-Chip Digital Cameras (http://www.ece.gatech.edu/research/labs/MCCL/research/p_demosaick.html)

Offline Nocturnal

  • PixInsight Jedi Council Member
  • *******
  • Posts: 2727
    • http://www.carpephoton.com
Re: Noise evaluation problems
« Reply #26 on: 2011 August 17 13:58:41 »
I'm surprised bilinear debayer would have such a strong effect. It's a rather simple averaging of pixel values after all. I've never been all that happy with having just the superpixel and bilinear methods but didn't see much reason to implement AHD or other methods.
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: Noise evaluation problems
« Reply #27 on: 2011 August 17 14:03:22 »
The lynx software looks great. Not sure why that didn't show up in my research when I wrote the debayer module. Actually that's quite a while ago. In any case, I don't know enough about GPL to know what it means to PI's closed source if we include code derived from lynx into the debayer module.
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: Noise evaluation problems
« Reply #28 on: 2011 August 17 16:56:05 »
Quote
I don't know enough about GPL to know what it means to PI's closed source

Unless you have the explicit authorization from the copyright owner (usually the author(s)), there is no way to include any code licensed under a GPL license in a PixInsight module, even if you release your module as an open-source product (even under GPL).

Dcraw by David Coffin:

http://www.cybercom.net/~dcoffin/dcraw/

has been released under a liberal open-source license and includes excellent implementations of the VNG, PPG and AHD debeyer interpolation algorithms. The DSLR_RAW PixInsight module already uses dcraw internally. I am sure you know who wrote the initial version of this module ;)
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: Noise evaluation problems
« Reply #29 on: 2011 August 17 17:00:09 »
By the way, the upcoming version 2.0 of PCL (due Q1 2012) will be completely open-source and released under the PCL/PJSR license, which is basically a BSD license.

Even that won't change the fact that GPLed code cannot be used for PI modules in any way.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/