| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3466
Application: | FLTK Library |
Status: | 2 - Closed w/o Resolution |
Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Image Support |
Summary: | FLTK and 16-bit images |
Version: | 1.3-feature |
Created By: | drdavid |
Assigned To: | AlbrechtS |
Fix Version: | Will Not Fix |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | drdavid 15:48 Apr 24, 2018 |
| Two very common PNG image types are 16 bit grey scale and 16 bit grey scale with 16 bit Alpha. When reading a 16 bit image I get the correct w(), h() and d()==1 but no indication pixels are unsigned shorts rather than unsigned bytes. When adding 16 bit image support don't forget to document or indicate the endianness of the image pixels.
If you add this feature I may switch over my large scale apps from using DevIL libraries to FLTK libraries. | |
|
#2 | AlbrechtS 14:47 May 26, 2021 |
| Thanks for this feature suggestion. However, there are currently no plans to use 16-bit image data internally, i.e. reading 16-bit images is possible but the internal storage is always 8 bits per channel. There are too many assumptions throughout the code regarding the data size and the documentation of d() can't be changed w/o breaking programs.
FLTK is not meant as an image processing library. FLTK's image features are limited to reading and displaying basic (i.e. 8-bit) images.
I'm sorry to say that the requested change is not going to happen in the near future, hence I'm closing this RFE.
You may however start a thread in fltk.coredev if you want to discuss this topic with the FLTK development team. https://groups.google.com/forum/#!forum/fltkcoredev
Note: changed title from "FLTK and 16 images" to "FLTK and 16-bit images". | |
[ Return to Bugs & Features ]
|
| |