colour 2.2.0 → 2.2.1

raw patch · 4 files changed

+71/−9 lines, 4 filesPVP ok

version bump matches the API change (PVP)

API changes (from Hackage documentation)

Files

CHANGELOG +2/−0
Data/Colour.hs +63/−3
README +4/−4
colour.cabal +2/−2

+ CHANGELOG view

@@ -0,0 +1,2 @@+New in version 2.2.1:+ - Additional Documenation

Data/Colour.hs view

@@ -1,5 +1,5 @@ {--Copyright (c) 2008+Copyright (c) 2008, 2009 Russell O'Connor  Permission is hereby granted, free of charge, to any person obtaining a copy@@ -39,13 +39,73 @@ -- -- - "Data.Colour.RGBSpace" - --TODO -- - "Data.Colour.HDTV" -- -- - "Data.Colour.SDTV"+ module Data.Colour- ( -- *Colour type+ (+-- *Interfacing with Other Libraries\' Colour Spaces+--+-- |Executive summary: Always use "Data.Colour.SRGB" when interfacing with+-- other libraries.+-- Use 'Data.Colour.SRGB.toSRGB24' \/ 'Data.Colour.SRGB.sRGB24' when+-- interfacing with libraries wanting 'Data.Word.Word8' per channel.+-- Use 'Data.Colour.SRGB.toSRGB' \/ 'Data.Colour.SRGB.sRGB' when+-- interfacing with libraries wanting 'Double' or 'Float' per channel.+--+-- Interfacing with the colour for other libraries, such as cairo+-- (<http://www.haskell.org/gtk2hs/archives/category/cairo/>) and OpenGL+-- (<http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenGL>),+-- can be a challenge because these libraries often do not use colour spaces+-- in a consistent way.+-- The problem is that these libraries work in a device dependent colour+-- space and give no indication what the colour space is.+-- For most devices this colours space is implicitly the non-linear sRGB+-- space.+-- However, to make matters worse, these libraries also do their+-- compositing and blending in the device colour space.+-- Blending and compositing ought to be done in a linear colour space,+-- but since the device space is typically non-linear sRGB, these libraries+-- typically produce colour blends that are too dark.+--+-- (Note that "Data.Colour" is a device /independent/ colour space, and+-- produces correct blends. +-- e.g. compare @toSRGB (blend 0.5 lime red)@ with @RGB 0.5 0.5 0@)+--+-- Because these other colour libraries can only blend in device colour+-- spaces, they are fundamentally broken and there is no \"right\" way+-- to interface with them.+-- For most libraries, the best one can do is assume they are working+-- with an sRGB colour space and doing incorrect blends.  +-- In these cases use "Data.Colour.SRGB" to convert to and from the+-- colour coordinates.  This is the best advice for interfacing with cairo.+--+-- When using OpenGL, the choice is less clear.+-- Again, OpenGL usually does blending in the device colour space.+-- However, because blending is an important part of proper shading, one+-- may want to consider that OpenGL is working in a linear colour space,+-- and the resulting rasters are improperly displayed.+-- This is born out by the fact that OpenGL extensions that support+-- sRGB do so by converting sRGB input\/output to linear colour coordinates+-- for processing by OpenGL.+--+-- The best way to use OpenGL, is to use proper sRGB surfaces for textures+-- and rendering.+-- These surfaces will automatically convert to and from OpenGL's linear+-- colour space.+-- In this case, use "Data.Colour.SRGB.Linear" to interface OpenGL's linear+-- colour space.+--+-- If not using proper surfaces with OpenGL, then you have a choice between+-- having OpenGL do improper blending or improper display+-- If you are using OpenGL for 3D shading, I recommend using+-- "Data.Colour.SRGB.Linear" (thus choosing improper OpenGL display).+-- If you are not using OpenGL for 3D shading, I recommend using+-- "Data.Colour.SRGB" (thus choosing improper OpenGL blending).++-- *Colour type   Colour  ,colourConvert

README view

@@ -3,12 +3,12 @@ gamma-correct the colours before blending.  Hopefully by using this library, Haskell programs dealing with colour blending will avoid this problem. -I am making an early release of my colour library to get some feedback.-I am especially interested in getting feedback on the interfaces: should-functions be renamed, should functions be moved, etc.+There are some optimizing RULES pragmas that could be added to improve+preformance.  If you are having performace issues with colour, please+let me know, and we will test some of these pragmas.  Bug reports and any patches are also welcome.  Be warned, I haven't extensively tested this library yet.  -- -Russell O'Connor <roconnor@cs.ru.nl>+Russell O'Connor <roconnor@theorem.ca>

colour.cabal view

@@ -1,5 +1,5 @@ Name:                colour-Version:             2.2.0+Version:             2.2.1 Cabal-Version:       >= 1.2 License:             OtherLicense License-file:        LICENSE@@ -14,7 +14,7 @@                      A module of colour names ("Data.Colour.Names") is provided. Tested-with:         GHC == 6.8.2 extra-source-files:  Tests.hs-data-files:          README+data-files:          README CHANGELOG  Library   Build-Depends:     base