Closed comstock closed 4 months ago
Hi comstock,
I tested with jpylyzer -- I suspect it has a bug, but more careful check is needed.
Notes:
--format jph
.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.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.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.
Thank you, so much.
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
Turns out this is indeed a Jpylyzer bug, see: https://github.com/openpreserve/jpylyzer/issues/221#issuecomment-1809376541
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.