To further Devisualization, I have got the start of an image library.
It should be fairly interface complete now.

For this I really could use help from anyone with experience with PNG especially with Adam7 interlacing and color correction such as gamma.
Currently missing an exporter. Only imports. Does not import grayscale or palleted.

Goal: to act as the image representation within memory (including colors).
Usage:
Devisualization.Window uses it for window icon's (untested for x11 can somebody confirm this does indeed work?).
Devisualization.Font heavily uses it for glyphs and the output of its rasterization.

[0] https://github.com/Devisualization/image

15.11.2014 07:48, Rikki Cattermole пишет:
> To further Devisualization, I have got the start of an image library.
> It should be fairly interface complete now.
>
> For this I really could use help from anyone with experience with PNG
> especially with Adam7 interlacing and color correction such as gamma.
> Currently missing an exporter. Only imports. Does not import grayscale
> or palleted.
>
> Goal: to act as the image representation within memory (including colors).
> Usage:
> Devisualization.Window uses it for window icon's (untested for x11 can
> somebody confirm this does indeed work?).
> Devisualization.Font heavily uses it for glyphs and the output of its
> rasterization.
>
> [0] https://github.com/Devisualization/image

I have working PNG export in my image processing package, part of dlib: https://github.com/gecko0307/dlib
There're also importers for BMP and TGA.

On 18/11/2014 10:37 p.m., Timur Gafarov wrote:
> 15.11.2014 07:48, Rikki Cattermole пишет:
>> To further Devisualization, I have got the start of an image library.
>> It should be fairly interface complete now.
>>
>> For this I really could use help from anyone with experience with PNG
>> especially with Adam7 interlacing and color correction such as gamma.
>> Currently missing an exporter. Only imports. Does not import grayscale
>> or palleted.
>>
>> Goal: to act as the image representation within memory (including
>> colors).
>> Usage:
>> Devisualization.Window uses it for window icon's (untested for x11 can
>> somebody confirm this does indeed work?).
>> Devisualization.Font heavily uses it for glyphs and the output of its
>> rasterization.
>>
>> [0] https://github.com/Devisualization/image
>
> I have working PNG export in my image processing package, part of dlib:
> https://github.com/gecko0307/dlib
> There're also importers for BMP and TGA.

Hmm I see.
There is quite a few incompatibilities so porting or reusing isn't really an option without hitting the filesystem at this time. Unfortunately.

While I like the idea of dlib, I'm not a fan of all encompassing libraries atleast now (yes yes I know Cmsed and all). I don't feel adding a dependency on the entire package is worth it.

However by the looks of things, you definitely have better quality code.
At the very least some way to convert between the two e.g. SuperImage and my Image would be worth it.

On Tuesday, 18 November 2014 at 10:04:15 UTC, Rikki Cattermole wrote:
>
> However by the looks of things, you definitely have better quality code.
> At the very least some way to convert between the two e.g. SuperImage and my Image would be worth it.

Please consider the abstraction in ae-graphics.
http://code.dlang.org/packages/ae-graphics

CyberShadow has presented his image abstraction here: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/

It seems to be the best we have in D ecosystem and in the same spirit of Phobos.

If using it we could have loader/exporters, resizing, and various processing in separate libraries with a lot of reusability, instead of each one having an incompatible image abstraction.

Am Tue, 18 Nov 2014 12:37:54 +0300
schrieb Timur Gafarov <gecko0307@gmail.com>:

> 15.11.2014 07:48, Rikki Cattermole пишет:
> > To further Devisualization, I have got the start of an image library. It should be fairly interface complete now.
> >
> > For this I really could use help from anyone with experience with PNG especially with Adam7 interlacing and color correction such as gamma. Currently missing an exporter. Only imports. Does not import grayscale or palleted.
> >
> > Goal: to act as the image representation within memory (including colors).
> > Usage:
> > Devisualization.Window uses it for window icon's (untested for x11 can
> > somebody confirm this does indeed work?).
> > Devisualization.Font heavily uses it for glyphs and the output of its
> > rasterization.
> >
> > [0] https://github.com/Devisualization/image
> 
> I have working PNG export in my image processing package, part of dlib:
> https://github.com/gecko0307/dlib
> There're also importers for BMP and TGA.

I also just wrote a TGA importer and found RLE and 16-bit in
particular badly supported on Linux. E.g. eye-of-gnome
(Gnome's picture viewer) doesn't correctly restore the last
pixel's color in an RLE image and most software doesn't handle
16-bit at all. Add to that, that the specs are not very
specific as to what allowed values are and you get all
sorts of funny implementations quirks.

-- 
Marco

Am Wed, 19 Nov 2014 00:35:09 +0100
schrieb Marco Leise <Marco.Leise@gmx.de>:

> > I have working PNG export in my image processing package, part of dlib:
> > https://github.com/gecko0307/dlib
> > There're also importers for BMP and TGA.
> 
> I also just wrote a TGA importer and found RLE and 16-bit in
> particular badly supported on Linux. E.g. eye-of-gnome
> (Gnome's picture viewer) doesn't correctly restore the last
> pixel's color in an RLE image and most software doesn't handle
> 16-bit at all. Add to that, that the specs are not very
> specific as to what allowed values are and you get all
> sorts of funny implementations quirks.

For example:
- the original Targa paint software TIPS used to store a
  palette even for TrueColor images, meaning you should
  actually calculate the data offset as header + id + palette
  even for 24- and 32-bit images.
- the number of channels for a TrueColor TGA is always 3, plus
  as many attribute bits as given in the descriptor.

If you only support 8-bits per color channel, you should check
if bitsPerPixel is >= 24. Otherwise, bitsPerPixel == 16 would
be interpreted as a two color channel image instead of three
channels à 5-bits. And bitsPerPixel == 15 would become a one
channel image. :p
The 15-/16-bit variants were used quite a bit in the early
days of 3D games, like in the menu graphics for "Trespasser".
They are the same except that 16-bit allows for an additional
attribute bit that could be used for a transparency mask.

-- 
Marco