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 - mschuster

Pages: [1] 2 3 ... 69
1
General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 13:28:25 »
Thank you jlodge.

The two flat darks also appear to be scaled up by 16. This is good, as if any frame scaling is done, all frames should to be scaled likewise to avoid PI pre-processing havoc.

Given your flat and flat dark frames, MureDenoiseDetectorSettings report gain 0.061 e-/DN and Gaussian noise 27.71 DN. Both are what I would expect for this camera with 16x frame scaling. These are the values to use in MureDenoise as long as your light frames were also scaled 16x, which I am guessing is very likely.

Regarding why the update was downloaded and but not installed, I do not know.

Edit:
Quote
*EDIT* I have managed to add it through feature scripts and pointing it at Pixinsight/src/scripts/mschuster. Should it not add itself automatically?

Yes, I think it should have been.

2
General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 12:22:50 »
Thank you Juan.

jlodge, those flats do appear to be scaled up by 16, as all pixel values are multiples of 16. Had they not been scaled up, measured gain would be 16 times larger, about 1 e-/DN (as expected for the camera).

If you cannot resolve your update problem (you need other 1.8.8-2 PI updates also), here is a link to the MureDenoiseDetectorSettings script. Here is how to install it manually:

https://www.dropbox.com/s/bwilmq9h1mvia85/MureDenoiseDetectorSettings.1.1.zip?dl=0

Unzip to a folder
Script > Feature Scripts...
Add
Select the folder
Open
OK
Done

3
General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 09:49:12 »
Those repositories are correct. I don't know why an auto update has not appeared.

I will post a link later today which you can apply manually.

4
General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 08:06:14 »
Thank you. The new MureDenoiseDetectorSettings script should appears as an auto update. Please try Resources > Updates > Check for Updates. It should appear as Script > Noise Reduction > MureDenoiseDetectorSettings.

You will need two raw uncalibrated flats and either two raw bias or two raw darks for MureDenoiseDetectorSettings. Masters and calibrated frames will not work.

MureDenoise does not work with drizzle.

5
General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 07:24:18 »
A gain of 0.061 e-/DN indicates that frames were multiplied by 16. This is OK as long as it was done consistently to all frames.

A temporal noise of 715.11 DN is likely the noise in flat frames. MureDenoise needs noise in bias or darks, not flats. Assuming all frames were multiplied by 16, I expect noise in bias to be somewhere around 30 DN.

Please try my new script MureDenoiseDetectorSettings. It replaces the old measurement scripts, is easier to use, and avoids some confusion. I will update MureDenoise tooltips and documentation soon to reference this new script.

Also, if possible please post a link to two uncalibrated flat frames and either two bias frames or two dark frames.

Regarding offset, PI preprocessing normally removes offset when light frames are bias- or dark-subtracted. A 0 offset setting in MureDenoise is correct.

Leaving variance scale and cycle-spin as defaults is OK. You need to make sure combination count and interpolation method are set correctly. Also, the latest MureDenoise version has a new option use image metadata. You should check this box also.

6
Bug Reports / Re: 1.8.8-2 iMac drizzle weight issue?
« on: 2019 December 06 09:15:38 »
Hi Juan,

Thank you. I have two other questions:

1) Notice that the satellite trail shows in the difference image as a subtle level change along the trail. Does this indicate a small normalization issue related to rejection in drizzle?

2) Note that in this example ImageIntegration uses bilinear interpolation. As a test, please change it to Nearest Neighbor and retry the entire process. You will see that the satellite trail is now much more prominent in the drizzle integrated result. I think this is an issue also. Note, I recall several years ago NN being an issue with drizzle, maybe it is just not supported by drizzle?

7
Bug Reports / Re: 1.8.8-2 iMac drizzle weight issue?
« on: 2019 December 06 07:40:08 »
I just added a link to the processing icons, which I forgot to include.

8
Bug Reports / 1.8.8-2 iMac drizzle weight issue?
« on: 2019 December 06 07:35:34 »
Hi Juan,

I see an unexpected artifact in drizzle weights, x1, square, drop shrink 1. The artifact affects the drizzle integrated result. The artifact does not appear if drop shrink is 0.9.

All files (~300 MB):
https://www.dropbox.com/s/4a30qbj24oqud3i/Drizzle.zip?dl=0

Edit: Process icons:
https://www.dropbox.com/s/haxy7tsljmd2e1b/DrizzleProcessIcons.xpsm?dl=0

Drizzle weights, with "block structured" artifact:


Difference image, showing that artifact affects the result (difference created by the PixelMath icon):

9
Hi Juan,

Thank you, I forgot about that.

10
Hi Juan,

On this example, ImageIntegration generates this message:

Code: [Select]
* Rescaling output image. Integration range: [-1.37814204e-03,8.56981397e-01]

However the ImageIntegration output is not in the full range [0, 1] as I expected, instead it is [2.931992e-03, 9.946846e-01].

Is this a bug?

Zipped folder, with all frames, LocalNormalization reference and results, Integration results and log, and process icons.

The negative pixels were generated by using a low median LN reference.

https://www.dropbox.com/s/vqy07zhb20iotks/Rescale.zip?dl=0 (133 MB)

11
General / Re: 1800 second Lights do not calibrate
« on: 2019 November 29 21:03:52 »
My experience with QSI-683, same sensor as yours.

2400s lights 3nm Ha, 64x 2400s darks taken within one month of lights, all binned 2x2, all at -20ÂșC.

Some "warm" pixels in the lights get warmer than they were in the darks, and so don't calibrate out.

Some "warm" pixels in the lights get cooler than they were in the darks, so the reverse problem.

Some "warm" pixels in the lights were normal in the darks. And so on.

Solution: 1) Don't scale dark master, that only makes the problems worse. 2) Don't use a bias master, just dark-subtract, 3) Dither, good dithering plus good rejection solves the problem completely for me.

12
still, it sounds like the median of the LN stack was for some reason abnormally low? i understand that Mure has problems with the low median but it seemed like you were saying the low median is in itself a problem.

I now think the low median is not itself a problem. It might remain a problem if LN gave a low median result for a high median reference, as that might indicate LN is not operating as we expect it should. But I am guessing that this did not happen, probably the LN reference had a low median.

For MureDenoise, the new metadata I am proposing will provide more info on what LN actually did. That will help a lot.

13
at any rate the LN reference image was not a subframe, it was an integrated master. this probably has something to do with the problem, however, i was under the impression that it was OK to use an integrated master as the LN reference. maybe it should be LinearFit to a representative subexposure first.

Yes, I think LN non-frame references are OK, and LinearFit should not be necessary. What needs to change is MureDenoise. I am working on a fix, and with some additional metadata from LN and II, I think a solution may be possible.

14
it dawned on me that i could use the DBE'd image as a reference for LN

Rob, OK, a followup:

Maybe you used a LN reference image that was not a frame and also not included in the actual integration?

If so, what is its median?

15
Hello Sedat,

If we are to apply LN to the data, we can use MureDeNoise on the individual subframes right after calibration, prior to registration, LN and stacking, can't we ?

Don't denoise frames, as doing risks compromising SNR. Weak signals, that are buried in noise in the frames, but appear as signal above the noise in the integration, might be removed.

How well CosmeticCorrection plays with Mure Denoise? Should we eliminate this step if we know we gonna use MD ?

I have not tried CosmeticCorrection. For my projects, pixel rejection during integration solves the problem on my long exposures. My guess is that CosmeticCorrection is OK, especially for isolated pixels. But for bad rows/cols please double check MureDenoise results.

Pages: [1] 2 3 ... 69