Binary Image processing library

Discussion in 'C Programming' started by Malcolm McLean, Aug 11, 2012.

  1. My binary image processing library has gradually been building up.
    The time has come to ask for suggestions and comments. The idea is
    to provide a C language resource for people with a need to handle
    binary images.

    http://www.malcolmmclean.site11.com/www/BinaryImageProcessing/binarylibrary.html

    Obviously one priority is that everything is in portable ANSI C.
    Another is that the interfaces are clean, and functions can be cut and pasted
    with a minimum of fuss if people don't want to use the entire library.
    Malcolm McLean, Aug 11, 2012
    #1
    1. Advertising

  2. Malcolm McLean

    Guest

    , Aug 12, 2012
    #2
    1. Advertising

  3. Malcolm McLean

    Guest

    Vincenzo Mercuri wrote:
    > What's the problem with his terminology? You only need to know what
    > a "binary image" is: http://en.wikipedia.org/wiki/Binary_image


    That refers to two-colour images, the OP's link discussed
    multi-coloured images.

    > "binary image processing library" is proper wording.


    A binary image could be an executable file, could be a file
    representing the contents of a disk, could be many other things,
    could be anything that is represented in binary format.

    "Image" is the usual term for pictures. Image processing,
    image manipulation, image recovery, raster image, vector
    image - all standard terms that refer to pictures. After
    all, as it's being processed as data, the "binary" is implied.

    JGH
    , Aug 12, 2012
    #3
  4. writes:

    > Vincenzo Mercuri wrote:
    >> What's the problem with his terminology? You only need to know what
    >> a "binary image" is: http://en.wikipedia.org/wiki/Binary_image

    >
    > That refers to two-colour images, the OP's link discussed
    > multi-coloured images.


    Eh? The OP code deals with images with pixels that can set or unset (0
    and 1 are the only valid pixel values).

    >> "binary image processing library" is proper wording.

    >
    > A binary image could be an executable file, could be a file
    > representing the contents of a disk, could be many other things,
    > could be anything that is represented in binary format.


    I think it might be slightly clearer to write "binary-image processing
    library" so that it's clear that it's the image that has the binary
    property, but that's a small matter.

    > "Image" is the usual term for pictures. Image processing,
    > image manipulation, image recovery, raster image, vector
    > image - all standard terms that refer to pictures. After
    > all, as it's being processed as data, the "binary" is implied.


    That argument cuts the other way as far as I am concerned. Because all
    modern computer data is binary, qualifying "image" with "binary" makes
    the meaning clear.

    --
    Ben.
    Ben Bacarisse, Aug 12, 2012
    #4
  5. Malcolm McLeanæ–¼ 2012å¹´8月12日星期日UTC+8上åˆ4時43分04秒寫é“:
    > My binary image processing library has gradually been building up.
    >
    > The time has come to ask for suggestions and comments. The idea is
    >
    > to provide a C language resource for people with a need to handle
    >
    > binary images.
    >
    >
    >
    > http://www.malcolmmclean.site11.com/www/BinaryImageProcessing/binarylibrary.html
    >
    >
    >
    > Obviously one priority is that everything is in portable ANSI C.
    >
    > Another is that the interfaces are clean, and functions can be cut and pasted
    >
    > with a minimum of fuss if people don't want to use the entire library.


    Do you plan to synthesize 3D images or layors of images not ?

    Now it is 2012, I'll assume that you can check the open source GTK/GIMG first.
    88888 Dihedral, Aug 12, 2012
    #5
  6. בת×ריך ×™×•× ×¨×שון, 12 ב×וגוסט 2012 21:46:53 UTC+1, מ×ת Ben Bacarisse:
    > writes:
    >
    > That argument cuts the other way as far as I am concerned. Because all
    > modern computer data is binary, qualifying "image" with "binary" makes
    > the meaning clear.
    >
    >

    I want the ibrary to be found by people typing search terms into Google.
    I would use the term "binary image processing" myself, but it doesn't come
    up with many good hits, which was part of the motivation for putting the
    library together.
    Malcolm McLean, Aug 12, 2012
    #6
  7. Malcolm McLeanæ–¼ 2012å¹´8月12日星期日UTC+8上åˆ4時43分04秒寫é“:
    > My binary image processing library has gradually been building up.
    >
    > The time has come to ask for suggestions and comments. The idea is
    >
    > to provide a C language resource for people with a need to handle
    >
    > binary images.
    >
    >
    >
    > http://www.malcolmmclean.site11.com/www/BinaryImageProcessing/binarylibrary.html
    >
    >
    >
    > Obviously one priority is that everything is in portable ANSI C.
    >
    > Another is that the interfaces are clean, and functions can be cut and pasted
    >
    > with a minimum of fuss if people don't want to use the entire library.


    Check the GIMP first. http://www.gimp.org/

    I'll assume that you are asking something nontrivial in processing
    digital images.
    88888 Dihedral, Aug 12, 2012
    #7
  8. Malcolm McLean

    Alan Curry Guest

    In article <>,
    Malcolm McLean <> wrote:
    >I want the ibrary to be found by people typing search terms into Google.
    >I would use the term "binary image processing" myself, but it doesn't come
    >up with many good hits, which was part of the motivation for putting the
    >library together.
    >


    The keywords I'd use for that Google search might include:
    bitmap
    1bpp
    monochrome
    pbm

    I'm especially puzzled that nobody has mentioned "bitmap". In my mind
    that's the standard term for images with a single bit per pixel.

    wikipedia's "Bitmap" article sort of agrees with me:

    : In some contexts, the term bitmap implies one bit per pixel, while
    : pixmap is used for images with multiple bits per pixel.

    I guess I come from those "some contexts". "Binary image" is a mostly
    meaningless phrase to me, since there are so many kinds of images and
    not so many non-binary computers. Even now, knowing what you mean by it,
    I have little confidence that the next time I see it it will mean the
    same thing.

    --
    Alan Curry
    Alan Curry, Aug 12, 2012
    #8
  9. Malcolm McLean

    BartC Guest

    "Vincenzo Mercuri" <> wrote in message
    news:...
    > Il 12/08/2012 01:10, ha scritto:
    >> Malcolm McLean wrote:
    >>> My binary image processing library has gradually been building up.

    >>
    >> Binary images of what? An executable? A disk?
    >>
    >>> http://www.malcolmmclean.site11.com/www/BinaryImageProcessing/binarylibrary.html

    >>
    >> Oh! Pictures. I'd recommend you clarify your terminology.

    >
    > What's the problem with his terminology? You only need to know what
    > a "binary image" is: http://en.wikipedia.org/wiki/Binary_image
    >
    > "binary image processing library" is proper wording.


    It might be proper but it's confusing.

    I would use black & white, mono, bi-level, or just 1-bit, compared with
    greyscale, palette (usually 16 or 256-colour) or full-colour images.

    The confusion is compounded by the use of a 'char' type to store the data;
    presumably each char represents one pixel? Most stored representations would
    store 8 pixels per byte, but that point doesn't seem to be stated
    explicitly.

    (A bit wasteful, but an image library using char/byte types to represent
    each pixel might as well deal with greyscale too.)

    --
    Bartc
    BartC, Aug 13, 2012
    #9
  10. בת×ריך ×™×•× ×©× ×™,13 ב×וגוסט 2012 00:32:01 UTC+1, מ×ת Bart:
    > "Vincenzo Mercuri" <> wrote in message
    >
    >
    > The confusion is compounded by the use of a 'char' type to store the data;
    > presumably each char represents one pixel? Most stored representations would
    > store 8 pixels per byte, but that point doesn't seem to be stated
    > explicitly.
    >
    >
    > (A bit wasteful, but an image library using char/byte types to represent
    > each pixel might as well deal with greyscale too.)
    >

    My thinking was that memory isn't likely to be at such a premium that a
    bit per pixel representation is worth it, given the complexities it adds
    to the code and the interface.
    Malcolm McLean, Aug 13, 2012
    #10
  11. Malcolm McLean

    James Kuyper Guest

    On 08/13/2012 03:56 AM, Malcolm McLean wrote:
    > בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 00:32:01 UTC+1, מ×ת Bart:
    >> "Vincenzo Mercuri" <> wrote in message
    >>
    >> The confusion is compounded by the use of a 'char' type to store the data;
    >> presumably each char represents one pixel? Most stored representations would
    >> store 8 pixels per byte, but that point doesn't seem to be stated
    >> explicitly.
    >>
    >> (A bit wasteful, but an image library using char/byte types to represent
    >> each pixel might as well deal with greyscale too.)
    >>

    > My thinking was that memory isn't likely to be at such a premium that a
    > bit per pixel representation is worth it, given the complexities it adds
    > to the code and the interface.


    Understood - but once you've decided to waste 7/8ths of the memory
    you're using, for convenience, it shouldn't add a whole lot more
    inconvenience to handle those 8 bits as representing a greyscale image?

    The set of functions a greyscale library would need to support is quite
    different, and even functions with the same purpose would use very
    different logic to implement it, so this is a decision better made at
    the start of the design process. However, such a library would have much
    more general usefulness. Those who are willing to deal with the
    limitations of a 1-bit color generally do so in order to achieve space
    savings that your library doesn't allow.
    --
    James Kuyper
    James Kuyper, Aug 13, 2012
    #11
  12. Malcolm McLean

    ImpalerCore Guest

    On Aug 13, 8:15 am, James Kuyper <> wrote:
    > On 08/13/2012 03:56 AM, Malcolm McLean wrote:
    >
    > > בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 00:32:01 UTC+1, מ×ת Bart:
    > >> "Vincenzo Mercuri" <> wrote in message

    >
    > >> The confusion is compounded by the use of a 'char' type to store the data;
    > >> presumably each char represents one pixel? Most stored representationswould
    > >> store 8 pixels per byte, but that point doesn't seem to be stated
    > >> explicitly.

    >
    > >> (A bit wasteful, but an image library using char/byte types to represent
    > >> each pixel might as well deal with greyscale too.)

    >
    > > My thinking was that memory isn't likely to be at such a premium that a
    > > bit per pixel representation is worth it, given the complexities it adds
    > > to the code and the interface.

    >
    > Understood - but once you've decided to waste 7/8ths of the memory
    > you're using, for convenience, it shouldn't add a whole lot more
    > inconvenience to handle those 8 bits as representing a greyscale image?
    >
    > The set of functions a greyscale library would need to support is quite
    > different, and even functions with the same purpose would use very
    > different logic to implement it, so this is a decision better made at
    > the start of the design process. However, such a library would have much
    > more general usefulness. Those who are willing to deal with the
    > limitations of a 1-bit color generally do so in order to achieve space
    > savings that your library doesn't allow.


    Most 1-bit images I have run across are either packed representations
    of low resolution displays or describing properties of other images,
    such as physicians defining contours of organs of interest in a CT or
    MRI. For the display, the image itself was packed, so one needed to
    address individual bits to set the pixels used to render graphics or
    text. When I was in school doing medical image processing, it was not
    uncommon to work on binary images of contours using unsigned char or
    uint8_t, but packing the representation when storing files to disk.
    Both representations have their merit, and a library looking to
    feature one style would miss out on some of its potential.

    Best regards,
    John D.
    ImpalerCore, Aug 13, 2012
    #12
  13. ImpalerCoreæ–¼ 2012å¹´8月14日星期二UTC+8上åˆ3時56分27秒寫é“:
    > On Aug 13, 8:15 am, James Kuyper <> wrote:
    >
    > > On 08/13/2012 03:56 AM, Malcolm McLean wrote:

    >
    > >

    >
    > > > בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 00:32:01 UTC+1, מ×ת Bart:

    >
    > > >> "Vincenzo Mercuri" <> wrote in message

    >
    > >

    >
    > > >> The confusion is compounded by the use of a 'char' type to store thedata;

    >
    > > >> presumably each char represents one pixel? Most stored representations would

    >
    > > >> store 8 pixels per byte, but that point doesn't seem to be stated

    >
    > > >> explicitly.

    >
    > >

    >
    > > >> (A bit wasteful, but an image library using char/byte types to represent

    >
    > > >> each pixel might as well deal with greyscale too.)

    >
    > >

    >
    > > > My thinking was that memory isn't likely to be at such a premium thata

    >
    > > > bit per pixel representation is worth it, given the complexities it adds

    >
    > > > to the code and the interface.

    >
    > >

    >
    > > Understood - but once you've decided to waste 7/8ths of the memory

    >
    > > you're using, for convenience, it shouldn't add a whole lot more

    >
    > > inconvenience to handle those 8 bits as representing a greyscale image?

    >
    > >

    >
    > > The set of functions a greyscale library would need to support is quite

    >
    > > different, and even functions with the same purpose would use very

    >
    > > different logic to implement it, so this is a decision better made at

    >
    > > the start of the design process. However, such a library would have much

    >
    > > more general usefulness. Those who are willing to deal with the

    >
    > > limitations of a 1-bit color generally do so in order to achieve space

    >
    > > savings that your library doesn't allow.

    >
    >
    >
    > Most 1-bit images I have run across are either packed representations
    >
    > of low resolution displays or describing properties of other images,
    >
    > such as physicians defining contours of organs of interest in a CT or
    >
    > MRI. For the display, the image itself was packed, so one needed to
    >
    > address individual bits to set the pixels used to render graphics or
    >
    > text. When I was in school doing medical image processing, it was not
    >
    > uncommon to work on binary images of contours using unsigned char or
    >
    > uint8_t, but packing the representation when storing files to disk.
    >
    > Both representations have their merit, and a library looking to
    >
    > feature one style would miss out on some of its potential.
    >
    >
    >
    > Best regards,
    >
    > John D.




    ImpalerCoreæ–¼ 2012å¹´8月14日星期二UTC+8上åˆ3時56分27秒寫é“:
    > On Aug 13, 8:15 am, James Kuyper <> wrote:
    >
    > > On 08/13/2012 03:56 AM, Malcolm McLean wrote:

    >
    > >

    >
    > > > בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 00:32:01 UTC+1, מ×ת Bart:

    >
    > > >> "Vincenzo Mercuri" <> wrote in message

    >
    > >

    >
    > > >> The confusion is compounded by the use of a 'char' type to store thedata;

    >
    > > >> presumably each char represents one pixel? Most stored representations would

    >
    > > >> store 8 pixels per byte, but that point doesn't seem to be stated

    >
    > > >> explicitly.

    >
    > >

    >
    > > >> (A bit wasteful, but an image library using char/byte types to represent

    >
    > > >> each pixel might as well deal with greyscale too.)

    >
    > >

    >
    > > > My thinking was that memory isn't likely to be at such a premium thata

    >
    > > > bit per pixel representation is worth it, given the complexities it adds

    >
    > > > to the code and the interface.

    >
    > >

    >
    > > Understood - but once you've decided to waste 7/8ths of the memory

    >
    > > you're using, for convenience, it shouldn't add a whole lot more

    >
    > > inconvenience to handle those 8 bits as representing a greyscale image?

    >
    > >

    >
    > > The set of functions a greyscale library would need to support is quite

    >
    > > different, and even functions with the same purpose would use very

    >
    > > different logic to implement it, so this is a decision better made at

    >
    > > the start of the design process. However, such a library would have much

    >
    > > more general usefulness. Those who are willing to deal with the

    >
    > > limitations of a 1-bit color generally do so in order to achieve space

    >
    > > savings that your library doesn't allow.

    >
    >
    >
    > Most 1-bit images I have run across are either packed representations
    >
    > of low resolution displays or describing properties of other images,
    >
    > such as physicians defining contours of organs of interest in a CT or
    >
    > MRI. For the display, the image itself was packed, so one needed to
    >
    > address individual bits to set the pixels used to render graphics or
    >
    > text. When I was in school doing medical image processing, it was not
    >
    > uncommon to work on binary images of contours using unsigned char or
    >
    > uint8_t, but packing the representation when storing files to disk.
    >
    > Both representations have their merit, and a library looking to
    >
    > feature one style would miss out on some of its potential.
    >
    >
    >
    > Best regards


    A bit map image is often produced in the segemetation of digital images.

    But this is a domain dependent problem, not a computer language problem.
    88888 Dihedral, Aug 14, 2012
    #13
  14. בת×ריך ×™×•× ×©× ×™,13 ב×וגוסט 2012 13:15:54 UTC+1, מ×ת James Kuyper:
    >
    > The set of functions a greyscale library would need to support is quite
    > different, and even functions with the same purpose would use very
    > different logic to implement it, so this is a decision better made at
    > the start of the design process. However, such a library would have much
    > more general usefulness. Those who are willing to deal with the
    > limitations of a 1-bit color generally do so in order to achieve space
    > savings that your library doesn't allow.
    >

    A grayscale image is essentially a continuous function. Beyond the trivial,the
    sorts of manipulations you would do on such images are completely different
    to those you would do with binary images.
    A colour-indexed image is often 256 colours, and in some ways a colour-indexed
    image can be thought of as lots of binary images superposed in the same
    space.
    I was thinking that the library would mainly be used for image processing. You
    treat images as binary because there are certain things which are harder to
    do with greyscale or colour images. But it may be that the real demand is
    from people who want to display binary images on machines with very
    constrained memory resources. That's not something I need personally,
    which is why I'm discussingthe library here.
    Malcolm McLean, Aug 14, 2012
    #14
  15. Malcolm McLean

    Jorgen Grahn Guest

    On Sun, 2012-08-12, Alan Curry wrote:
    ....
    > I'm especially puzzled that nobody has mentioned "bitmap". In my mind
    > that's the standard term for images with a single bit per pixel.


    I was just about to. But perhaps we both got that terminology from
    the PBM and Xbm tools/file formats and the X11 terminology?

    I don't I think I've ever heard of "binary images" before. But on the
    other hand you don't see them much these days ...

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Aug 14, 2012
    #15
  16. Malcolm McLean

    ImpalerCore Guest

    On Aug 14, 10:51 am, Malcolm McLean <>
    wrote:
    > בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 13:15:54 UTC+1, מ×ת James Kuyper:
    >
    > > The set of functions a greyscale library would need to support is quite
    > > different, and even functions with the same purpose would use very
    > > different logic to implement it, so this is a decision better made at
    > > the start of the design process. However, such a library would have much
    > > more general usefulness. Those who are willing to deal with the
    > > limitations of a 1-bit color generally do so in order to achieve space
    > > savings that your library doesn't allow.

    >
    > A grayscale image is essentially a continuous function. Beyond the trivial, the
    > sorts of manipulations you would do on such images are completely different
    > to those you would do with binary images.
    > A colour-indexed image is often 256 colours, and in some ways a colour-indexed
    > image can be thought of as lots of binary images superposed in the same
    > space.
    > I was thinking that the library would mainly be used for image processing.. You
    > treat images as binary because there are certain things which are harder to
    > do with greyscale or colour images. But it may be that the real demand is
    > from people who want to display binary images on machines with very
    > constrained memory resources. That's not something I need personally,
    > which is why I'm discussingthe library here.


    Why did you choose to not encapsulate the image in a struct that
    contains the data and the dimensions so the user has less to pass
    around?

    As far as visualization and image processing goes, VTK and ITK are
    pretty popular, although restricted to the C++ language. And I've
    used a RamTex C library for an embedded project that had a 1-bit OLED
    display.

    A library like that is nice from a learning or tinkering perspective,
    but you'd probably have to delve deep into a specific application
    domain to see any real use, like image segmentation in the medical
    imaging or machine vision fields, or provide drivers to use your
    algorithms on some group of embedded LCD displays.

    Best regards,
    John D.
    ImpalerCore, Aug 14, 2012
    #16
  17. בת×ריך ×™×•× ×©×œ×™×©×™, 14 ב×וגוסט 2012 20:39:50 UTC+1, מ×ת ImpalerCore:
    > On Aug 14, 10:51 am, Malcolm McLean <>
    >
    > Why did you choose to not encapsulate the image in a struct that
    > contains the data and the dimensions so the user has less to pass
    > around?
    >

    So that someone can snip and paste a single function. If I provide an imagestructure, either he's got to base his entire work on my library, or he won't use it at all.
    >
    >
    > As far as visualization and image processing goes, VTK and ITK are
    > pretty popular, although restricted to the C++ language. And I've
    > used a RamTex C library for an embedded project that had a 1-bit OLED
    > display.
    >
    >

    I don't think any display routines are appropriate for a general purpose library. I did think of providing a function to write a binary image as a GIF..
    >
    > A library like that is nice from a learning or tinkering perspective
    > but you'd probably have to delve deep into a specific application
    > domain to see any real use, like image segmentation in the medical
    > imaging or machine vision fields, or provide drivers to use your
    > algorithms on some group of embedded LCD displays.
    >
    >

    I'd agree that the future is with more sophisticated algorithms, like the Canny edge detector or the distance transform, which are hard to implement.
    Malcolm McLean, Aug 15, 2012
    #17
  18. Malcolm McLeanæ–¼ 2012å¹´8月14日星期二UTC+8下åˆ10時51分11秒寫é“:
    > בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 13:15:54 UTC+1, מ×ת James Kuyper:
    >
    > >

    >
    > > The set of functions a greyscale library would need to support is quite

    >
    > > different, and even functions with the same purpose would use very

    >
    > > different logic to implement it, so this is a decision better made at

    >
    > > the start of the design process. However, such a library would have much

    >
    > > more general usefulness. Those who are willing to deal with the

    >
    > > limitations of a 1-bit color generally do so in order to achieve space

    >
    > > savings that your library doesn't allow.

    >
    > >

    >
    > A grayscale image is essentially a continuous function. Beyond the trivial, the
    >
    > sorts of manipulations you would do on such images are completely different
    >
    > to those you would do with binary images.
    >
    > A colour-indexed image is often 256 colours, and in some ways a colour-indexed
    >
    > image can be thought of as lots of binary images superposed in the same
    >
    > space.
    >
    > I was thinking that the library would mainly be used for image processing.. You
    >
    > treat images as binary because there are certain things which are harder to
    >
    > do with greyscale or colour images. But it may be that the real demand is
    >
    > from people who want to display binary images on machines with very
    >
    > constrained memory resources. That's not something I need personally,
    >
    > which is why I'm discussingthe library here.




    Malcolm McLeanæ–¼ 2012å¹´8月14日星期二UTC+8下åˆ10時51分11秒寫é“:
    > בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 13:15:54 UTC+1, מ×ת James Kuyper:
    >
    > >

    >
    > > The set of functions a greyscale library would need to support is quite

    >
    > > different, and even functions with the same purpose would use very

    >
    > > different logic to implement it, so this is a decision better made at

    >
    > > the start of the design process. However, such a library would have much

    >
    > > more general usefulness. Those who are willing to deal with the

    >
    > > limitations of a 1-bit color generally do so in order to achieve space

    >
    > > savings that your library doesn't allow.

    >
    > >

    >
    > A grayscale image is essentially a continuous function. Beyond the trivial, the
    >
    > sorts of manipulations you would do on such images are completely different
    >
    > to those you would do with binary images.
    >
    > A colour-indexed image is often 256 colours, and in some ways a colour-indexed
    >
    > image can be thought of as lots of binary images superposed in the same
    >
    > space.
    >
    > I was thinking that the library would mainly be used for image processing.. You
    >
    > treat images as binary because there are certain things which are harder to
    >
    > do with greyscale or colour images. But it may be that the real demand is
    >
    > from people who want to display binary images on machines with very
    >
    > constrained memory resources. That's not something I need personally,
    >
    > which is why I'm discussingthe library here.


    Those problems were all sovled in the color printing industry of books, magazines, or films in analogue long time before.

    Problems in the digital part are slightly different but are solved again.
    88888 Dihedral, Aug 18, 2012
    #18
  19. בת×ריך ×™×•× ×©×‘×ª,18 ב×וגוסט 2012 06:09:12 UTC+1, מ×ת 88888 Dihedral:
    > Malcolm McLeanæ–¼ 2012å¹´8月14日星期二UTC+8下åˆ10時51分11秒寫é“:
    >
    >
    > Those problems were all sovled in the color printing industry of books,
    > magazines, or films in analogue long time before.
    >
    > Problems in the digital part are slightly different but are solved again.
    >

    The idea of the library isn't to develop new algorithms. Obviously if anyone
    does have a novel algorithm for use on binary images I'd be very interested
    to hear about it.
    The idea is to collect and package existing algorithms, so that anyone who
    want to do binary image processing can find them and use them.
    --
    The binary image library is on my website
    http://www.malcolmmclean.site11.com/www
    Malcolm McLean, Aug 18, 2012
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    3,295
  2. Guch
    Replies:
    6
    Views:
    417
    Catalin Pitis
    Mar 22, 2006
  3. polemon
    Replies:
    4
    Views:
    478
    zeppe
    Jul 22, 2007
  4. Obnoxious User

    image processing library

    Obnoxious User, Mar 21, 2008, in forum: C++
    Replies:
    29
    Views:
    798
    Diego Martins
    Mar 24, 2008
  5. Yingqi Tang
    Replies:
    6
    Views:
    251
    Clifford Heath
    May 18, 2007
Loading...

Share This Page