QImage and floating point
I read somewhere recently that QImage can open (via plugins) EXR files, which are used for HDR floating point images, right?
So does Qt just resize these to bytes then load them, or is there a way to make floating point images in Qt?
With all the different format options in QImage, shouldn't it be possible to have a 128 bit floating point format?
QImage is something you can paint on directly, so without making quite a lot of changes across the graphics system that would be very poorly performing on a lot of devices Qt runs on, you can't really support floating point images properly. You also can't display images with floating point precision on any common hardware...
There's nothing wrong with reading such a format and converting it to standard RGB values in a QImage. Have you got a reason for using QImage with HDR floating point images and retaining the precision? A use case?
Yes, specifically when using the openGL tools with Qt, it would be useful to be able to render HDR textures. Of course custom code can be written that bypasses QImage entirely, but it seems in this case it would be useful.
Surely as QImage already supports so many different byte formats, and can render directly to all of these in an optimised fashion, another format wouldn't be any overhead?
Good use case - is it for high-end animation and special effects software... something like Pixar would use?
I guess it depends which parts of the QImage class you want to use... most of the methods take uchar's or QRgb's (which is just a typedef for an unsigned int).
Superficially at least, it looks like a fairly poor fit as an interface to images with floating point pixels. I expect the trolls could come up with something! It's not that mainstream though, so probably not a very high priority - particularly now Nokia owns the company and there seems to be a shift in focus towards embedded products - OpenGL ES doesn't support floating point textures IIRC.
Sounds like a good opportunity to contribute something to Qt! :-)
Yes, the interface is not a good fit. Hmm... will need some more consideration!
In my opinion what we need is a new image class (not QImage) for use with graphics hardware, which supports all OpenGL texture formats, this way we avoid format conversions.
Floating point (and other higher precision) image formats are also very useful for image-based computing and data processing. It would be quite handy to have an image class in Qt that could load and manipulate these types of images.
This kind of functionality requires converting between color spaces. A floating point internal storage is one of those color spaces, RGB is another.
Qt does not have this functionality build in and its not really something that a lot of people will need to find in a basic Qt install.
For users that need it I can suggest an open source (LGPL so for commercial usage too) library written in Qt and lots of templates. Its called 'pigment' and is included in the KOffice libraries directory which itself lives on the KDE svn server.
It has plugins for the color spaces and some very interesting ones are included in the project already. More info can be found on the krita.org website.
What about the new wide gamut displays that are starting to appear? Many of these have gamuts that are much wider than sRGB. These are starting to come into wider use now and will likely be common in the not too distant future. In addition we are starting to see displays and video devices that support 10 and 12 bits per channel and Display Port supports of to 16 bits per channel. How is an 8 bit per channel format like QImage suitable for use with this class of hardware?
Also as a side note color scientists do not consider "floating point internal storage" a color space but rather a storage format. In addition these same folks would also tell you that RGB is not a color space unless there is lots more information included to define it as a color space. What is it's white point? What is it's gamma? How do the RGB values map to a CIE color space like XYZ or Lab*? And so on. For example sRGB and ProPhotoRGB both define such color spaces. Absent that information it is impossible to do a meaningful conversion between color spaces.