HDR pipeline questions

1. The reason is blending modes -- not all modes support HDR. Yes, a HDR/LDE switch is an obvious improvement, and that's how we plan to handle this, but the infrastructure for 'polymorphic' components is not ready yet.

2. I strongly believe that they shouldn't do anything smart -- this is the responsibility of the filter author.

3. These aren't planned, but both of them would be easy to implement.

4. Yes, we discussed that, but decided against putting it on our immediate plans -- we'd like to do high-priority stuff first. We may add .HDR file format in future betas on in updates for 2.0.

5. I don't think it's necessary to draw too much attention of non-professional public to the HDR feature. In fact, I designed its interface to be minimally intrusive, almost invisible, to preserve the LDR filter creation experience people are already used to. For example, the color picker is LDR by default and is switched to HDR only if the user says so, and the yellow brackets on inputs are very subtle. Plus, the lifesaver is not an easy target for HDRization, we'll have to find another preview image, which means combing through literally thousands of stock photos.

Quote
Crapadilla wrote: So, if I wanted to use an HDR component's output multiple times and pipe it into a couple of HDR/LDR inputs, how do I get around the clipping on the LDR inputs?

You already can use an HDR component's output multiple times, and piping it into any number of HDR and LDR inputs simultaneously is perfectly fine -- the HDR ones will receive unclipped colors, the LDR ones clipped.

I just don't quite understand why you need to "get around" the clipping -- if you need any custom clipping or tone-mapping for the LDR ones, you can just stick it there (as soon as we release components for that, haha!)

Or perhaps the problem you're trying to convey is the absence of clipper/normalizer/tonemapper components in the current version?

Clip HDR = Invert component with invert disabled