Binary Image processing library

[Malcolm McLean]

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.

 

[jgh]

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.

JGH

 

[jgh]

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

 

[Ben Bacarisse]

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).

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.

 

[88888 Dihedral]

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.

 

[Malcolm McLean]

בת×ריך ×™×•× ×¨×שון, 12 ב×וגוסט 2012 21:46:53 UTC+1, מ×ת Ben Bacarisse:

(e-mail address removed) 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.

 

[88888 Dihedral]

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.

 

[Alan Curry]

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.

 

[BartC]

Il 12/08/2012 01:10, (e-mail address removed) ha scritto:

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.)

 

[Malcolm McLean]

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

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.

 

[James Kuyper]

בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 00:32:01 UTC+1, מ×ת Bart:
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.

 

[ImpalerCore]

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.

 

[88888 Dihedral]

ImpalerCoreæ–¼ 2012å¹´8月14日星期二UTC+8上åˆ3時56分27秒寫é“：

On 08/13/2012 03:56 AM, Malcolm McLean wrote:












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 08/13/2012 03:56 AM, Malcolm McLean wrote:












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.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©× ×™,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.

 

[Jorgen Grahn]

.

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

 

[ImpalerCore]

בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 13:15:54 UTC+1, מ×ת James Kuyper:


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.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×œ×™×©×™, 14 ב×וגוסט 2012 20:39:50 UTC+1, מ×ת ImpalerCore:

On Aug 14, 10:51 am, Malcolm McLean <[email protected]>

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.

 

[88888 Dihedral]

Malcolm McLeanæ–¼ 2012å¹´8月14日星期二UTC+8下åˆ10時51分11秒寫é“：

בת×ריך ×™×•× ×©× ×™, 13 ב×וגוסט 2012 13:15:54 UTC+1, מ×ת James Kuyper:










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:










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.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,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.