www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Devisualization.Image

reply Rikki Cattermole <alphaglosined gmail.com> writes:
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
Nov 14 2014
parent reply Timur Gafarov <gecko0307 gmail.com> writes:
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.
Nov 18 2014
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Nov 18 2014
parent "ponce" <contact gam3sfrommars.fr> writes:
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.
Nov 18 2014
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 18 Nov 2014 12:37:54 +0300
schrieb Timur Gafarov <gecko0307 gmail.com>:

 15.11.2014 07:48, Rikki Cattermole =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 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 color=
s).
 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
=20 I have working PNG export in my image processing package, part of dlib:=20 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. --=20 Marco
Nov 18 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
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:=
=20
 https://github.com/gecko0307/dlib
 There're also importers for BMP and TGA.
=20 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.
=20 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 >=3D 24. Otherwise, bitsPerPixel =3D=3D 16 would be interpreted as a two color channel image instead of three channels =C3=A0 5-bits. And bitsPerPixel =3D=3D 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. --=20 Marco
Nov 18 2014