Kai-Uwe Behrmann wrote: > FLTK is a toolkit and as almost all of these category of software not > trimmed toward bit depth but for speed. For 16-bit per channel and higher > processing most people use own routines, libraries like OpenEXR and the > like. > > An option more and more deployed is OpenGL these days. FLTK provides at > least good integration with OpenGL. I supect that FLTK drawing does not > work on OpenGL contexts. > > kind regards > Kai-Uwe Behrmann
I understand and agree with the performance reason. I was just curious as to why the original 16-bit data is not accessible? I scoured the docs but didn't find any mention to the fact that the 16-bit data would not be available. I was pretty confused (that is until I read the source for Fl_PNM_Image) when I accessed the raw data of the Fl_PNM_Image as 16-bit values and I was getting some weirdness. I had initially assumed that since I was loading a 16-bit image, that FLTK would keep it 16-bit since it is my own fault for using it. I haven't checked the other supported file formats, but I assume now that they all convert the pixel/channel value from 16-bit to 8-bit. For my purposes I need just the 16-bit data and I am not really concerned about how the image is viewed. Having it converted to 8-bit for viewing is fine in my situation. So, I'm not suggesting any changes to the current implementation, but perhaps this could be documented either in Fl_PNM_Image() or, if all image ctors do this, then in Fl_Image()? Should I create a STR? Cheers, Alvin _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
