Subject: Question on RFC 2035

From: Tobias Öbrink <[email-masked]>
Date: Mon, 23 Aug 1999 16:29:26 +0200 (MET DST)

Maybe someone already have noticed this a few years ago, but the
width and height fields in the JPEG payload header "encodes the
width/height of the image in 8-pixels multiples..." which means 
that the width/height field values ranges from 0x0 to 2040x2040
instead of from 8x8 to 2048x2048.

I find it hard to believe that this was the intention. How is this
RFC implemented today? 

/Tobias
............................................................................
Tobias Öbrink                 Grad. Stud. Dept. of Teleinformatics, KTH
Phone numbers:				Paper mail address:
	+46 8 752 14 75 (IT, work)		KTH-ELECTRUM/204
        +46 8 751 17 93 (Fax)			S-164 40 Kista
						Sweden
E-mail: [email-masked]	URL: http://www.it.kth.se/~nv91-tob/
See if I'm logged in: http://www.it.kth.se/~nv91-tob/notice.html

---

From: Peter Parnes <[email-masked]>
Date: Tue, 24 Aug 1999 10:23:21 +0200

I my implementation I just do a ( >> 3) which gives a range of 0-2040
and not 8-2048. I think I checked vic when I did it (a long time ago)
and there it was done the same way.

..... just checked and in the vic code there is a
  h->width = p->width_ >> 3;
  h->height = p->height_ >> 3;

/P

---

From: Ron Frederick <[email-masked]>
Date: Tue, 24 Aug 1999 08:02:19 PDT

>   h->height = p->height_ >> 3;
Right - I do the same. I vaguely remember the question coming up when we
defined the field, as we realized that a width or height of 0 wouldn't be
very interesting, but the thought was that it would only complicate the
code to special-case 2048 somehow or offset all the values by 1, with very
little gain. 2040x2040 was larger than HDTV resolution already. While one
might imagine some low-frame-rate imaging application wanting to send larger
images than that, supporting 2048x2048 wasn't going to help there much.
--
Ron Frederick
[email-masked]