Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Color Chooser

edited August 2013 in Code Sharing Posts: 1,976

Well, here's my color chooser. I came up with it a little bit ago, and compressed it into an easy-to-use class. It has support for multiple touches, remembers which finger is controlling which part, has a nice little ring for choosing hue, a triangle that spins to your finger in the middle to choose saturation and value, and has a smart little bar on the side to handle alpha. Enjoy!

Installer: https://gist.github.com/SkyTheCoder/6176791

Source: https://gist.github.com/SkyTheCoder/ed1c139d64268c2c2f7b

Screenshot:

Color chooser

(Note: the square in the bottom shows you the color you chose and is drawn by Main, and is not actually part of the color chooser class.)

Comments

  • Posts: 2,160

    I must admit that I don't agree with using circles for the colour changer! The correct shape is a hexagon.

  • Posts: 1,976

    @Andrew_Stacey I don't under stand what you mean. I used a ring to choose hue easily, and it's used in many other color choosers.

  • Posts: 2,160

    @SkyTheCoder Just because everyone does it doesn't make it right!

    As you go round the colour wheel from red to green, the colour changes as follows:

    255,0,0 -> 255,x,0 -> 255,255,0
    255,255,0 -> x,255,0 -> 0,255,0
    

    Thus when you consider the RGB cube, what you are actually doing is traversing some of its edges.

    Find a cube. Got one? No, I really mean get a cube. Got one now? Good.

    Hold it so that one corner is down and the opposite is up. These are black and white respectively. The other corners are the primary and secondary colours, the primary are the lower three and the secondary are the upper three. As you move around the "colour wheel" then you are moving along the edges between these middle corners.

    Now look at the cube along the "white - black" axis. What shape do you see outlined?

    Circle - schmircle. Hexagons rule.

    (By the way, you can see my colour chooser in the Simply Complex app.)

  • edited August 2013 Posts: 1,976

    @Andrew_Stacey I honestly can't find a cube. Any chance you could draw one?

    Edit: Another problem is it will take me a bit to think up the vertex geometry for a hexagon (Don't tell me, I want to think of it myself!). And I have no idea how to make a collision hexagon (for touches.).

  • edited August 2013 Posts: 1,976

    @HyroVitalityProtago Ah... I see. Using a circle clips some of the edges a bit. Now for hexagon geometry and collision hexagons... I'll have to move it to the left a bit, too, as there isn't any way to put a hole in the middle.

  • edited August 2013 Posts: 1,976

    Hey, wait a minute... Doesn't my ring method work just as a hexagon would? If you look in the code, it essentially takes the edge pixels of the hexagon and stretches them to fit a circle. And then the saturation and value are handles by the triangle, and the bar for the alpha...

  • Posts: 2,160

    Yes, colour choosers work by projecting the hexagon onto the circle. The problem with this is that it gives the wrong "feel" to the user. They think they are smoothly choosing between colours when they are actually doing so in a piecewise linear fashion with "breaks" at the vertices.

    One place where the hexagonal method would make a difference is if you implemented a "nearest point" rather than "angle" method for choosing which point on the rim you are selecting.

    Try choosing "pure red" with your chooser. Now imagine doing it with a hexagonal chooser that uses the "nearest point" to determine the hue. You have a much bigger target.

  • Posts: 1,976

    Using the hexagon that @HyroVitalityProtago posted, my color chooser is much easier to choose pure red with. Just straight up, the area below the top of the circle is still red, too. Whereas with the hexagon, there's white in the center, so I would have to make sure I'm choosing the very top of the hexagon to get pure red.

  • Posts: 2,160

    No, you misunderstand. The hexagonal version still uses the border just as the circular one does. What HVP posted was the full RGB cube (projected onto a 2d plane), you don't use that. You take the boundary and make it thicker, just as with the circle.

    Incidentally, selecting a particular line in space is probabilistically as unlikely as selecting a particular point so you're wrong: you've no better chance of selecting pure red with yours as with HVP's cube.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Does any of this matter if we aren't building Photoshop, but a simple game for fun?

  • Posts: 1,976

    @Andrew_Stacey I agree with @Ignatz, but I have one last thing to say: when you talked about choosing red, you didn't say it took the border and expanded it, so I assumed you meant the full hexagon. In that case, It would have been easier using my version. After you explained, yes they are the same. So why are we arguing? But anyways, don't prove me wrong on something I didn't post about.

  • IgnatzIgnatz Mod
    Posts: 5,396

    I notice that Sketchbook Pro, a top line drawing app, and iDraw, which some of us use, both have circular colour wheels. Probably, UI design issues were important than technical accuracy, for them.

  • Posts: 2,820

    Looks great. Love it. This should be included in Cider.

  • Posts: 2,160

    @SkyTheCoder Why can't I prove you wrong about something you didn't post about? I didn't read that in the rules! But seriously, I mean no offence and my initial remark was an off-hand one.

    Nevertheless, I still think there is a case for a hexagonal chooser and I still want to explain why - I am sort-of a teacher, after all.

    Aesthetically, one can say that the circular one looks better and that's why most UI designers choose it (since when has a UI been designed by function over form?). Moreover, the situation in which it helps is precisely the one where one wants to choose a rough colour and thus not PhotoShop (whatever that might be) that @Ignatz talks about. In a proper drawing program (which I assume PhotoShop to be) then one will want the ability to precisely choose the colour and then no wheel is ever going to give you that ability.

    But I've lost count of the number of times I've tried to select precisely green or precisely blue in the Codea selector and failed miserably. The point is that when choosing a rough colour (that is, say I want "something vaguely orange") then I can be quite imprecise and so the error on touching a wheel (or hexagon) is not a bother. But even if most of the time I'm happy with an approximate colour, there are times when I want a precise colour and almost always those times are when I want one of the primary, secondary, or black, or white. This is where the hexagon model with the correct selection method triumphs because it allows you to select the primary and secondary colours precisely (black and white come from tinting so are fine in either model).

    Note the emphasised phrase.

    Here's how the correct selection method works. You start by touching the (hexagonal) wheel. This signals that you are going to select a hue. The exact hue chosen depends on where you stop touching. But you are allowed to stop touching anywhere on the screen, even off the wheel. Now, how does the code know what colour you meant to choose? The naïve way is to take the line from the centre to the touch point and see where it intersects the wheel. With this method both hexagon and circle give the same answer. But the more sophisticated way is to find the nearest point on the wheel to the touch point. Now it becomes much, much easier to select one of the corners and thus one of the primary or secondary colours.

    Let me illustrate with some ascii art. To make this drawable, I have to use a square but the principle is the same.


    _|_|_ _|_|_ | |

    In the above, there are nine regions. The middle square represents the colour "wheel". So when we finish touching the screen, the coordinate returned is the nearest point inside the middle square (or on its boundary if you prefer) to the touch point. The places we're interested in are the outer regions. If we end up in one of the edge squares then the selected point is simply the corresponding point on the nearest edge. But if we end up in one of the corner squares then the selected point is always the corresponding corner. So it is really, really easy to select a corner as there is a vast region of the screen where you can end up that will guarantee you the corner.

    So the hexagonal model is better because not all colours are equal, and the hexagonal model makes it easier to select the colours where it is more likely that you care about them being precise.

  • Posts: 2,160

    Perhaps I should add that while my colour chooser is hexagonal, it still uses the naïve selection method. When I get a minute, I'll fix that ...

  • Jmv38Jmv38 Mod
    Posts: 3,271

    @SkyTheCoder this discussion made me intrigated. So i downloaded your code and tried it: that is very nice. Startup is a bit slow, though.
    @Andrew_Stacey can you post your code here so i could see the difference? As for theoretical considerations, i though the CIE lab coordinates were the bottom line, and according to them the "good" way to define colors is a triangle of u' v' coordinates. Not a circle nor hexagon...

  • IgnatzIgnatz Mod
    Posts: 5,396

    @Andrew_Stacey - I might detect a touch on a circle or a hexagon by drawing it to memory and spriting it, then comparing the touch point with the memory image to get the exact pixel colour.

    Your explanation above would make a nice tutorial

  • Posts: 2,160

    Oh botheration! I just deleted a comment that looked like it had been double-posted (by me) and I can't figure out how to get it back.

    Anyway, the gist of it was a reply to @JmV38. Firstly, that CIELAB is a way of specifying a colour, not particularly of choosing it. We're working in RGB(A) space here since that's how Codea chooses to handle colours. Once we're in a model, we can discuss how best to choose a colour but changing models obviously changes how things work.

    In RGB space we're picking a point in a cube. There are various ways to do that, the circular wheel pretends that it is actually a cylinder and wraps that cylinder onto the cube. That obviously introduces breaks. The hexagonal model works a bit better because the breaks are already accounted for.

    The difference between triangular and hexagonal is not all that much, it just changes how you go from, say, red to green. Do you go via (255 - t,t,0) or do you first go (255,t,0) and then (t,255,0)? The first is a triangle, the second a hexagon.

    My code is freely available in the usual places, and you can use it in the Simply Complex app. But note that I hadn't thought about the "nearest point" bit until this discussion so it uses the naïve method of using the angle.

    @Ignatz That's what SkyTheCoder's code does. Isn't that a bit inefficient? Why not simply compute the angle subtended at the origin. I don't know, but I think that these get and set methods are not very fast and so I'd always prefer a "pure maths" approach to testing pixels in a sprite.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @Andrew_Stacey - When you're responding to a finger dabbing at the screen to choose a colour, I suggest you have all the time in the world to respond, so a pixel get is perfectly ok. It is also less complex for the less mathematical among us.

  • Posts: 2,160

    @Ignatz Actually, I disagree. It depends on what you're doing as that finger dabs. If you are continually updating something to show what the colour currently is (ie what the selection would be if the finger were lifted at that point) then you can't afford lagging. You need to be fully responsive to the movement of the finger otherwise it gets confusing for the user.

  • Posts: 1,976

    @Andrew_Stacey Dude, give it a rest. I honestly don't care if I use a circle or a hexagon. I don't care if it's "programmatically correct." If it's a simple drawing app, people will not care. It's easier to use a ring or a circle, it's easier to compute touches, and EVEN IF I USED A HEXAGON IT WOULD GET THE COLOR THE EXACT SAME WAY. There is no difference. Besides, this is MY color chooser, not yours. If you want to waste hours coding a hexagon nobody's going to care about, fine by me. I'm not going to, though. To me, a circle is the right way. It works for everyone else, colors don't have to be precise here. Quit beating a dead horse.

  • Posts: 382

    Ouch! Before @Andrew_Stacey and @SkyTheCoder murder each other I thought i'd put some of this in perspective. You're both right and both wrong.

    As a pro 3D Artist, i deal with colour every-day and I really couldnt give a monkeys if its a hexagon or a circle. What I do care about is being able to specify colour as HSV values rather than RGB which gives you a much greater degree of control. For most casual users mathematical precision really isn't hugely important as long as it looks 'kinda right'. Even in my day job I really cant resolve 16 million colour combos that accurately, but can make a good aesthetic decisions with the tools I have. :-D

    I think its very easy on this forum to get hung up on 'the correct way' of doing stuff. @SkyTheCoder should be applauded for developing something that works really well, and @Andrew_Stacey for his insight. Your both right and wrong.

  • Jmv38Jmv38 Mod
    Posts: 3,271

    Well, i dont know. What about a pentagon?
    :)) :)) :)) :)) :)) :))
    (sorry, i couldnt help it)

  • Posts: 382

    LOL @ Jmv38 - the voice of reason ;-)

  • Posts: 2,160

    @SkyTheCoder Calm down! I'm not telling you what to do and I never did. I've been trying to explain something and you're not the only one reading so it's not aimed at you. Often I find that I understand something more myself when I try to explain it to someone else so I often take the time to go through stuff in painful detail to ensure that I understand it. If anyone else does then that's just a bonus. I'm an academic, and a mathematician to boot, which makes me like a teacher only worse!

    So get used to discussions like these as they tend to happen a lot when I'm around.

  • Posts: 2,160

    @andymac3d I think you meant "You're both right and wrong." (Last sentence.)

    (Sorry, sorry - couldn't help myself.)

    Seriously, I'm curious as to why HSV gives you a much greater degree of control over HSV. Could you explain that?

  • edited August 2013 Posts: 382

    Did you mean HSV over RGB? Im not a big fan of colour wheels/hexagons/dodecahedrons etc.. per se. I think they can get you in the general area, but I get better control using individual HSV sliders than sliding over a grid of colour and hoping for the best.

    Indeed, a 'good' colour picker will give you multiple methods of selecting and modifying the colour - ideally with a colour wheel AND sliders. The 'better' ones give you the control of swapping between colour models with HSV/RGB/CMYK and LAB controls and mapping the values (when valid) across each. (p.s. Photoshop is often a good reference for most people in this respect, as its colour management is pretty good and flags 'gamut warnings' when you select a colour that cant be represented in another colour space).

  • Posts: 382

    @Andrew_Stacey - after re-reading your question I guess HSV tends to give me more control with creative clients. Especially with 'creatives' who talk in terms of 'de-saturating' tones and boosting the 'intensity' of colours. Although being able to swap into RGB mode gives me the ability to add another level of fine tuning if I need it.

  • Jmv38Jmv38 Mod
    edited August 2013 Posts: 3,271

    A 'good' color picker should even show your choice in a square over another bigger background square for whch you can choose the color too.... Color perception change strongly depending on what is around.

  • Posts: 1,976

    @Andrew_Stacey It did feel like you were aiming it at me, as it first started with you talking to me. But seriously, why did you keep pushing that hexagons were better than circles? They both would give the same result.

    @Jmv38 So basically two color pickers drawn on top of each other?

    @andymac3d Yes, RGB can give much higher precision than HSV, but the reason I used a HSV color picker here is because I was tired of using RGB sliders to choose colors, and wanted an easy-to-use color ring, for non-precise color choosing, just chosen by tapping on the H that looks nice, and then going into a bit more detail with S and V. I may add RGB sliders, too, though, for precision color choosing. But that's the problem, it's hard to choose a precise color with your big fingers fumbling around everywhere. (At least, fingers are big to your iPad. If you think about it, it must be pretty complicated, know the mass of pixels your finger is touching and trying to figure out the exact position.)

  • Posts: 2,160

    @SkyTheCoder No, they don't necessarily give the same result. They only do that if you use the naïve selection method that uses angle. If you use the "nearest point" selection method then they don't: the hexagon makes it easy to pick the primary and secondary colours. That's what I've been trying to get across (and, it seems, dismally failing).

    I "kept pushing", to use your phrase, because you made one fatal error. You used the phrase "I don't under stand [sic] what you mean.". To a teacher, that means that the discussion cannot end until you say "Oh, now I understand.".

    Moreover, have you ever known any discussion on these forums stick on topic? At least once it gets to about the 7th or 8th post?

  • Posts: 1,976

    @Andrew_Stacey Okay, I understand now. But anyways, I feel that a "nearest point" selection method would be too much of a hassle to set up, and people wouldn't tell the difference between it and trigonometry. Once again, my color chooser, not yours. If I feel I don't want to do it, then I won't.

    Also, you probably don't know this, but I'm homeschooled. To me, if I'm just not getting something, I can just stop. If I don't understand it after multiple explanations, I'm not going to.

  • Posts: 2,160

    @SkyTheCoder

    To me, if I'm just not getting something, I can just stop. If I don't understand it after multiple explanations, I'm not going to.

    I actually find that quite sad. But I'll stop going on about it now.

  • edited August 2013 Posts: 1,976
  • Posts: 1,595

    @SkyTheCoder The day you stop learning is the day you stop living, why would you ever just not do something because you couldn't do it the first couple times?

  • IgnatzIgnatz Mod
    edited August 2013 Posts: 5,396

    @luatee - I'm a lot older, and I do the same. If I have real trouble understanding something, I find it's often best to give it a break and come back later. I didn't read the comment as defeatist.

    And if I was SkyTheCoder's age, I wouldn't expect to be understanding advanced math just yet.... There's plenty of time for that later.

  • Posts: 1,595

    @Ignatz I believe SkyTheCoder is doing pretty advanced maths for his age, I in no way doubt that he's capable though, I didn't even know trigonometry at that age which leads me to think that the learning style of not breaking from a problem would be very beneficial to his learning but we all do things differently so its not something to expect, I know..

  • Posts: 108

    I downloaded and installed to check it out but am getting an error:

    ColorChooser:14: bad argument #1 to 'set' (number has no integer representation)
    stack traceback:
        [C]: in method 'set'
        ColorChooser:14: in field 'init'
        ... false
        end
    
        setmetatable(c, mt)
        return c
    end:24: in global 'ColorChooser'
        Main:4: in function 'setup'
    
    
  • dave1707dave1707 Mod
    Posts: 6,397

    In the set command, you have to do an integer divide by 1 ( //1 ) to get an integer passed to set. I didn't download the code so I don't know the whole command giving you the error.

  • dave1707dave1707 Mod
    Posts: 6,397

    I downloaded the code and it turns out there are a lot of (number has no integer representation) errors.

  • Posts: 213

    @dave1707 @AxiomCrux
    This is because either @John or @Simeon changed the functions image:set() and image:get(), they used to allow floats, but now they can only take integers, which means that they made this code before it was changed.

  • dave1707dave1707 Mod
    Posts: 6,397

    Heres a version that corrects the integer errors.

    -- Color Chooser
    
    supportedOrientations(LANDSCAPE_ANY)
    
    function setup()
        cc = ColorChooser()
    end
    
    function draw()
        background(40, 40, 50)    
        cc:draw()    
        fill(cc.pickedColor)    
        rect(0, 0, 100, 100)
    end
    
    function touched(touch)
        cc:touched(touch)
    end
    
    ColorChooser = class()
    
    function ColorChooser:init()
        self.DIST = 90    
        local size = 361
        local offset = 182    
        self.circle = image(size, size)    
        for hue = 1, 360, .5 do
            for len = 0, 0.06, 0.01 do
                for dist = 0, self.DIST do
                    self.circle:set(((math.sin((hue/180 * math.pi)+ len)*(180-dist))+offset)//1,
                        ((math.cos((hue/180 * math.pi)+ len)*(180-dist))+offset)//1,
                        color(self:HSVtoRGB(hue / 360, 1, 1)))                
                end
            end
        end    
        self.triangle = mesh()
        local len = 179 - self.DIST    
        self.triangle.vertices = {vec2(math.sin((2 * math.pi) / 3) * len, 
            math.cos((2 * math.pi) / 3) * len),vec2(math.sin(2 * ((2 * math.pi) / 3)) * len, 
            math.cos(2 * ((2 * math.pi) / 3)) * len),vec2(math.sin(2 * math.pi) * len, math.cos(2 * math.pi) * len)}    
        self.triangle.colors = {color(0, 0, 0),color(255, 255, 255),color(255, 0, 0),}    
        self.alpha = mesh()
        self.w, self.h = 50, 360
        self.x, self.y = 7 * (WIDTH / 8), HEIGHT / 2    
        self.alpha.vertices = {vec2(-(self.w / 2), -(self.h / 2)), vec2(-(self.w / 2), self.h / 2), 
            vec2(self.w / 2, -(self.h / 2)),vec2(self.w / 2, self.h / 2), vec2(self.w / 2, -(self.h / 2)), 
            vec2(-(self.w / 2), self.h / 2),}    
        self.alpha.colors = {color(0, 0, 0, 0), color(255, 0, 0, 255), color(0, 0, 0, 0),
            color(255, 0, 0, 255), color(0, 0, 0, 0), color(255, 0, 0, 255),}    
        self.ANGLE = 0
        self.ON_RING = false
        self.RING_ID = 0
        self.ON_TRIANGLE = false
        self.TRIANGLE_ID = 0
        self.ON_ALPHA = false
        self.ALPHA_ID = 0
        self.screen = image(WIDTH, HEIGHT)
        self.alphaScreen = image(self.w, self.h)
        self.pickedColor = color(255, 0, 0, 255)
    end
    
    function ColorChooser:draw()
        pushStyle()
        pushMatrix()    
        noStroke()    
        self.triangle.colors = {color(0, 0, 0),color(255, 255, 255),
            color(self.circle:get(((math.sin(-self.ANGLE) * 170) + 181)//1, 
            ((math.cos(-self.ANGLE) * 170) + 181)//1)),}    
        local r, g, b = self.pickedColor.r, self.pickedColor.g, self.pickedColor.b
        local col = color(r, g, b, 255)    
        self.alpha.colors = {color(0, 0, 0, 0), col, color(0, 0, 0, 0),col, color(0, 0, 0, 0), col,}    
        translate(WIDTH / 2, HEIGHT / 2)
        rotate(math.deg(self.ANGLE))
        self.triangle:draw()
        resetMatrix()    
        setContext(self.screen)    
        background(0, 0, 0, 0)
        translate(WIDTH / 2, HEIGHT / 2)
        rotate(math.deg(self.ANGLE))
        self.triangle:draw()
        setContext()    
        resetMatrix()    
        sprite(self.circle, WIDTH / 2, HEIGHT / 2)    
        translate(self.x, self.y)    
        self.alpha:draw()
        resetMatrix()    
        setContext(self.alphaScreen)
        background(255, 255, 255, 0)    
        translate(self.w / 2, self.h / 2)    
        self.alpha:draw()    
        resetMatrix()    
        setContext()    
        popStyle()
        popMatrix()
    end
    
    function ColorChooser:touched(touch)
        local tx, ty = touch.x, touch.y
        local xc, yc = WIDTH / 2, HEIGHT / 2
        local a, b, c, d = 90, 90, 180, 180
        if touch.state == BEGAN and touch.id ~= self.RING_ID and touch.id ~= self.ALPHA_ID and 
                not self.ON_TRIANGLE and (ty-yc)^2/b^2+(tx-xc)^2/a^2 <= 1 then
            self.ON_TRIANGLE = true
            self.TRIANGLE_ID = touch.id        
            if color(self.screen:get(touch.x//1, touch.y//1)).a ~= 0 then
                self.pickedColor = color(self.screen:get(touch.x//1, touch.y//1))
            end
        elseif touch.state == BEGAN and touch.id ~= self.TRIANGLE_ID and touch.id ~= self.ALPHA_ID and 
                not self.ON_RING and (ty-yc)^2/d^2+(tx-xc)^2/c^2 <= 1 then
            self.ON_RING = true
            self.RING_ID = touch.id
            self.ANGLE = math.atan2(touch.y - (HEIGHT / 2), touch.x - (WIDTH / 2)) - (math.pi / 2)
        elseif touch.state == BEGAN and touch.id ~= self.RING_ID and touch.id ~= self.TRIANGLE_ID and 
                not self.ON_ALPHA and touch.x >= self.x - (self.w / 2) and touch.y >= self.y - (self.h / 2) and 
                touch.x <= self.x + (self.w / 2) and touch.y <= self.y + (self.h / 2) then
            self.ON_ALPHA = true
            self.ALPHA_ID = touch.id
            local r, g, b, a = self.alphaScreen:get(
                (math.max(1, math.min(self.w, touch.x - (self.x - (self.w / 2)))))//1, 
                (math.max(1, math.min(self.h, touch.y - (self.y - (self.h / 2)))))//1)
            self.pickedColor.a = a
        end    
        if touch.state == MOVING and self.ON_RING and self.RING_ID == touch.id then
            self.ANGLE = math.atan2(touch.y - (HEIGHT / 2), touch.x - (WIDTH / 2)) - (math.pi / 2)
        elseif touch.state == MOVING and self.ON_TRIANGLE and self.TRIANGLE_ID == touch.id then
            if color(self.screen:get(touch.x//1, touch.y//1)).a ~= 0 then
                self.pickedColor = color(self.screen:get(touch.x//1, touch.y//1))
            end
        elseif touch.state == MOVING and self.ON_ALPHA and self.ALPHA_ID == touch.id then
            local r, g, b, a = self.alphaScreen:get(
                (math.max(1, math.min(self.w, touch.x - (self.x - (self.w / 2)))))//1, 
                (math.max(1, math.min(self.h, touch.y - (self.y - (self.h / 2)))))//1)
            self.pickedColor.a = a
        end    
        if self.ON_RING and self.RING_ID == touch.id and (touch.state == ENDED or touch.state == CANCELLED) then
            self.ON_RING = false
            self.RING_ID = 0
        elseif self.ON_TRIANGLE and self.TRIANGLE_ID==touch.id and (touch.state==ENDED or touch.state==CANCELLED) then
            self.ON_TRIANGLE = false
            self.TRIANGLE_ID = 0
        elseif self.ON_ALPHA and self.ALPHA_ID==touch.id and (touch.state==ENDED or touch.state==CANCELLED) then
            self.ON_ALPHA = false
            self.ALPHA_ID = 0
        end
    end
    
    -- From a guest on pastebin.com.
    -- Slightly modified indentations to look prettier.
    -- URL: http://pastebin.com/NrcJgL1d
    
    ----------------------------- 
    -- HSV > RGB color conversion
    ----------------------------- 
    -- adapted from: 
    -- http://mjijackson.com/2008/02/rgb-to-hsl-and-rgb-to-hsv-color-model-conversion-algorithms-in-javascript
    -----------------------------
    
    function ColorChooser:HSVtoRGB(h, s, v)
        local r, g, b    
        local i = math.floor(h * 6)
        local f = h * 6 - i
        local p = v * (1 - s)
        local q = v * (1 - f * s)
        local t = v * (1 - (1 - f) * s)
        local switch = i % 6    
        if switch == 0 then
            r,g,b=v,t,p
        elseif switch == 1 then
            r,g,b=q,v,p
        elseif switch == 2 then
            r,g,b=p,v,t
        elseif switch == 3 then
            r,g,b=p,q,v
        elseif switch == 4 then
            r,g,b=t,p,v
        elseif switch == 5 then
            r,g,b=v,p,q
        end   
        return math.floor(r * 255), math.floor(g * 255), math.floor(b * 255)
    end
    
  • Posts: 108

    is there a reason to not allow both? is it a substantial optimization / speed increase?

    seems like a precompiler pass type conversion could achieve the same thing?
    why not allow 32 bit image buffers/color space? It is very useful for certain techniques and especially high end visual quality to have float32 buffer option for shaders and image processing techniques, and seems in the spirit of Lua to provide implicit type management.

    @dave1707 @John @Simeon

Sign In or Register to comment.