Should I/O be included in LibHDR

[davideanastasia]

I want to hear your opinion about something that has been bugging me
for a while now.
I am currently working on the I/O of the new library, but I am
actually wondering if an I/O must be part of the library of not.
Do you think it should be in?

D.

[bruceg]

I think routines for decoding or encoding HDR file formats that don't
have other commonly available libraries could be useful, or *maybe*
wrappers around things like openexr. Otherwise I'd say focus first
and foremost on the algorithms that other libraries are not providing.

[Daniel Kaneider]

I agree with Bruce. The focus should be on features, that other libraries aren't providing: mainly hdr creation and tonemapping.
The other things, depend on the scope of libhdr. Routines for IO could be useful, but you always have to keep in mind that including external libraries could be a risk: for maintainability, durability, and the fact, that someone prefers library X over library Y.

[Davide Anastasia]

I in fact could say the opposite: including external dependencies and the wrap these libraries inside our api could mean less error from the user in feeding correctly merge and tonemap algorithms.

D.

[Daniel Kaneider]

Have a look at the nmake.opt file from the libtiff project. In an old fashioned way you can enable/disable jpeg support (using libjpeg), zip support (using zlib), iso jbig support (using jbig) and many other things. Such a kind of thing should be easy to implement with cmake options or something similar.

What I wanted to say is, that IMHO supporting external libraries could be useful and less error prone, agree. But I would see this as a possibility and not as a requirement when somebody "just" wants to use some functions of libhdr.

[Davide Anastasia]

I completely agree on this point. And as you say, it should be easy with cmake.

D.