Open Floessie opened 8 years ago
IMHO HDRMerge should be able to to the RT predemosaic steps itself before merging.
Let me explain:
1) badpixels should be corrected before merge because they a) can't be removed after merge when source files are misaligned and b) can lead to misalignments when using 'aligning' in HDRMerge.
2) darkframes should be applied before merge because it removes hot/dead pixels which could confuse the aligner
3) flat fields (vignetting correction and dust removal) should be applied before merge because (see above...)
4) even worse, if images are misaligned by a very small amount (2 pixels) variations in green channels may lead to a wrong output if not preprocessed by 'Green equilibration' or other methods
5) raw ca-correction is also a thing which at least is worth checkin whether it works well before merge
Ingo
Aha, so I was struck by 4), I suppose. I've got another example of a single pano strip, showing this phenomenon, with all other strips being okay. Maybe the wind shook my tripod when taking the shots for that particular strip.
Porting all those things over to HDRMerge seems way more expensive than porting HDRMerge's core algorithm over to RT (apart from UI integration). I'm not raising my hand. ;)
@Floessie Unfortunately I was wrong when assuming 'Green equilibration' is predemosaic. It's postdemosaic.
@heckflosse Maybe this could benefit from your motion detection work done for the pixelshift branch...
Hi there,
I'm having an issue with HDRMerge that pops up now and then only for some photo stacks. Here is a recent example:
After pushing the shadows (with tonemapping in this example), I sometimes get regions showing a pattern like above. I already figured out that they can be suppressed by using "amaze" with "Green equilibration" pushed above 50, or by using "vng4" instead of "amaze".
Now I'm wondering, why this might happen at all.
Here you find the CR2s. I've tested them with the latest HDRMerge and RT.