Feature request: HDR rendering

[memononen]

Feature request: HDR rendering

[dougbinks]

NanoVG renders to whatever render target is currently bound. So if you bind a 16F/32F texture as a render target then it will render to that. All shader calculations are at full precision so this should also composite at the render target precision.

However input colours and images currently have only 8-bits per channel, although colours are passed to the renderer as float converted from 8-bits per channel.

[paniq]

Cairo deals with colors as normalized floats only (very similar to GL, ironically), so full magenta would e.g. be (1.0,0.0,1.0). I found that to be quite convenient. NanoVG seems to require a muxer conversion of (8-bit) colors before they can be passed to nvgStrokeColor / nvgFillColor (Cairo has the concept of a single source (pattern, gradient, color) for both stroke / fill operations, and multiple set_source_* functions). I would imagine replacing unsigned int with a nvgColor that is a typed float[4] would be in the lib's present spirit.

I should add that I have no use for convenience functions on the C level, as I'm intending to use the library only through a Python interface, which also holds my convenience layers.

[dougbinks]

I'd be interested in doing this work as it would be useful for me, and I'm familiar enough with NVG to do it fairly quickly.

It looks reasonably trivial to make the underlying state use floats, and all the current byte functionality can be left with new functions nvgFillColorF etc. made for using floats.

If Mikko thinks that's a reasonable approach I can go ahead and do it.

[memononen]

Sounds good!

Maybe I could be better to introduce nvgColor, and nvgRGBA/nvgRGBAf() instead. My rationale is that it adds specialization to the color packing functions, not to the main API. I don't have super strong feelings about this, though.

[dougbinks]

nvgColor with nvgRGBA/nvgRGBAf() would be better as an API I think, but it
could break some folks code - so it depends how much
backwards compatibility you want at the moment.

If you're OK with a small break (most folk probably use nvgRGBA which
should work), then I say we go for nvgColor. Let me know and I'll do it at
some point next week or so.

On 16 March 2014 21:29, Mikko Mononen [email protected] wrote:

Sounds good!

Maybe I could be better to introduce nvgColor, and nvgRGBA/nvgRGBAf()
instead. My rationale is that it adds specialization to the color packing
functions, not to the main API. I don't have super strong feelings about
this, though.

Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-37769292
.

[memononen]

Since the project is still quite young, I think the right choice is to go with the choice that will keep the API cleaner. I think it is the way of nvgColor. If the use feels ackward, then let's reconsider it.

[paniq]

As long as the color struct is cast compatible to a data type primitive (e.g. float[4]) it seems OK. Usually less custom structures is more comfortable in interop situations.

[dougbinks]

I have a working nanovg version with a color structure and gl3 backend here: https://github.com/dougbinks/nanovg/commits/NVGcolor

If @memononen is happy with the overall design, I'll look to porting the other backends and submit a pull request.

Note that the utility function nvgTransRGBA no longer makes much sense, but I've left it in.

[dougbinks]

I ended up fixing the other code branches, though I've not been able to test the ES versions (same code though so should work).

[dougbinks]

See #56

[paniq]

Good work everyone :)