10bpc support #12
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Imlib seems to deal exclusively with 8bpc colors. These days, 10bpc or even more screens and video are becoming more and more common.
scrot can't take 10bpc screenshots of a 10bpc X server because
imlib_create_image_from_drawable()uses 8bpc. The Linux fb API supports 10bpc: https://www.kernel.org/doc/Documentation/fb/api.txt but screenshotting a 10bpc framebuffer would mean reducing it to 8bpc first becauseimlib_create_image_using_data()uses 8bpc.It seems even the PNG loader converts to 8bpc:
29d3204a16/src/modules/loaders/loader_png.c (L184-L186)PNG in particular supports up to 16bpc colors. The VP9 and AV1 video codecs support 12bpc. xrandr says my hardware/X11 setup supports up to 12bpc.
Please add support for 10bpc and above.
While I no longer maintain Imlib2, I did design it and wrote most of it until I moved to Evas as I neeed something fat better. I left Imlib2 behind long ago as Evas replaced everything it does and then so much more. But the job of suporting 10bit per channel is basically a complete rewrite.
A whole new parallel set of APIs is needed for everything that exports or imports pixel data as the defined api/abi is 32bit ARGB. Every loader and saver now needs to handle possible 10bit data. Imlib2 was designed ~25 years ago with the idea that all data internally is in one universal format to keep code and implementation sane/simple as well as relatively optimal. Alpha is always there - but may have an optimized case of it being 0xff (solid) all the time. (Evas is the same BTW, but it is only maybe 20% rendering code of which a chunk is also abstracted as OpenGL - there is an entire scene graph, event handling and much more that would not change to support 10bit per channel (30bit color) and its abstraction does allow different pixel formats for input/output from the start so it already supports for example YUV, though loaders and savers in evas do assume they get ARGB 32bit and would need to adapt - but it's modifying a much smaller percentage of the lib that already handles multiple formats). In addition, in Imlib2, every single rendering function now needs to be duplicated as a special 10bit version. Every scale, draw, convert to/from screen, draw operation etc. now needs a 30bit version. In addition you destroy the "All data has an alpha channel" concept as you now have 30bits for RGB but only 2 bits left for alpha - that's not really functional Alpha at all. That then requires you probably have yet another internal pixel format to have a high depth yet functional alpha channel: 64bit ARGB (16bit per channel).
So in essence to support what you want needs pretty much a whole new library. 80% of Imlib2's code would need to be touched, altered or re-jigged in some way as well as a whole lot of new code added - it'd pretty much go up in size by 50% to handle this.
Right, much work and no benefit from my point of view.
I'm sorry to say that this is probably not going to happen.