«

Hi,

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

Thanks a ton,
Speed

Speed wrote:

> 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

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.
--
Flash Gordon

Speed <> writes:

> 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/re...ef_highgui.htm

No need to reinvent the wheel.

"Speed" <> wrote in message
news: ps.com...
> 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).

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

"Malcolm McLean" <> wrote:

> "Speed" <> wrote in message
> news: ps.com...
> > Could anyone tell me what is the simplest code to read a 8-bit
> > grayscale JPEG image using C.

> 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

On Friday 20 Jul 2007 3:25 pm, Richard Bos
<> wrote in message
<>:
> "Malcolm McLean" <> wrote:
>
>> "Speed" <> wrote in message
>> news: ps.com...
>> > Could anyone tell me what is the simplest code to read a 8-bit
>> > grayscale JPEG image using C.
>
>> 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.

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

santosh <> wrote:

> On Friday 20 Jul 2007 3:25 pm, Richard Bos
> <> wrote in message
> <>:
> > "Malcolm McLean" <> wrote:
> >
> >> "Speed" <> wrote in message
> >> news: ps.com...
> >> > Could anyone tell me what is the simplest code to read a 8-bit
> >> > grayscale JPEG image using C.
> >
> >> 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.
>
> 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

[snips]

On Thu, 19 Jul 2007 21:20:02 +0100, Malcolm McLean wrote:

> 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?

"Kelsey Bjarnason" <> wrote in message
news:5huun4-...
> [snips]
>
> On Thu, 19 Jul 2007 21:20:02 +0100, Malcolm McLean wrote:
>
>> 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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm