Expected to find EPH marker

[gcode-importer]

Originally reported on Google Code with ID 425

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.488493100272,144.85485970322,104.139596543597,74.8684275452172,53.8246894469852,38.6958466880406,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

Reported by ludanemec on 2014-11-04 15:10:56

---

- _Attachment: [S1M_005.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-425/comment-0/S1M_005.jp2)_

[gcode-importer]

Sorry there is input file

Reported by ludanemec on 2014-11-04 15:12:41

---

- _Attachment: [S1M_005.tif](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-425/comment-1/S1M_005.tif)_

[gcode-importer]

Reported by malaterre on 2015-01-07 17:37:18

• Labels added: Priority-High
• Labels removed: Priority-Medium

[gcode-importer]

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.

Reported by ludanemec on 2015-01-12 13:25:33

---

- _Attachment: [S1M_005.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-425/comment-3/S1M_005.jp2)_

[rouault]

Likely fixed per 73d1510