ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

[Andrew Coppin]

OK, so having released AC-HalfInteger, I got slightly carried away and
released three other small packages. These are packages that many
programs I write all end up using. I'm forever copying these files, so I
made them into actual bonafide packages.


http://hackage.haskell.org/package/AC-Vector-1.1.1

This provides two types, Vector2 and Vector3, which are unboxed vectors
of Doubles, with arithmetic, dot product and cross product, and a few
other useful items.


http://hackage.haskell.org/package/AC-Colour-1.1.1

This provides two types, Colour and Colour8. Both implement simple RGB
colour types with arithmetic. Colour has unboxed Double fields, and
Colour8 has unboxed Word8 fields. My usual workflow is to do all the
image generation with Colour, and to convert to Colour8 just before the
data hits the I/O channels. You can, however, do arithmetic directly on
Colour8. (I haven't extensively tested that it works properly though...)


http://hackage.haskell.org/package/AC-EasyRaster-GTK-1.1.1

This is a layer over Gtk2hs. As you all probably know, Gtk2hs provides a
Cairo binding that makes vector graphics wonderfully easy. However,
*bitmapped* graphics is darned tricky. I basically had to sit in the
#haskell channel with Duncan for a few hours trying to figure out how
the hell to do it. This knowledge is now codified in the above package.
Load it up and you don't need to know a thing about GTK; you can just
create an ImageBuffer, write some pixels to it (efficiently!), save it
to disk or display it on screen. (But you *can* access the underlying
GTK+ resources if you wish...)


In other news, it appears that the batch job to generate the
documentation just ran, so you can view it all online. :-D

Comments, suggestions, random flames, etc...

[I'm particularly curios to know what Duncan will make of the GTK thing...]

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Felipe Lessa]

On Sat, Jul 04, 2009 at 06:56:44PM +0100, Andrew Coppin wrote:
> http://hackage.haskell.org/package/AC-Colour-1.1.1

Why don't you use colour[1]?

[1] http://hackage.haskell.org/package/colour

--
Felipe.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Andrew Coppin]

Felipe Lessa wrote:
> On Sat, Jul 04, 2009 at 06:56:44PM +0100, Andrew Coppin wrote:
>  
>> http://hackage.haskell.org/package/AC-Colour-1.1.1
>>    
>
> Why don't you use colour[1]?
>
> [1] http://hackage.haskell.org/package/colour
>  

A few reasons:

1. I never knew it existed. ;-)

2. It's mind-blowingly complex.

3. It doesn't appear to provide arithmetic over colours.

4. It's parameterised over the component type; my library is hard-coded
to specific types for speed.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Max Rabkin-2]

On Sat, Jul 4, 2009 at 8:38 PM, Andrew
Coppin<andrewcoppin@...> 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?

> 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 :)

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

> 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?

BTW, the EasyRaster package looks useful.

--Max
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Andrew Coppin]

Max Rabkin wrote:

> On Sat, Jul 4, 2009 at 8:38 PM, Andrew
> Coppin<andrewcoppin@...> 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.
>  

Fair enough. ;-)

> 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?
>  

Well, for example, there's seemingly half a dozen unrelated packages all
called "binary", which is just confusing. I wanted to make sure my
packages had unique names. (I mean, so do the existing binary packages,
just not very useful ones...)

>> 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. ;-)

>> 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?

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

> BTW, the EasyRaster package looks useful.
>  

Well, I'd like to think so... It doesn't do anything you couldn't do
yourself if you spend a day or two trying to grok the GTK complexity.
But it's much easier to just import some code somebody else has already
written. ;-) Certainly when I'm in the middle of trying to build a
complicated bit of software, figuring out how to just write a few pixels
onto the screen is a low priority.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Max Rabkin-2]

On Sat, Jul 4, 2009 at 9:18 PM, Andrew
Coppin<andrewcoppin@...> wrote:
>>> 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.

The sRGB function makes a Colour from RGB (actually sRGB, which is a
"standardised" RGB -- basically RGB where the exact frequency and
power of each channel is specified -- but you can pretend your
monitor's RGB is sRGB.

> So mappend gives you colour addition [with the perplexing comments about
> "gamut", presumably some kind of small mammal?]

The gamut of a device is the range of representable colours (a
monitor's gamut looks something like a parabola with a flat base in
XYZ space, whereas a printer's is much more complex and variable).
This makes sense. If you double a monitor's brightest white, you don't
get a colour twice as bright: you get the same colour.

> but there's no subtraction?
> No multiplication? No linear blending?

affineCombo can do subtraction, again with the gamut warning. darken
does scalar multiplication; it probably doesn't do componentwise
multiplication, which doesn't make much sense if you're trying to work
in a coordinate-independent setting, though I admit RGB-multiplication
can be handy.

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

Fair enough. Can your implementation not be turned into a patch?

BTW, I'm also working on Haskell fractals. You might be interested in
looking at my fractal package (though it's currently undocumented, and
has no GUI).

--Max
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Andrew Coppin]

Paul Johnson wrote:

> Andrew Coppin wrote:
>> 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. ;-)
> Your display may not be calibrated, but those used for graphic design
> certainly are.

Indeed. And if you're in any kind of position where you *care* about
such things, you should be using color, not AC-Colour. If, however, you
just want to throw together pretty pictures, AC-Colour is simpler and
easier. Different libraries for slightly different tasks. ;-)

> On the package naming front: I appreciate your wish to avoid just
> having another "colour" library.  But "AC_Colour" doesn't help much.  
> "Simple_colour" might be better.

Mmm, yeah. Naming everything with "AC" precludes name clashes and
doesn't require too much thinking. Coming up with a better name requires
thinking about what actually makes your package unique. And, of course,
if another package comes along, that analysis may change. (E.g., I seem
to recall there's a "newbinary" package which has actually been long
since superceeded - so not so "new" any more!) If I name my package
simple-colour, and then somebody else makes an even simpler one... the
name becomes kind of meaningless. (Admitedly there's not too much danger
of this happening...)

I just like the idea of having definitely unique, distinctive package
names. Otherwise I'd have to come up with stuff like geovector and
trivicolour and so on... Arguably EasyRaster-GTK should have been a
sufficiently unique name by itself though.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Brandon S. Allbery KF8NH]

On Jul 4, 2009, at 15:01 , Max Rabkin wrote:
> On Sat, Jul 4, 2009 at 8:38 PM, Andrew
> Coppin<andrewcoppin@...> wrote:
>> 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.

I don't see a good meaning for signum offhand, but fromInteger could  
take an X11-encoded RGB value and abs could produce grayscale  
brightness.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@...
system administrator [openafs,heimdal,too many hats] allbery@...
electrical and computer engineering, carnegie mellon university    KF8NH




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe