Expected to find EPH marker

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build WIN64 version from trunk
2.
compress attached attached-i img.tif -o img.jp2 -I  -r 
754.256332343635,542.252778413158,389.838391920622,280.264072154672,201.48849310
0272,144.85485970322,104.139596543597,74.8684275452172,53.8246894469852,38.69584
66880406,27.8193625692756,20 -c 
[256,256],[256,256],[128,128],[128,128],[128,128],[128,128] -p RPCL -n 6 -t 
1024,1024 -b 64,64 -SOP -EPH

What is the expected output? What do you see instead?
file with correct EPH marker position.

What version of the product are you using? On what operating system?
trunk version

Please provide any additional information below.

Unable to open image in kdu_show and XnView

Original issue reported on code.google.com by ludane...@gmail.com on 4 Nov 2014 at 3:10

Attachments:

• S1M_005.jp2

[GoogleCodeExporter]

Sorry there is input file

Original comment by ludane...@gmail.com on 4 Nov 2014 at 3:12

Attachments:

• S1M_005.tif

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 7 Jan 2015 at 5:37

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Using opj_decompress on jp2 image, we have found if code reaches int this 
condition

if ((l_band->x1-l_band->x0 == 0)||(l_band->y1-l_band->y0 == 0)) 
       {
        ++l_band;
              continue;
       }

in opj_t2_read_packet_header funciton EPH error is raised.

So have made some modifications in encoder 

opj_t2_encode_packet
/* Writing Packet header */
band = res->bands;
for (bandno = 0; bandno < res->numbands; ++bandno)      {
    opj_tcd_precinct_t *prc = &band->precincts[precno];
       if ((band->x1-band->x0 == 0)||(band->y1-band->y0 == 0))
       {
        ++band;
              continue;
       }
.
.
.
.
/* Writing the packet body */
band = res->bands;
for (bandno = 0; bandno < res->numbands; bandno++) 
{
    opj_tcd_precinct_t *prc = &band->precincts[precno];
       if (!opj_t2_is_band_for_process(band)) 
       {
        ++band;
              continue;
       }

And now files are without error.
But we are not shure if this is the right fix and if this "fix" could not lead 
to any other problems. 

Could anyone with better knowledge of jp2000 algorith look in to it?

We have made another observation. If we encode same image with x86 version, 
part after first tile is corrupted as you can see in attached file.  

Corrupted blocs are in 2nd and 4th tile. This "artefact" is present if images 
height or with is over one tile(1024) within one or two code blocks(64).

Strange is that x86 version has no EPH errors but "artefacts". But now every 
image with has artefact encoded in x64 version has errors.

Original comment by ludane...@gmail.com on 12 Jan 2015 at 1:25

Attachments:

• S1M_005.jp2