OpenJpeg fails to encode components with different precision properly

[gcode-importer]

Originally reported on Google Code with ID 459

OpenJpeg fails to encode components with different precision properly.

issue203-32x32-bgr16.bmp & issue203-127x64-bgr16.bmp are not encoded properly. The
image color are off, with or without mct.

It seems to happen only when the first component is not the one with highest precision.

bmpmask16toimage in convertbmp.c can easily be modified to produce different combinations.

i.e. to get 5bits precisions on all components (from this bgr565 images) would modify
it as follow :
    bmp_mask_get_shift_and_prec(blueMask,  &blueShift,  &bluePrec);
    bmp_mask_get_shift_and_prec(alphaMask, &alphaShift, &alphaPrec);

+   greenPrec -= 1;
+   greenShift += 1;

    image->comps[0].bpp = redPrec;
    image->comps[0].prec = redPrec;

Reported by mayeut on 2014-12-22 18:34:33

[gcode-importer]

This is related to QCC marker not being written.

All code related to QCC/COC is between #ifdef 0

Any idea why ?
I could make a patch but it seems someone did this for a good reason & it would be
good to know it before starting anything.

Reported by mayeut on 2014-12-24 11:20:26

• Status changed: Started

[gcode-importer]

With QCC in the file, all goes well.

What I suspect is that one doesn't want COC/QCC markers written when not necessary
& simply disabled it for now. Maybe I'm wrong...

Reported by mayeut on 2014-12-24 11:22:11

[mayeut]

NR-ENC-issue203-32x32-bgr16.bmp-43-compare_dump2base
NR-ENC-issue203-32x32-bgr16.bmp-43-compare_dec-ref-out2base
NR-ENC-issue203-33x33-bgr16.bmp-44-compare_dump2base
NR-ENC-issue203-33x33-bgr16.bmp-44-compare_dec-ref-out2base
NR-ENC-issue203-127x64-bgr16.bmp-49-compare_dump2base
NR-ENC-issue203-127x64-bgr16.bmp-49-compare_dec-ref-out2base

All those tests are failing because of that (reference data not created because of that issue in fact)

[detonin]

Hi thanks for all the work. There is sth more fundamental I don't get here: COC and QCC are used to define different coding style and quantization parameters for a given component (by "different"; I mean "different than what is defined in QCD and COD").
The issue here seems to be at encoding side, which is surprising as a given image does not actually require itself that one of its components be encoded differently, this is more sth related to the options one wants to give at the commandline ... Or am I missing sth ?
So I would say having the encoder able to write QCD and COC is nice but is this really solving the issue with the files given in #459 or only hiding it in some way ?

[mayeut]

@detonin, those images are rgb16: red 5 bits, green 6 bits, blue 5bits.
The step sizes are computed with the component precision. Thus, QCC shall exist (i.e. is different from QCD) for those files since the step sizes are part of QCD/QCC.

[detonin]

@mayeut Thanks, got it. I guess you add COC writing so that it's handled the same way (or is there a reason similar to what requires QCC ?).
If the case where 5-3 transform is handled (i.e. no quantization => no need for different stepsizes => no QCC even for images with components with different precision), the PR can be merged, the issue closed and the known_failures on travis updated. I can do this tomorrow if you're not available.

[mayeut]

@detonin, should be handled properly. The addition of COC/QCC is only done if it differs from COD/QCD. The trigger for it to be added is really differences between COC/COD (resp. QCC/QCD). If the same, then it's not written. The trigger is not the number of components.
Seems to match your requirements so closing (I'll update known_failures).