New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add components-a?rgb with tests #2

Merged
merged 1 commit into from Jul 31, 2013

Conversation

Projects
None yet
2 participants
@guns
Copy link
Contributor

guns commented Jul 31, 2013

Hello,

I wanted to visualize a PRNG this morning and found imagez. It's great!

I noticed that components-a?rgb were unimplemented, so I decided to whip up a simple implementation.

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.

Thank you!

@mikera

This comment has been minimized.

Copy link
Owner

mikera commented Jul 31, 2013

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?

@guns

This comment has been minimized.

Copy link
Contributor Author

guns commented Jul 31, 2013

In my case it was easier to work with fixed values, but it was a very precise task.

It's much easier to do thing like colour adjustments, mask multiplication etc. without having to worry about renormalising all the time, surely?

There are two considerations here:

  • User interface
  • Underlying discrete values

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)

@guns

This comment has been minimized.

Copy link
Contributor Author

guns commented Jul 31, 2013

BTW, it may just be that imagez is the wrong tool for the things I am doing. If returning doubles makes more sense for the library, I have no objections. Just wanted to complete those two functions for you.

mikera added a commit that referenced this pull request Jul 31, 2013

Merge pull request #2 from guns/colour-components
Add components-a?rgb with tests

@mikera mikera merged commit 17f70e9 into mikera:master Jul 31, 2013

1 check passed

default The Travis CI build passed
Details
@mikera

This comment has been minimized.

Copy link
Owner

mikera commented Jul 31, 2013

OK sounds fair. I'll merge these as is. We can always add separate functions for getting the double components.

Thanks!

@guns

This comment has been minimized.

Copy link
Contributor Author

guns commented Jul 31, 2013

Thank you!

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment