Connect with us

Color Sensor

Discussion in 'Electronic Design' started by Quack, Apr 15, 2004.

Scroll to continue with content
  1. Quack

    Quack Guest


    I am considering using a CCD chip (omnivision OV6620 or something else
    if easier?) interfaced to a SX chip to give me a color sensor.

    I have posted about color sensors before, but could not accomplish
    what i needed - i think taking 'average color' readings from a
    'defined window' within a CCD image would be great.

    Never having attempted this before, anyone have any tips ?
    Something to make it easier ? perhaps a different CCD chip ?

    I know of the CMUCam, which does what i want - and this is the CCD
    they use, and the SX is the controller they use - but i cant use their
    product :(.
    Its too slow (not enough FPS, as its doing so much other processing,
    blob tracking etc), and its for a kind of commercial use.

    any help would be appreciated before i waste too much time :),

  2. Ian Stirling

    Ian Stirling Guest

    What are you trying to make?
    If it plugs into a PC, software is probably easier.

    You also need to think about what colour is, and how you take its average.
    This is a very non-trivial subject, as it depends on pattern, texture,
    lighting, and even person-person variations.
  3. Jim Nagy

    Jim Nagy Guest

    It will be a lot of work to do this from scratch. Have you seen the
    colour to frequency converters sold by TAOS? I haven't used them, but
    they sure look interesting.
  4. Pat Ford

    Pat Ford Guest

    Years ago PE did a project that used different coloured leds, and a few
    photo transisters. These were all in a probe
    and the leds binked one at a time and the output of the phototrans was
    measured. would that work for you?
  5. Garrett Mace

    Garrett Mace Guest

    The following full-color sensor has been out since 1998:

    3 millisecond response time. I don't think you'll get 333fps from a CCD, not
    to mention processing all of the pixels and computing an average in real

    If you need to get an average color of a large area, use a three-color
    sensor, perhaps three phototransistors behind filters, and investigate lens
  6. One way to dio color from a webcam is to decide to YUV (it likely already is
    YUYV), and then look at the U and V for the area you want.
    Those form 2 90 degree apart vectors, and the vector sum is a pointer in
    a color circle.
    If both U and V are zero, there is no color (black -grey-white).
    Best way top represent the results are in a color circle.
    You can of cause use a vector angle too, like vectorscope.
    Or you could assign names to the colors and display on a LCD the real color
    names (these lists exist for example in Linux).
    I wrote al that soft, and in fact there is a chroma key in for example
    mcam and also in subtitler
    Here I just use the result to key an other signal.
    You can think of all sort of fancy ways to display the result.
    You can average over more then one frame, or use a small area of a frame.
    I would need to know more specifics, but the system is simple.
  7. Zak

    Zak Guest

    Problem is that the webcam may have soem auto white balance function
    that will always make the overall result neutral grey.

    In any case I'd suggest 3 LEDs and a single sensor. I have a
    light-tp-frequency converter chip (TSL230) here on my desk. With the 3
    LEDs connected to a parallel printer port and some programming one would
    have a decent color sensor.

    Of courseyou need to keep the LED current constant, take care of surface
    gloss, and recalibrate for LED aging.

  8. Quack

    Quack Guest

    What are you trying to make?
    No it does not connect to a PC, it must be accomplished within
    firmware on an MCU, as it is a stand-alone device. :(
    Yes i know that, im not looking for anything too discriminating.
    The environment is very specific, and there will be about 80% color
    infront of the lense at any one time, and only 3 different color
    states to detect (green, red, black) at a distance of about 15cm.
    A pixel average would work just fine.
  9. Quack

    Quack Guest

    It will be a lot of work to do this from scratch. Have you seen the

    They look fantastic! loads of google searching for 'color sensor'
    never turned up something so wonderful! thanks. :)

    I especially like the 'color sensor' right below the FTL chip.
    Perhaps using a couple of these 'filtered' and mounted behind light
    proof tubes pointed at what i want.
    Measurement distance must be 100-150mm this is what im worried about.
  10. Quack

    Quack Guest

    Years ago PE did a project that used different coloured leds, and a few

    Actually i have done that kind of stuff, and it works nice and simply.
    but its no good for a distance of 100-150mm in ambient and
    uncontrolled lighting conditions.
  11. Quack

    Quack Guest

    One way to dio color from a webcam is to decide to YUV (it likely already is
    Very interesting, i will keep this in mind if i try to interface
    directly to a CCD, as i believe that comes of as YUV. But i will keep
    it in firmware.

    I wonder if i need to go into such complexity, and the detecting
    environment will not change, i never need to define 'new colors', or
    know what those colors actually are in real life - i just need to know
    if COLOR_VALUE_X (plus or minus error margin) is present, and if
    COLOR_VALUE_Y (again plus or minus error) is present.

    where VALUE_X or Y are only defined in development, and never again
    need to be related to an 'actual color'.
    So this could be fairly hard coded (perhaps the 'error margin' can be
  12. Quack

    Quack Guest

    In any case I'd suggest 3 LEDs and a single sensor. I have a
    How would this go at a distance of 100-150mm ?

    it will not be reading the color of an 'object' as much as a

    What i mean, is that this device will be mounted in such a way that
    all it sees is a surface 100-150mm away, and this surface changes
    color, (slides past).

    So this surface would take up 100% of the 'view' of the sensor by
    using a suitable optical mounting. (chip-in-a-tube? :) ).

    I guess LED's may be okay.. perhaps.
  13. Ian Stirling

    Ian Stirling Guest

    It doesn't.
    It generally comes off as simple pixel values from pixels coloured by
    red-green-blue filters in a
    GB pattern.
    It's then up to you to work out the colour.
    A few imagers use cyan-magenta-yellow, not RGB.
  14. Ian Stirling

    Ian Stirling Guest

    Quite well.
    They key is not to keep the LED current constant, as that will cause major
    problems with stray light, but to modulate each one at a constant power,
    and frequency. (square waves are OK if you pick the frequencies right)

    For example, red is modulated at 10Khz, green at 12Khz, and blue at 14Khz.

    A filter that passes 9-15Khz or so, gives nice sine-waves at the output,
    and then filters that pass 10,12,14Khz before detecting the value.

    If the filters are narrow enough, you can put lots of amplification
    first, not caring overmuch about its noise.

    This can buy you lots in terms of signal-noise, and be immune to external

    An alternative, though slightly trickier to get right is to replace the
    filters with switches that change the signals polarity in phase
    with the various LEDs current, this then gives a DC output of the intensity.

    This is much less sensitive generally.

    Ensure that the LEDs have even light output over the field of view of the
    sensor, and that the light sensor is not overloaded by ambient light.
  15. John Fields

    John Fields Guest

    What I'd do would be to put a couple of phototransistors at the ends
    of tubes with filters (red in one and green in the other) in front of
    them, and locate the phototransistors far enough back in the tubes
    that they only see the field of view they need to. Also, I'd point
    the ends of the tubes so that their fields of view were concentric.
    Then, when the different colors go sliding past you'll get an output
    from the red sensor (but none from the green sensor) when a red
    surface slides by, an output from the green sensor (but none from the
    red sensor) when a green surface slides by, and no output from either
    sensor when black goes sliding by.
  16. The UV are normally 8 bits signals, with bit 8 the signs bit.
    So a BW pic would give you about 127 127.
    If you do a compare you could do it like this, a routine that has
    rgb input, converts it to yuv, then calculates an angle in the color
    circle, and sets a pointer in a dial in the display.
    It works, but is rather old code, was me experimenting :)
    I also have the reverse somewhere from angle to rgb.

    For just ONE color you could just set a window for U and V, and
    test if both values are in that window.
    But maybe this shows that color circle concepts is simple.

    int set_color_circle(int r, int g, int b)
    char temp[80];
    double radians, degrees;
    int y, u, v;
    double dvector, dsine, du, dv, ds;

    /* rgb to yuv */
    y = (0.257 * (double)r) + (0.504 * (double)g) + (0.098 * (double)b) + 16.0;

    u = (0.439 * (double)r) - (0.368 * (double)g) - (0.071 * (double)b);

    v = -(0.148 * (double)r) - (0.291 * (double)g) + (0.439 * (double)b);

    The U and V signals were intended for quadrature modulation on the 4.43
    PAL carrier, lets do it:
    color vector, angle alpha sets color, amplitude sets saturation
    u /
    |/ alpha
    -v -- -- v

    /* no color no action, prevent nan */
    if( (u == 0) && (v == 0) ) return 0;

    /* u v to angle */

    /* calculate the vector amplitude (hypotenusa) */
    du = (double)u;
    dv = (double)v;
    dvector = sqrt( (du * du) + ( dv * dv ) );

    /* calculate the sine */
    dsine = (du / dvector);

    /* dsine must be in the range -1 to +1, else errno. */

    /* get the vector angle */
    errno = 0;
    radians = asin(dsine);
    if(errno == EDOM)
    perror("subtitler(): rotate_color(): asin NOT A NUMBER :)");

    /* abort */

    /* -PI/2 to +PI/2 radians = -90 to + 90 degrees. */
    degrees = radians * (180.0 / M_PI);
    /* degrees now -90 to + 90 */

    dvector is always positive, now we can say:
    if we are in the top right quadrant then u and v are positive, so dsine is positive.
    in the bottom right quadrant then u is negative and v is positive, so dsine is negative
    in the bottom left quadrant then u is negative and v is negative, so dsine is negative
    in the top right quadrant then u is positive and v is negative. so dsien is positive.
    dsine does not know about when v is negative.
    If v is negative we have to add 180 degrees to the result off asin..

    degrees += 90;
    /* now 0-180 */

    if(v < 0) degrees = 360 - degrees;

    fl_set_dial_value(fdui -> global_subtitle_palette_form_color_circle_dial, degrees);

    sprintf(temp, "%02f", degrees);
    fl_set_input(fdui -> global_subtitle_palette_form_color_circle_input, temp);

    } /* end function set_color_circle */
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day