  | |  | | ![]()  | Jaxe'd said: | | Or do you have a better idea, Cryo? Lol. |
You can always do what some other art programs do. Mix a selected color in a square box with a white gradient along one axis and a black gradient along the other. To select the hue, use a separate box containing a gradient of color mixing red into yellow, green, cyan, blue, magenta, and back to red. That should provide access to millions of colors. I made a simple demo of this yesterday evening...
cd/zips/Cryoburner/colorpick (19 Kb)
While you can select a hue by clicking on the bottom bar in this demo, I didn't include any sort of mouse pointer, so you'll have to guess a bit for its location. I didn't want to make the demo too complex and make it difficult to determine what it was going on, and I decided to get some sleep. : P
The code is split into two files. Colorpicktest is the example program, while colorpick is the library that draws the color gradient boxes. It also includes colormix, by Peterpaul and I, which offers fast and effective color mixing routines. The "fill color picker" routine draws a 256x256 square containing all brightness and saturation levels of a given hue. It mixes in white based on the pixel's x coordinate, followed by black based on its y coordinate. "fill hue picker" draws a 16 pixel wide bar containing a gradient of available hues.
Something like this could easily be considered overkill for a simple paint program though. Not many people are going to need direct access to thousands of brightness and saturation levels for each of hundreds of different hues. One option would be to merge them all into a single, more limited box. It could be similar to the hue box, only fading to black at the bottom, and white at the top, with the fully saturated color along the center. | |  | |  |
|
| | | | ![]() That's pretty cool... though I think I was getting hypnotized watching the numbers at the center. : P
Actually, that's roughly how my hue bar cycles between the colors, though I skip six hues at a time to make it fit in roughly the same amount of space as the brightness and contrast selector. I used the color mixer library, though that was mainly to keep the code easily readable. Since only one color channel changes at a time, it would likely be faster to flip through each channel manually.
One other thing to note about the single box method I mentioned earlier is that it won't include medium brightness low saturation colors, so it might be best to use a two box format. Another option would be to use three individual sliders to control the RGB values. Either way, you'll need to somehow display a three dimensional color space on a two dimensional screen. : ) | | | | |
|
| written by Jaxe'd on Nov 22, 2008 15:45 |
 | |  | | ![]() For these two programs, I set the width and height at 256 for good reason. The colors are created through simple math and each color channel can go from 0 to 255.
In [colors], the width demonstrates how much of the primary color is present at each pixel while the height demonstrates how much of the inverse color is present at each pixel.
The primary color being red, blue, or green at any given time while the inverse colors are cyan, yellow, or magenta (respectively).
With each palette able to show 65,536 colors each, one would assume it is possible to achieve all 16,777,216 colors by using the three different color channels separately ("...display a three dimensional color space on a two dimensional screen.")
This was the way I thought it would work while I was creating it. However, I did not realize that not all colors could be displayed through the process I used. Of course, that's why I am looking into the [color_morphing] program.
All this will definitely benefit LinoPaint greatly; I just have to work the bugs out and make it work correctly. : P
If I cannot find a way to implement the [colors] display into the [color_morphing] program, I may have to start a new prototype and find a different way to do it.
Meh, it's all good. Oh and I had to make the numbers print on the display so I could see what the actual color was at any given time (for bug-killing purposes). | | | EDIT | | | | | | Since nobody has responded yet, I'm going to post another thing I was working on.
It is similar to [color morphing] except that the way that it goes through all the colors is from 0 to 16777215 instead of each channel separately.
Program and source available here:
cd/zips/Jaxe'd/color_morphing_new (19 Kb) | |  | |  |
|
└> last changed by Jaxe'd on November 27, 2008 at 00:27
|
| written by Jaxe'd on Dec 01, 2008 22:05 |
| | | | ![]() I was thinking over the weekend about the name of the program. I don't really care too much for "LinoPaint" as a "clone of Microsoft Paint" (suggested by the Linoleum (programming language) Wikipedia page).
So, while thinking about it some, I thought instead of calling it Limp (Linoleum Image Manipulation Program). Yes, like Gimp (GNU Image Manipulation Program).
Anyway, it's a funny name and it would be far from a clone of Gimp, but it sounded better than LinoPaint to me. Feedback? | | | | |
|
| | | | Just popping into the Lino forum to say that I like the name. Think of the jokes someone could get out of that one...  | | | | |
|
| written by Jaxe'd on Dec 01, 2008 22:13 |
| | | | ![]() Yeah, I'm sure some jokes would come out of it, of course. I could probably create a witty program icon to match the name (PG-13 rated, at the worst) | | | | |
|
| | | | ![]() Hmm... not so sure I'm digging that name. : P | | | | |
|
|
