-
Notifications
You must be signed in to change notification settings - Fork 91
Proposals juicypixels
This is a proposal for the 'Juicypixels' package to be included in the next major release of the Haskell platform.
Everyone is invited to review this proposal, following the standard procedure for proposing and reviewing packages.
Review comments should be sent to the libraries mailing list before **DATE TO BE EDITED**, which is the discussion deadline.
Proposal author: Vincent Berthoux
Package maintainer: Vincent Berthoux
The `JuicyPixels` package is a pure Haskell implementation of decoding/encoding of various image file format, with a simple image type.
Documentation and tarball from the hackage page:
http://hackage.haskell.org/package/JuicyPixels
Development repo:
git clone https://github.com/Twinside/Juicy.Pixels.git
The talk "Haskell Platform: Field Report and Future Goals" promote an extension of the Haskell Platform to fill some void. This proposal put itself in this vision and want to provide image encoding and decoding capabilities to the Haskell Platform.
The library handle Jpeg, PNG, Gif and bitmap files and is entirely programmed in Haskell and build on all three major OS.
The API is structured as follows:
* `Codec.Picture` - Generic image loading/serialization functions, the first module to import. * `Codec.Picture.Types` - Image type and pixel definition. * `Codec.Picture.Bitmap` - Specific functions for Bitmap (.bmp) files. * `Codec.Picture.Gif` - Specific functions for GIF (.gif) files, allow to load all images of gif animations. * `Codec.Picture.Jpg` - Specific functions for jpg (.jpg, .jpeg) files. * `Codec.Picture.Png` - Specific functions for PNG (.png) files. * `Codec.Picture.HDR` - Specific functions for Radiance (.hdr, .pic) files. * `Codec.Picture.Saving` - Helper to save into a file format without having to convert manually.
* Be 'stealable', if the limited provided abstraction doesn't suit the user, he must be able to use the data the way he wants. This enforce the very simple 'Image' type.
* Be pure for the user, all decoding/encoding function must be able to give results in bytestring, without relying on a file.
* Just be a serialization component of an hypothetic image stack. Very limited abstraction is proposed, it's not the role of this library.
A comparison with Imagemagick performance can be found there : https://soundofapixel.wordpress.com/2013/01/27/juicy-pixels-performances/
* No reverse dependency on Hackage * Only a handful image types are supported * Better documentation might be needed