Experiment with tnsot icm tpsot

[renevanderark]

--> what will happen if we increment tnsot (property of tile header) by one in the .jpx files we have (dts files with .jpf extension)

Lachen dit. Ik probeer het volgende (OpenJPEG 2.0.0 onder Windows):

opj_decompress" -i dts_2340001_0005_access.jpf -o dts_2340001_0005_access.tif

Resultaat:

[ERROR] In SOT marker, TPSot (5) is not valid regards to the current number of t
ile-part (5), giving up
[ERROR] Fail to read the current marker segment (0xff90)
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> opj_decompress: failed to decode image!

M.a.w. hij doet het bij mij helemaal niet!

Wat hier aan de hand is: elke ‘tile’ in de codestream is opgebouwd uit een aantal ‘tile-parts’. Op tile-part niveau heb je een headerveld (tnsot) dat aangeeft hoeveel tile-parts er in één tile zitten. Daarnaast heeft elke ’tile –part’ een index (tpsot) met het bereik: [0,tnsot-1]. Bij die Photoshop jpfs klopt de waarde van tnsot niet! Voor dit bestand is tnsot 5 (jpylyzer), wat betekent dat tpsot van 0-4 (dus 5 tile parts per tile) loopt. Maar in werkelijkheid bevat elke tile 6 tile-parts (dus tpsot loopt door t/m 5!). Overigens geeft jpylyzer ook netjes een foutmelding:

False

Dit had ik al eens eerder gezien, en ik geloof dat we dit probleem ook voor alle JPX access images hebben, maar de meeste decoders kunnen desondanks wel met die files overweg.

Nu weet ik niet of dit iets met jouw probleem te maken heeft, want jij kunt ‘m blijkbaar wel decoderen. Gebruik jij ook opj_decompress of doe je dit anders?

Het zou natuurlijk altijd kunnen dat door de foute headerinformatie niet alle tile-parts volledig worden uitgelezen, en dat dit indirect weer tot een mindere kwaliteit leidt. Maar da’s ook maar een gokje ...

Johan

[bitsgalore]

Gelijk maar even dit probleem gedocumenteerd op de OPF Wiki:

http://wiki.opf-labs.org/display/TR/Erroneous+tile-part+information+in+images+created+by+Adobe+Photoshop

Johan

---

From: Rene van der Ark [mailto:[email protected]]
Sent: 09 April 2013 16:48
To: KBNLresearch/jp2view
Subject: [jp2view] Experiment with tnsot icm tpsot (#7)

Lachen dit. Ik probeer het volgende (OpenJPEG 2.0.0 onder Windows):

opj_decompress" -i dts_2340001_0005_access.jpf -o dts_2340001_0005_access.tif

Resultaat:

[ERROR] In SOT marker, TPSot (5) is not valid regards to the current number of t
ile-part (5), giving up
[ERROR] Fail to read the current marker segment (0xff90)
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> opj_decompress: failed to decode image!

M.a.w. hij doet het bij mij helemaal niet!

Wat hier aan de hand is: elke 'tile' in de codestream is opgebouwd uit een aantal 'tile-parts'. Op tile-part niveau heb je een headerveld (tnsot) dat aangeeft hoeveel tile-parts er in één tile zitten. Daarnaast heeft elke 'tile -part' een index (tpsot) met het bereik: [0,tnsot-1]. Bij die Photoshop jpfs klopt de waarde van tnsot niet! Voor dit bestand is tnsot 5 (jpylyzer), wat betekent dat tpsot van 0-4 (dus 5 tile parts per tile) loopt. Maar in werkelijkheid bevat elke tile 6 tile-parts (dus tpsot loopt door t/m 5!). Overigens geeft jpylyzer ook netjes een foutmelding:

False

Dit had ik al eens eerder gezien, en ik geloof dat we dit probleem ook voor alle JPX access images hebben, maar de meeste decoders kunnen desondanks wel met die files overweg.

Nu weet ik niet of dit iets met jouw probleem te maken heeft, want jij kunt 'm blijkbaar wel decoderen. Gebruik jij ook opj_decompress of doe je dit anders?

Het zou natuurlijk altijd kunnen dat door de foute headerinformatie niet alle tile-parts volledig worden uitgelezen, en dat dit indirect weer tot een mindere kwaliteit leidt. Maar da's ook maar een gokje ...

Johan

Reply to this email directly or view it on GitHub #7 . https://github.com/notifications/beacon/sPgm4HRLXydDGhnZHWEpYqOjB0vyLqjeFJQmLgUcBBOjB3nNqNuCbVIpeskFKt3_.gif