[Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

roconnor at theorem.ca roconnor at theorem.ca
Thu Jul 9 23:26:54 EDT 2009


> Max Rabkin wrote:
>> On Sat, Jul 4, 2009 at 8:38 PM, Andrew
>> Coppin<andrewcoppin at btinternet.com> wrote:
>> 
>>> A few reasons:
>>> 
>>> 1. I never knew it existed. ;-)
>>> 
>> 
>> A good reason. However, it's good to do a quick search over Hackage
>> before uploading (or before writing) so you know what's out there.
>> 
>> Also, if you hadn't used an "AC-" prefix, you'd have had a name
>> collision. Is there a particular reason why you want your name in the
>> package name rather than just the author field?
>>

I find it amazing that you independently chose to spell colour with a `u'. 
It makes me feel better about my choice.

>>> 2. It's mind-blowingly complex.
>>> 
>> 
>> Colour *is* complex. Which is why I'm so glad Russell O'Connor did all
>> the hard work for me :)
>> 
>
> Well, no, because now I'm going to have to spend a few hours trying to
> find out what CIE is before I can even use that library.
>
> I think really it's just aimed at a different problem. It looks like
> it's trying to specify actual real-world colours. [It's news to me that
> this isn't fundamentally impossible...] I'm only trying to specify
> colours on a computer screen. And as we all know, computer screens
> aren't calibrated in any way, and the same RGB value looks different on
> each display. But then, I'm only trying to write a fractal generator, so
> CIE specifications are somewhat overkill here. ;-)

You can use by lib without worrying about the CIE.  You can use my library 
without ever importing or using the word CIE.  However, the CIE stuff is 
there for those who need it.

Perhaps I (maybe with some help) need to make a tutorial on the haskell 
wiki to try to make it less intimidating.

>>> 3. It doesn't appear to provide arithmetic over colours.
>>> 
>> 
>> It provides darken, blend and addition (though addition is called
>> mappend rather than (+)). signum, abs and fromInteger don't make a
>> huge amount of sense for colours.
>> 
>
> Yeah, I implemented signum and so forth for colours and vectors, but
> they're not particularly meaningful... [Insert remark here about
> Haskell's numeric class hierachy.]
>
> So mappend gives you colour addition [with the perplexing comments about
> "gamut", presumably some kind of small mammal?], but there's no
> subtraction? No multiplication? No linear blending?

Linear blending is done by the affineCombo function.

I think the darken function will do what you mean by multiplication

Colour subtraction can be done by adding (using mappend) a colour that has 
been darkend by a factor of (-1).  I don't believe there is any demand for 
a colour subtraction fuction, so I don't have a name for it.

I suppose these sorts of questions can be put nicely into a short tutorial 
on the wiki.

>>> 4. It's parameterised over the component type; my library is hard-coded 
> to
>>> specific types for speed.
>>> 
>> 
>> My feeling would be to trust the specializer until it lets me down.
>> Has it let you down in the past?
>> 
>
> Heh, my colour library includes a custom floor implementation that talks
> to the GHC primops directly because calling floor is too slow...
>
> [In case that sounds like idle talk, I had a program go from 10 seconds
> to less than 1 second just by using this function. There's a few tickets
> about it on the GHC Trac.]

Certainly speed is an issue that I haven't tackled yet since I don't know 
too much about how to optimized Haskell code.  I was thinking of 
sprinkling in some SPECIALIZE pragmas and maybe adding some RULES to make 
operations more effecient.  For example we could have a rule to rewrite 
floor to some sort of GHC specific fast floor function. (Although that 
rule probably deserves to be in some sort of more general location).

Any help in this direction would be appricated (perferably while keeping 
things as portable as possible).

This all being said, the major problem my code solves is doing blending in 
a linear colour space. This necessarily make converting to non-linear sRGB 
for output much slower. So for people who want speed over proper blending, 
then probably AC-Colour is the package they need to reach for.

Essentially the two packages do fill different niches!

>> BTW, the EasyRaster package looks useful.
>>

I haven't looked at EasyRaster yet, but I got excited when I saw it 
announced. :)

-- 
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.''


More information about the Haskell-Cafe mailing list