What will make YOU actually use or reject the image library?

p0nce said:

"The reasons that will make me interested in the end are cold and mechanical: is it maintained? does it load image files (progressive JPEG and normal PNGs)? quickliest? usable without runtime?"
"I tend to reject libraries that aren't on DUB, that impose bizarre flags, that don't work on the 3 desktop OSes, or seem to expand important energy on trivialities or strange wrappers. Preference for a few larger files."

Manu:

 I have no motivation to write code that I can't use in my own projects. (numerous, including Dreamcast game)

- must support a @nogc path with concern for allocation (which is inline with modern phobos; a la std.experimental.allocator)
- must be relatively small binary (pay as you go)
- GUI rendering at least as efficient as ImGui
- must have swappable rendering backend (ie, backend abstraction, which we've discussed quite thoroughly)
- must load common useful formats
- should care about compile times
- should care about memory consumption
- nice to have great runtime perf
- very-nice to have an attractive/modern UI look/feel that runs at refresh rate, rather than like a sloth (ie, electron)

NX1337:

I will say that I have no interest in an image library, but it's good to have one integrated with the GUI lib

integrity
I don't know exactly but if it doesn't suck chances are I'm gonna use it
because pretty much anything I used I wasn't pleased with
(in D)

cerjones:

image loading
control over memory usage, 
manual MM / or if GC dont want tons of garbage created when loading
cross platform windowing

WebFreak:

it should be fast
I want to use it fast
fast code, fast
so both low level and high level use cases

0xEAB

> What will make YOU actually use or reject the _image_ library?
use:
 - easily understandable API
 - usable as blackbox (without having to understand details what's going on underneath
 - docs that don't assume I already know what's going on
reject:
 - not available on DUB, or DUB support being treated as an orphan
 - hard to get working with existing misc graphics libraries (in terms of what it takes to write an adapter - while acknowledging that the image library is some kind of core of them)
 - MIT license or similar or more demanding - if not for a good reason (the image library shouldn't bloat the credits section imho (that I don't even would want to create for smaller apps))