does LocalNormalization count as an unsupported ImageIntegration option? if so, what should be done in this case? not sure what to configure and where when you uncheck the 'use image metadata' checkbox.mschuster said:MureDenoise 1.25 should appear soon as an auto update.
Fixed bug in Use image metadata due to a typo.
Increased maximum Cycle-spin count to 48.
The text Use image metadata [none] indicates either unavailable image metadata or unsupported ImageIntegration options.
Hi Rob,pfile said:does LocalNormalization count as an unsupported ImageIntegration option? if so, what should be done in this case? not sure what to configure and where when you uncheck the 'use image metadata' checkbox.
Ok, thank you Rob. Please also post your detector settings and interpolation method. I would like to try denoising.pfile said:i have probably not been using it with LocalNormalization; i usually don't use LN but i have a dataset with a very difficult flattening problem and so i tried it out.
if "use image metadata" is checked, does the script ignore the Variance Scale setting? it seems like it doesnt, so does it treat the value 1 as a special case to internally compute a different value?
i will upload the image.
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.Sedat said: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 ?
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.Sedat said:How well CosmeticCorrection plays with Mure Denoise? Should we eliminate this step if we know we gonna use MD ?
no idea what changed the median then since the image was not processed, but i did run DBE so maybe that messed things up. or maybe my integration reference was bad, as mentioned i didn't really cull any frames or choose a good reference.mschuster said:Hi Rob,
Thanks for the info.
I tried LN on some frames, generating the actual normalized frames so that I could look at them.
I did not see a large change in median. Medians were changed, scales also, to roughly match those of the reference. A result which seems reasonable to me.
So it may be that the large median change in your project was due to some other processing.
But even so with these more moderate results, MureDenoise can't/won't account for LN processing. So it remains a not good idea for use with MureDenoise, at least to get "accurate" results.
MureDenoise strongly relies on pixel intensities to determine expected noise levels (ie, combined shot and sensor noise, parameterized by detector settings). Anything that tweaks pixel values in ways MureDenoise is not aware of will cause trouble.
Rob, OK, a followup:pfile said:it dawned on me that i could use the DBE'd image as a reference for LN
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.pfile said: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.