Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add components-a?rgb with tests #2
I wanted to visualize a PRNG this morning and found imagez. It's great!
I noticed that
The docstring said that the functions would return doubles, but it seems more in keeping with the rest of the library to simply return longs, the return type of bit-ops on long inputs.
Cool looks good. Just one quick question - any reason you prefer longs over doubles?
I ask because in most of my image-processing work I've found it much easier to work with colour values normalised to the 0.0 - 1.0 range (e.g. in https://github.com/mikera/clisk). It's much easier to do thing like colour adjustments, mask multiplication etc. without having to worry about renormalising all the time, surely?
In my case it was easier to work with fixed values, but it was a very precise task.
There are two considerations here:
If you are hooking up a user-interface element like a knob, slider, or even image processing API to colour data, then floats have the natural advantage in "feel" and arithmetic simplicity.
However, I would expect a function called #'components-argb to return the discrete components of the colour bitfield so that I may do precise calculations (steganographic messages, for instance).
Perhaps there should be just one low-level function that returns a long-array (or byte-array) of the four components for people who want discrete values, and a higher-level version that returns a vector of doubles? (and a couple of conversion functions)
added a commit
this pull request
Jul 31, 2013
BTW, I just realized the fn would be prettier as:
[(-> argb (bit-and 0xFF000000) (bit-shift-right 24)) (-> argb (bit-and 0x00FF0000) (bit-shift-right 16)) (-> argb (bit-and 0x0000FF00) (bit-shift-right 8)) (-> argb (bit-and 0x000000FF))]
but I got to you too late.
I think you should change the fns next time you touch the namespace.