http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0 I hope for this library to become the standard colour library for Haskell. Most software does not properly blend colours because they fail to 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. Should I put black and white colours into Data.Colour? Which is better form making a colour: (sRGB r g b) or (sRGB (r,g,b))? Bug reports and any patches are also welcome. Be warned, I haven't extensively tested this library yet. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
roconnor:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0
I hope for this library to become the standard colour library for Haskell. Most software does not properly blend colours because they fail to 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. Should I put black and white colours into Data.Colour? Which is better form making a colour: (sRGB r g b) or (sRGB (r,g,b))?
Bug reports and any patches are also welcome. Be warned, I haven't extensively tested this library yet.
On Wed, Oct 22, 2008 at 1:12 AM, <roconnor@theorem.ca> wrote:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0
I hope for this library to become the standard colour library for Haskell. Most software does not properly blend colours because they fail to 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. Should I put black and white colours into Data.Colour? Which is better form making a colour: (sRGB r g b) or (sRGB (r,g,b))?
Bug reports and any patches are also welcome. Be warned, I haven't extensively tested this library yet.
It would be nice if we could customize the gamma curve. Different devices have different gamma. Some hardware even approximates the gamma curve with piecewise linear functions. This can make a massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 (typical office LCD screen), do some work on it, then convert to a gamma of 2.5 (typical TV - they assume TVs will be in a darker background setting), then the graphics card reads this as sRGB with its own piecewise linear approximation, then does some more work on it, and converts it back. Long story short, if you can't get all of those steps right the errors can add up quickly and becomes very noticable. If it could read photoshop colour profiles that would be even better. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862
On Fri, 24 Oct 2008, Sebastian Sylvan wrote:
It would be nice if we could customize the gamma curve. Different devices have different gamma. Some hardware even approximates the gamma curve with piecewise linear functions. This can make a massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 (typical office LCD screen), do some work on it, then convert to a gamma of 2.5 (typical TV - they assume TVs will be in a darker background setting), then the graphics card reads this as sRGB with its own piecewise linear approximation, then does some more work on it, and converts it back. Long story short, if you can't get all of those steps right the errors can add up quickly and becomes very noticable.
That is a fair point. I've only just started thinking about colour correction due to viewing environments. I remembered that dealing with colour was difficult (which is why I'm writing this library), but I forgot exactly how difficult it was. I just finished user defined linear RGB spaces in my development version. Allowing user defined non-linear RGB spaces would be a reasonable addition.
If it could read photoshop colour profiles that would be even better.
Perhaps ICC profiles would do? Or are they the same thing? -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
On Fri, Oct 24, 2008 at 8:12 PM, <roconnor@theorem.ca> wrote:
On Fri, 24 Oct 2008, Sebastian Sylvan wrote:
It would be nice if we could customize the gamma curve. Different devices
have different gamma. Some hardware even approximates the gamma curve with piecewise linear functions. This can make a massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 (typical office LCD screen), do some work on it, then convert to a gamma of 2.5 (typical TV - they assume TVs will be in a darker background setting), then the graphics card reads this as sRGB with its own piecewise linear approximation, then does some more work on it, and converts it back. Long story short, if you can't get all of those steps right the errors can add up quickly and becomes very noticable.
That is a fair point. I've only just started thinking about colour correction due to viewing environments. I remembered that dealing with colour was difficult (which is why I'm writing this library), but I forgot exactly how difficult it was.
I just finished user defined linear RGB spaces in my development version. Allowing user defined non-linear RGB spaces would be a reasonable addition.
Another useful predefined space which I didn't see is the YCoCg space, which is used in lots of compression schemes (like H.264 IIRC). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862
participants (3)
-
Don Stewart -
roconnor＠theorem.ca -
Sebastian Sylvan