#61 32 and 24 bit conversion enhancements

Lucian Sabo

I have added support for RGBF, RGBAF, RGB16, RGBA16 into ConvertTo32Bits and ConvertTo24Bits.
This is especially useful for converting a high dynamic range image to 24/32 bits without the need for the slow ToneMapping.
At least for me, tone mapping give floating point exceptions with some images and the results are often not so good.
The conversion from RGBF uses also a 2.2 gamma correction, because the images will look over-saturated/dark if no gamma correction is applied.

Also, I cleaned up the code to improve consistency and minimize it.


  • Lucian Sabo

    Lucian Sabo - 2010-08-11

    24 and 32 bit conversion

  • Mihail Naydenov

    Mihail Naydenov - 2010-08-13

    I myself have also developed similar routines for the same purpose.
    I dont think they can fit into standard ConvertTo functions because they need additional params. At minimum gamma and exposure. Both of these should be user controllable.
    Also there are concerns about pow which is slow as hell. It can be worked-around with some methods the most crude of which being applying it on the LDR data where one can use a LUT.
    The long story sort, there are many considerations for the func to be generic and useful and in the end it is (more or less) trivial to implement in user code.
    (These are the concerns that hold me back from uploading similar code myself )

  • Lucian Sabo

    Lucian Sabo - 2010-08-13

    Still, I think the patch should be accepted since a basic support for this conversion is preferable on not having one. The code is small, it's faster than Drago and the results seem acceptable to me, better than IrfanView's implementation for example.
    If you replaced pow with something else, please show your version of gamma correction.

    User controlled parameters could go in a more sophisticated function which can represent a faster alternative to tone mapping.

  • Tanner Helland

    Tanner Helland - 2014-02-28

    I realize this patch has been dormant for four years now, but I thought I'd mention another reason that Lucian's patch makes sense.

    Many FreeImage forum posts involve trouble handling RGBF/16 images. It is difficult to debug these problems with new users, as there is no way to easily compare FreeImage's output with that of other software (e.g. Irfanview). Making matters worse, most test images - for example basic gradients - are destroyed by tone-mapping, so they just appear as black/white squares, which makes it seem like FreeImage is not handling the images correctly, when in fact tone-mapping is causing the distortion!

    While it may be trivial for seasoned graphics developers to roll their own linear or gamma conversion functions, this is overkill for novice users, especially those who just want a drop-in imaging solution. I bet few users choose to do that.

    Anyway, I myself searched the documentation for a simple linear transform (when debugging troublesome EXR images) and was shocked when I couldn't find one. For a "fast, easy-to-use" library, this seems like a big oversight.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks