Hey cool. Glad to hear you had no problems. Sorry, I missed it. I had an early night last night (sunday night >_<) .. Are there recordings to review?
It's an interesting idea; knowing if a colour is convertible to some other colour without loss... it sounds like it leads to implicit conversion, but I don't think we want that here. I'll think on how to do it. It's not really trivial. On 22 June 2015 at 18:55, Rikki Cattermole via Digitalmars-d <[email protected]> wrote: > On 22/06/2015 8:45 p.m., Andrea Fontana wrote: >> >> On Monday, 22 June 2015 at 08:08:42 UTC, Rikki Cattermole wrote: >>> >>> >>> Why would IImage support alpha? Shouldn't that be on the color? >>> If so, the PR does support it see RGBA8 and friends. >> >> >> I said "on color or IImage". Anyway transparency is a property (mask) of >> an image ("material") rather than of the color itself. A color has no >> transparency, there's no transparency on gamut. It doesn't make sense >> for a color: transparency is used only when you add an image over >> another in order to sum the *colors* of two pixels. They used to pack >> alpha informations with other pixel infos (color) just for simplicity >> and to have a convenient way to store info inside a file, I guess. >> >>> I just had a look at antigrain. It really is beyond this code. Well >>> and truly out of scope. >> >> >> I mean it would be useful to grab some ideas from it. >> And that it would really wonderful to have something like this. >> >> However I think it is useful to build the library and interfaces >> thinking also to possible future developments. >> >> Andrea > > > Humm, I can add it as an optional part of the interface like pixel offset. > Maybe. But it does feel a little less like other libraries out there. > > The main reason I'm put off of antigrain is it feels a little too much > unwieldy to me. > > But of course, I can't dismiss your guys suggestions so of course I'll dig > more deeper into it! Even if I do drag my heels a little bit.
