New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More noisy data appear in place of perfectly well-exposed pixels #173
Comments
Actually no, the job of HDR is to choose the "best" data from the available ones. "Best" means valid (not clipped) and having highest SNR from the valid samples available.
Yes, the lower-exposed images should be ignored, since the best data are all in the brightest image in this case.
Not sure what EV has to do with checks for overexposure. The correct way to determine whether a (sub)pixel is overexposed is to compare its raw value to the maximum value for the camera which took the photo. |
I haven't checked the code but the calculated EV value seems to be off meaning that possibly the code is not measuring/detecting overexposure properly when deciding on which pixels from which layer to use |
Can you try this patch? index 6074321..81d6c06 100644
--- a/src/ImageStack.cpp
+++ b/src/ImageStack.cpp
@@ -90,6 +90,7 @@ void ImageStack::calculateSaturationLevel(const RawParameters & params, bool use
}
const size_t threshold = width * height / 10000;
+ const uint16_t min_saturation_threshold = params.max * 0.80;
uint16_t maxPerColor[4] = {0, 0, 0, 0};
@@ -112,6 +113,8 @@ void ImageStack::calculateSaturationLevel(const RawParameters & params, bool use
}
if (!useCustomWl) { // only scale when no custom white level was specified
+ // assume default saturation in case of dark images
+ satThreshold = std::max(satThreshold, min_saturation_threshold);
satThreshold *= 0.99;
}
Seems to perform better with your set of pictures. |
Although it doesn't apply to current master, I've applied it manually, and it does seem to give a good result. |
I was trying HDRMerge with three files, of which the one with longest exposure is actually sufficient: it has no overexposures and, due to having largest signal, has smallest SNR. But for some reason HDRMerge decides to place some underexposed data in place of the brightest parts of the image, resulting in very visible noise which stops outside of the bright part of the image.
Here's a link to the example three bracketed photos: Google Drive link. Steps to reproduce the problem:
Resulting image: Google Drive link.
The text was updated successfully, but these errors were encountered: