Hey guys,
I've been browsing around for quite a bit, because I supposed this is a classical error, although I couldn't find much.
I am well aware of the purple-highlights effect in case the ISO is amped down, but this has happened without all that thing, simple dual iso: 100 and 800.
Here are the files, the original interlaced image seems perfectly fine, but once I process it with cr2hdr the result is a nasty turn in blue/purple/pink.
The nature of this error showing up I'm rather sure it's a processing fault of the cr2hdr...
How can this be fixed?
A quick fix would be erasing all the excess info of the image, but I have no clue how to get there.
also, I'm using a rather recent version of it (v1.0.3)
(http://i.imgur.com/GeLgQYB.jpg)
Upload the CR2.
Quote from: Satis on May 22, 2014, 12:34:02 AM
also, I'm using a rather recent version of it (v1.0.3)
Recent version of what? I did not label any of my tools as v1.0.3.
Ok, the version has to be connected to the Lightroom cr2hdr plugin I downloaded yesterday.
Here is the file:
https://drive.google.com/file/d/0BzBsjJnB7tI2TEVmMEVvbkdmNlE/edit?usp=sharing
part of a raw video timelapse sequence.
Confirmed, will take a look these days.
Thanks a1ex!
Did you find something?
Yes, confirmed the bug, but didn't fix it yet.
Hey A1ex, respect for all the work that has been put into the development. I'm not trying to get a quick fix for the problem - this scene is not all that important to me - but I'm curious of what actually causes this effect.
I suppose the dynamic range of the original raw images exceeds that of the dual-iso converter's understanding, hence results in pink clipping.
As this is something I have seen in other contexts as well - blown highlights in raw sequences with iso's lower than 100, and maybe other instances too - this is a matter of extending the converter's capabilities to handle overblown highlight info, right?
Solved.
Thanks! 8) What was the problem, clipping due to overflowing data?
These highlights were at 16383 (a bit unusual, since white level is usually around 15000), which caused two overflows:
- when matching exposures, there is usually a small black level difference (around 60 in my worst-case samples)
- I also add some anti-posterization noise, which also caused a few pixels to become 16384 => overflowing to 0
Before, these very bright pixels were tagged as bad pixels, and interpolated. But here they are grouped together, so interpolation didn't work.