Re: [Haskell] ANNOUNCE: colour 0.0.0
On Wed, Oct 22, 2008 at 1:12 AM, [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: colour 0.0.0
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.'' ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: colour 0.0.0
On Fri, Oct 24, 2008 at 8:12 PM, [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: [Haskell] ANNOUNCE: colour 0.0.0
On Fri, 24 Oct 2008, Sebastian Sylvan wrote: 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). YCoCg, like HLS and HSV, seems to not really be a colour space because it isn't well specified. A transformation is given from some unknown RGB space. Perhaps I should make a datatype for unknown RGB triple, and create HLS HSV, and YCoCg transforms from this type. I can have toRGB709 and toSRGB take and return this unknown RGB triple type. This would suggest changing sRGB and rgb709 from the type sRGB :: a - a - a - Colour a to sRGB :: RGB a - Colour a so the code sRGB r g b becomes sRGB (RGB r g b). That doesn't seem very nice. Also, I could add phantom type annotations to the RGB triple type, allowing it to be labeled as linear, or nonlinear, or other information. -- 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.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANNOUNCE: colour 0.0.0
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. In Arch, http://aur.archlinux.org/packages.php?ID=20927 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: [Haskell] ANNOUNCE: colour 0.0.0
On Wed, 22 Oct 2008 02:12:05 +0200, [EMAIL PROTECTED] 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. I think it would be nice to have conversion functions for wxHaskell and the like, to convert between the different color representations. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANNOUNCE: colour 0.0.0
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.'' ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
