JPEG Core compliance

JPEG Core compliance

Post by Vincenzo Liguor » Sat, 05 Dec 1998 04:00:00



Hi,

I have almost finished a JPEG core for FPGA ASIC according to the
ISO specs ISO/IEC 10918-1.
I'm currently planning compliance tests according to ISO/IEC 10918-2.
I've noticed that the latter mentions a data set for the compliance
test.
Is this available on line or I must contact ISO (probably slow) ?

You can answer in this newsgroup, but if you need to email me directly,
see my web page.

Thanks,

Enzo

-------------------------------------------------------------------------------

Vincenzo Liguori
Ocean Logic Pty Ltd
PO BOX 768
Manly NSW 1655
Australia

Ph : +61-2-99054152
Fax : +61-2-99050921
WWW : http://www.bigfoot.com/~oceanlogic

 
 
 

JPEG Core compliance

Post by Tom Lan » Sat, 05 Dec 1998 04:00:00



> I'm currently planning compliance tests according to ISO/IEC 10918-2.
> I've noticed that the latter mentions a data set for the compliance test.
> Is this available on line or I must contact ISO (probably slow) ?

It's not available on-line, and I'm not sure that ISO ever even released
it officially.  The fact of the matter is that the draft 10918-2 dataset
is almost valueless as a test set; you can accomplish more, more easily,
by cross-testing with any well-recognized implementation.  (For example,
the free IJG code.)

Let's see, where did I put that screed ... ah, here it is...

10918-2 is completely useless for testing most production codecs anyway,
because it consists of random-noise data in a meaningless four-component
colorspace with randomly chosen sampling factors.  Most of the codecs
I know about include colorspace conversion and upsample/downsample logic
and will not work on this data.  If you can separate out those parts of
your codec and feed it raw subsampled data then you might have some
chance of using the 10918-2 data.  It's still a pretty unfriendly test
set because it's a random-noise image --- you have no chance of getting
a go/no go indication by eyeball, you have to resort to nontrivial
statistical analysis to see whether your codec works at all!  (Worse,
since your codec's roundoff errors are doubtless different from anyone
else's, you can't just compare output bits...)

And on top of that, the data set consists of one example of each of the
JPEG-defined processes.  IIRC, there are only about two datastreams that
a standard baseline codec has any hope of reading.  So it tells you
nothing at all about the robustness of your codec WRT real-world
variations in marker layout, restart markers, etc.

I'd suggest cross-testing with existing applications as a far more
useful and practical validation procedure than 10918-2.  (The IJG code
is intended in part as a freely available reference codec for such
testing.)  If you want to test the accuracy of your math, measuring the
degradation of an image over multiple compression cycles with a fixed
quality setting is a pretty sensitive check.

You can try the folks at www.jpeg.org if you want a more official
answer, but my opinion is that 10918-2 is a waste of time.

                        regards, tom lane
                        organizer, Independent JPEG Group

 
 
 

JPEG Core compliance

Post by Tom Lan » Sat, 05 Dec 1998 04:00:00



> I have run my own, with the help on the excellent IJG software, but big
> companies like to have some sort of "official" tests done.

True ... whether the tests prove anything is far too often irrelevant...

Quote:> Among my tests I run 10^6 8x8 blocks through FDCT and IDCT, calculatingthe
> PSNR with each original block. The worst was better than 52dbs.

This is good, but as far as FDCT/IDCT go there actually is a recognized
accuracy test, IEEE-1180.  IEEE withdrew this spec a couple years ago,
for reasons that were never explained in my hearing, but it's still about
as good a test procedure as you're going to find for those components.
Besides, if you need buzzword compliance then any spec with a number
on it is worth running ;-).

Now I will modestly claim to know a few things about JPEG implementation
bugs and compatibility problems ... and in my experience the DCT code
is not usually the source of problems.  (I can only ever recall seeing
one image that appeared to be made with a broken FDCT.)  The real
creepy-crawlies come from bogus assumptions about marker layout,
inability to cope with unusual Huffman tables or sampling factors,
and so forth.  And these are exactly the areas that the 10918-2 test
streams won't teach you much about :-(

I don't know whether you intend your hardware to produce/consume a
complete JPEG file directly, or whether you expect there to be a layer
of software to deal with the markers.  If you expect to consume real-
world JPEG files then there's no substitute for trying to read a
bunch of what's out there.  I have accumulated a rogue's gallery
of unusual JPEGs (some valid, most not) which I can send you if you're
interested in doing some stress testing.  It's far from official
but I daresay it'll teach you more than 10918-2 would...

                        regards, tom lane
                        organizer, Independent JPEG Group

 
 
 

1. CORBA 2.4.x compliance w.r.t. messaging changes in CORBA core.

Hello,

 I'd like to implement some missing feature(s) in MICO to update it to
CORBA 2.4. The problem which I see is in messaging related changes in
CORBA core. As I understand CORBA specification, I'll have to update
all features specified in CORBA core chapters to CORBA 2.4. This is
perfectly ok till the moment when I see some messaging related changes
in these chapters - examples:

ORB Interface: added operations get_client_policy,
get_policy_overrides, validate_connection

Dynamic Invocation Interface: added operations on Request interface:
sendp, prepare, sendc.

etc.

Question is: do I really need to implement all these messaging related
changes which infiltrate into CORBA core for CORBA 2.4 compliance?

Thanks a lot,

Karel
--

ObjectSecurity Ltd.           http://www.objectsecurity.com

2. Restoring W2K DC from tape onto different hardwar

3. What is the compliance testing standard in JPEG or MPEG?

4. Seeking easy scheme with EPROM

5. JPEG Compliance Test

6. hash_set, hash_map

7. JPEG Decoder Compliance Data

8. Clear path? I'll give you clear path

9. JPEG display program cv core dumps

10. Progressive JPEG to normal JPEG

11. Comparing JPEG and JPEG 2000

12. JPEG Standard of Independent JPEG Group's software

13. help - - jpeg viewing problem - - is there a win98 system component that decompresses jpegs for viewing