I am working on a jpeg encoder decoder project.
I have problems with testing compliance.
I read the T.83 ITU document for compliance testing.
It says if I have to test compliance of my decoder
I have to have a double precision reference FDCT
so that I will do FDCT(ref FDCT) on my decoded data.
After quantization if I get back the input to the decoder
my decoder is said to be compliant.
Do I have to write my own code for "ref FDCT" or is there any standard
Also I downloaded the test vectors for jpeg compliance testing from
ITU site.There were some image named as A1,B1,B2 etc.
All the images are of 4 components and i am interested in only 3
components.(why would ITU give a test vector set with all the images
containing 4 components!?!?)
What should I do?
Reply by Rune Allnor●September 13, 20092009-09-13
On 12 Sep, 21:57, "Nave" <pswamynav...@gmail.com> wrote:
> �Hi guys,
> � I am working on a jpeg encoder decoder project.
> � I have problems with testing compliance.
> � �What should I do?
Don't know about JPEG in particular, but in general the
ideal way to test an implementation is to
- Get a 'full-feature' known data set (that is, one or
more images that use all the features of the file
format). Encode, decode, and see that you get the
known data back.
- Use independent codes to test the encoders and decoders.
That is, use somebody else's decoder to test your encoder,
and vice versa. That way, the risk of not detecting
'mirror' blunders (blunders in the endocer that are not
detected because a corresponding blunder in the decoder)
In practice you need to build brick on brick: Start with the
basics, and add the main features one by one. Test each one,
as you implement them. Make sure the backbone implementation
is flexible enough that it is simple to add new features.
As for how many feature you need to implement, you obviously
need to implement what you immediately need. From there on,
it depends as much on political issues [*] as robustness
and security [**].
And so on.
[*] What does it take before the implementation is
sufficiently/fully 'standard compliant'? What are
the business risks of *not* having a fully/sufficiently
[**] What would the operational and business consequences be
if your implementation came across that feature that is
used in one-in-a-billion cases, and could not handle it?
It depends totally on where your device is intended to
work, and what type of product you have sold. If you
have claimed to sell a fully compliant device, that can't
handle everything the standard specifies, you might find
yourself in trouble. And you might find yourself at a
competitive disadvantage if your product is only partially
compliant while your competitor's device is fully compliant.
Reply by Vladimir Vassilevsky●September 13, 20092009-09-13
Rune Allnor wrote:
> On 12 Sep, 21:57, "Nave" <pswamynav...@gmail.com> wrote:
>> Hi guys,
>> I am working on a jpeg encoder decoder project.
>> I have problems with testing compliance.
>> What should I do?
> Don't know about JPEG in particular, but in general the
> ideal way to test an implementation is to
Disclaimer: I am not familiar with the details of JPEG2000 standard.
The standard things are tested as proscribed in the standard. For the
perceptual multimedia coders the standards usually specify the format of
the data and the algorithm of the decoder. They provide the set of the
test vectors so the result of the decoding of those vectors must be
exact bit-to-bit. The implementation of the encoder is left to you; as
there could be the significant variations depending on the computing
power, memory size, the perceptual model and the nature of the content.
I.e. for the same input, the output of the different encoders can be
DSP and Mixed Signal Design Consultant
Reply by Dale Dalrymple●September 13, 20092009-09-13
On Sep 12, 12:57 pm, "Nave" <pswamynav...@gmail.com> wrote:
> Hi guys,
> Also I downloaded the test vectors for jpeg compliance testing from
> ITU site.There were some image named as A1,B1,B2 etc.
> All the images are of 4 components and i am interested in only 3
> components.(why would ITU give a test vector set with all the images
> containing 4 components!?!?)
> What should I do?
The ITU T80 series documents do not address application level issues
like color models and number of components (or even image size
limits). Your test suite will have to deal with differences in such
application level choices. At least the 4 component images provide
enough components to allow testing of encoders/decoders for most color
models with some subset of the reference images.
Dale B. Dalrymple