Sample JPH images, please

[comstock]

Hi. I'm looking for sample JPH images, properly encoded, for testing purposes. Could you supply any?

FYI: The JPH files in the jp2k_test_codestreams repository are all found not valid according to jpylyzer, recently updated to accommodate JPH.

[aous72]

Hi comstock,

I tested with jpylyzer -- I suspect it has a bug, but more careful check is needed.

Notes:

1. Perhaps you already know that, in jpylyzer, you need to specify the format to test, the default is ".jp2." You should use --format jph.
2. Most of the .jph images in jp2k_test_codestreams/openjph pass with jpylyzer. The tiled ones sometimes fail, but that might be a bug in jpylyzer (We need to check with jpylyzer main developer @bitsgalore); of course, it is possible the problem is in the encoder -- the encoder used to produce the jph images is in a comment in the jph file; this comment is produced by jpylyzer.
3. The official conformance test images are in 'https://gitlab.com/wg1/htj2k-codestreams/' which has the testfiles_jph and testfiles_jp2 folders. There are files in 'https://github.com/osamu620/OpenHTJ2K/tree/main/conformance_data' which may have the wrong extension to work with jpylyzer.
4. You can create your own with 'https://kakadusoftware.com/documentation-downloads/downloads/' which I rely on.

There are resource on 'https://github.com/chafey/HTJ2KResources', but I am not sure if there are any images.

Let me know how it goes with you. You can also join the HTJ2K discord server 'https://discord.gg/U4Zbq7RGDn' if you like.

Cheers,
Aous.

[comstock]

Thank you, so much.

[bitsgalore]

I just had a look at this, and I'm able to reproduce the results reported by @aous72. In all cases the offending tests are (this happens with some of the JPHs and some of the codestreams):

    <tests>
        <foundExpectedNumberOfTiles>False</foundExpectedNumberOfTiles>
        <foundExpectedNumberOfTileParts>False</foundExpectedNumberOfTileParts>
    </tests>

I did a couple of tests, and from what I can see the reason this error is reported, is that the tile-parts aren't implemented correctly.

See for example this one:

jpylyzer --format jhc simple_enc_irv97_tall_narrow1.j2c > simple_enc_irv97_tall_narrow1.xml

Based on the image geometry defined in the SIZ marker (values of xsiz, x0siz, xTsiz, ysiz, y0siz, and yTsiz), this image only contains one single tile:

<xsiz>17</xsiz>
<ysiz>256</ysiz>
<xOsiz>1</xOsiz>
<yOsiz>0</yOsiz>
<xTsiz>16</xTsiz>
<yTsiz>256</yTsiz>
<xTOsiz>0</xTOsiz>
<yTOsiz>0</yTOsiz>
<numberOfTiles>1</numberOfTiles>

It also contains two tile-parts, with the following properties:

<tileParts>
    <tilePart>
        <sot>
            <lsot>10</lsot>
            <isot>0</isot>
            <psot>739</psot>
            <tpsot>0</tpsot>
            <tnsot>1</tnsot>
        </sot>
        <pltCount>0</pltCount>
        <pptCount>0</pptCount>
    </tilePart>
    <tilePart>
        <sot>
            <lsot>10</lsot>
            <isot>1</isot>
            <psot>96</psot>
            <tpsot>0</tpsot>
            <tnsot>1</tnsot>
        </sot>
        <pltCount>0</pltCount>
        <pptCount>0</pptCount>
    </tilePart>
</tileParts>

Note that both tile-parts have different isot values. Since isot (tile index) links each tile-part to its respective tile (see clause A.4.2 of Part 1), for a single-tile image, the expected value here would be 0 for both tile-parts (after all they're both part of the same tile)!

Also, tnsot represents the number of tile-parts of a tile in the codestream. Its value is either 0 (which means that the number of tile-parts of this tile is not specified in this tile-part), or the correct number of tile-parts for that tile. Since we have a single-tile image with two tile-parts, the expected value here would be either 0 or 2 (not 1!).

So unless I'm overlooking something obvious, I think this is really a fault of the images.

BTW Jpylyzer's behaviour is not affected in any way by file extensions. As long as you set the --format option correctly, Jpylyzer will validate against that format, irrespective of the file extension of the file

[aous72]

See openpreserve/jpylyzer#221 (comment)

[bitsgalore]

Turns out this is indeed a Jpylyzer bug, see: openpreserve/jpylyzer#221 (comment)