home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.compression:2785 comp.arch:8218 sci.electronics:13162
- Newsgroups: comp.compression,comp.arch,sci.electronics
- Path: sparky!uunet!nic.unh.edu!kepler.unh.edu!pss1
- From: pss1@kepler.unh.edu (Paul S Secinaro)
- Subject: Need help with LSI JPEG chipset
- Message-ID: <1992Jul23.113602.20438@nic.unh.edu>
- Sender: news@nic.unh.edu (USENET News System)
- Organization: University of New Hampshire - Durham, NH
- Date: Thu, 23 Jul 1992 11:36:02 GMT
- Lines: 26
-
- Hi folks.
-
- I'm part of a team working on a design that uses the LSI Logic
- L64745 JPEG Coder. This device takes a stream of data from the DCT
- processor chip (L64735) and performs the quantization and entropy
- coding steps. It then outputs the coded data in 32-bit words. From
- that point, our design takes the coded data, divides it down to 8-bit
- bytes, and performs byte-stuffing and other code insertions as
- specified by the JPEG/JFIF spec.
-
- That's all fine, but there's just one thing I can't seem to figure
- out - what byte ordering should we use when breaking up the 32-bit
- code words into an 8-bit data stream? Right now we're using
- big-endian, but we aren't sure if that's right. The documentation
- isn't too helpful on this point either. Anyone have suggestions?
- Also, if anyone here has experience with some other JPEG chipsets
- (such as C-Cube), maybe they could tell me how they approached this
- problem? Thanks.
-
- Paul
-
- --
- Niven's Law #14: There exist minds that think as well as you do, but
- differently.
- Niven's Corollary: The gene-tampered turkey you're talking to isn't
- necessarily one of them.
-