|Version 2 (modified by VincentBerthoux, 4 months ago)|
Proposal: Add the Juicypixels package to the Haskell Platform
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:
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.
Introduction to the API
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