How to read a 8-bit grayscale JPEG image using C?

[Speed]

Hi,

Could anyone tell me what is the simplest code to read a 8-bit
grayscale JPEG image using C.

Thanks a ton,
Speed

 

[Default User]

Hi,

Could anyone tell me what is the simplest code to read a 8-bit
grayscale JPEG image using C.

Well, the simple answer is that you open the file with fopen() in
binary mode, and read the data with fread().

However, that's not likely what you are asking. If you're asking
whether C has facilities for image handling, then the answer is no.
You'll have to find a library with a C API for that. the platform you
intend to use will be important.

I recommend a Google search, or ask on a newsgroup dedicated to image
processing.




Brian

 

[Flash Gordon]

Speed wrote, On 18/07/07 23:06:

Hi,

Could anyone tell me what is the simplest code to read a 8-bit
grayscale JPEG image using C.

FILE *jpeghandle = fopen(jpegname,"rb");
if (jpeghandle)
while (getc(jpeghandle)!=EOF);

The above will work given an appropriate definition and initialisation
of jpegname on systems with CHAR_BIT==8.

If you want to do more it might be useful for you to say what you want
to do. The most probable useful answer is that you want an appropriate
library for handling jpegs that does rather more than just read it. What
libraries are available will depend on your implementation, and thus a
question with rather more information on a group related to your
implementation would probably help you more.

 

[Richard]

Hi,

Could anyone tell me what is the simplest code to read a 8-bit
grayscale JPEG image using C.

Thanks a ton,
Speed

You will probably get about 30 replies telling you that JPEG has nothing
to do with C - and they will be right.

However, you can learn a lot by looking up the Intel developed openCV
libraries.

Here's a link to some docs which details cvLoadImage

http://vision.cis.udel.edu/opencv/ref/OpenCVRef_highgui.htm

No need to reinvent the wheel.

 

[Malcolm McLean]

Hi,

Could anyone tell me what is the simplest code to read a 8-bit
grayscale JPEG image using C.

Thanks a ton,
Speed

Buy my book, Basic Algorithms. Just out. It has a chapter on JPEG
compression. Other chapters on Huffman coding, colour sopaces, and frequency
transforms lead in to it.
(Follow the link from the website).

 

[Richard Bos]

Buy my book, Basic Algorithms.

Or rather, read Malcolm's contributions to this group and the real
experts' opinions of his expertise, and then consider whether you want
to buy his book.

Richard

 

[santosh]

Or rather, read Malcolm's contributions to this group and the real
experts' opinions of his expertise, and then consider whether you
want to buy his book.

IIRC, his book uses his own version of BASIC, so judging it from the
perspective of his C skills is not quite fair.

 

[Richard Bos]

IIRC, his book uses his own version of BASIC, so judging it from the
perspective of his C skills is not quite fair.

Possibly not, but would _you_ trust algorithms written by someone who
doesn't know the difference between an int and an integer?

Richard

 

[Kelsey Bjarnason]

[snips]

Buy my book, Basic Algorithms.

Or not. Let's see:

int strlen(const char *str)

You follow up your example with one that uses size_t and even explains why
you should use size_t... which raises the obvious question why include
such a badly broken example at all?


This is followed up by, among other things, strcount which counts the
number of characters in a string. Problem: it returns an int, which
you've already said, on that very page, is a bad idea, yet here you go
doing it again, apparently oblivious to the notion that the string could
just as easily be longer than the range of an int *and* be filled with a
single character.

int squnch(void *data, int len, void *out)

Er... no. Once again, a complete failure to grasp the concept of size_t
and its reason for existence. One might also ask the utility of
(len & 0xFF000000) >> 24; where len is an int and the code is being
compiled on a 16-bit implementation. One might *also* ask the reasoning
behind using *signed* ints for sizes; do you expect a lot of negative
length buffers to compress?

In fact, the entire example set seems to suggest a serious fetish for
using inappropriate types and inappropriate assumptions on sizes and the
like. How the hell did you get this past a reviewer or editor?

 

[Malcolm McLean]

[snips]

Buy my book, Basic Algorithms.

Or not. Let's see:

int strlen(const char *str)

You follow up your example with one that uses size_t and even explains why
you should use size_t... which raises the obvious question why include
such a badly broken example at all?


This is followed up by, among other things, strcount which counts the
number of characters in a string. Problem: it returns an int, which
you've already said, on that very page, is a bad idea, yet here you go
doing it again, apparently oblivious to the notion that the string could
just as easily be longer than the range of an int *and* be filled with a
single character.

int squnch(void *data, int len, void *out)

Er... no. Once again, a complete failure to grasp the concept of size_t
and its reason for existence. One might also ask the utility of
(len & 0xFF000000) >> 24; where len is an int and the code is being
compiled on a 16-bit implementation. One might *also* ask the reasoning
behind using *signed* ints for sizes; do you expect a lot of negative
length buffers to compress?

In fact, the entire example set seems to suggest a serious fetish for
using inappropriate types and inappropriate assumptions on sizes and the
like. How the hell did you get this past a reviewer or editor?

I do most of my programming on parallel hardware.
There is no interface for passing size_ts over the system. You can do so, of
course, by hardcoding in the bit size, or converting to integers, or simply
passing as a bit buffer. But that sort of thing adds complexity I don't
need.

There are good reasons for disliking size_t. That's just one of them. It
certainly isn't a case of not being able to grasp the concept. I explain,
rightly or wrongly, in the first paragraphs the coding conventions I am
using, and the justification for them.
The programs contain operations on integers, characters, and reals. I don't
want a zoo of types.

 

[Kelsey Bjarnason]

[snips]

There are good reasons for disliking size_t. That's just one of them.

Then at *most*, an unsigned type would be appropriate, unless you actually
do plan on compressing buffers with negative lengths. Using an unadorned
int is simply wrong, no matter how you look at it, for the purposes you
put it to.