.itw file (afbeelding). Hoe te openen/decoderen?

[Juup]

De BMW reparatiehandleidingen zitten in een windows programma genaamd TIS. De plaatjes die ze in het programma tonen staan opgeslagen in een vreemd formaat en hebben de .itw extensie. Er wordt naar gerefereerd met de melding dat het een TIFF bestand zou zijn.

De eerste paar bytes zien er zo uit:

code:

ITW_\x02\x00\x01<\x00

oftwel in hex:

code:

49 54 57 5f 02 00 01 3c 00

als ik `file 34.ITW` uitvoer zegt hij alleen maar:

code:

34.ITW: data

Lekker nuttig dus.

Heeft iemand een idee hoe ik er achter kan komen wat dit voor formaat is?

[RobIII]

Juup schreef op zaterdag 03 mei 2008 @ 23:48:
Er wordt naar gerefereerd met de melding dat het een TIFF bestand zou zijn.

Dom idee; maar al eens gewoon in een paar image-viewers gegooid nadat je 't heb gerenamed naar TIFF?

Anders is het misschien een TIFF ingepakt in een eigen formaat; in dat geval pak je er even de TIFF specs bij en kijk je of je de header ofzo in de ITW kunt vinden en vanaf dat punt inlezen.

Image File Header
A TIFF file begins with an 8-byte image file header, containing the following
information:

Bytes 0-1: The byte order used within the file. Legal values are:
“II” (4949.H)
“MM” (4D4D.H)
In the “II” format, byte order is always from the least significant byte to the most
significant byte, for both 16-bit and 32-bit integers This is called little-endian byte
order. In the “MM” format, byte order is always from most significant to least
significant, for both 16-bit and 32-bit integers. This is called big-endian byte
order.
Bytes 2-3 An arbitrary but carefully chosen number (42) that further identifies the file as a
TIFF file.
The byte order depends on the value of Bytes 0-1.
Bytes 4-7 The offset (in bytes) of the first IFD. The directory may be at any location in the
file after the header but must begin on a word boundary. In particular, an Image
File Directory may follow the image data it describes. Readers must follow the
pointers wherever they may lead.
The term byte offset is always used in this document to refer to a location with
respect to the beginning of the TIFF file. The first byte of the file has an offset of
0.

Overigens zegt filext.com dat het wel eens een IT Works Database zou kunnen zijn, wat relatief aannemelijk is gezien het reparatiehandleidingen zijn die je prima in een DB zou kunnen opslaan (inc. afbeeldingen als BLOB ofzo). Hoe groot zijn die bestanden en is het aannemelijk dat het 'puur' images zijn? Staan er (naar schatting) voldoende .itw bestanden in de directory (of directories) voor het aantal afbeeldingen in de handleiding? Of heb je maar 1 of een paar van die .itw bestanden en zijn die veel groter dan een gemiddelde image?

En vind je iets terug van compressie als JPG artefacts in die handleidingen of zijn het (schijnbare) vector-afbeeldingen?

[ Voor 75% gewijzigd door RobIII op 04-05-2008 00:07 ]

[gertvdijk]

Juup schreef op zaterdag 03 mei 2008 @ 23:48:
Er wordt naar gerefereerd met de melding dat het een TIFF bestand zou zijn.

Dat is heel nutteloze informatie gezien TIFF gewoon een container is voor elk ander soort 'formaat' afbeelding. Dat het gebruikelijk is dat je er bitmap danwel lossless compressie bitmap instopt normaal gesproken is niets meer dan een ongeschreven conventie die nergens op slaat. Dus ze kunnen prima beweren dat het TIFF is, met een specifieke afbeeldingscodering die geen enkel ander programma kan hanteren.

Nja, wat je wel kan proberen is gewoon de extensie hernoemen en kijken of je het met een image viewer/editor als 'TIFF' kan openen.

[ Voor 10% gewijzigd door gertvdijk op 04-05-2008 00:04 ]

[Juup]

RobIII schreef op zaterdag 03 mei 2008 @ 23:53:
Dom idee; maar al eens gewoon in een paar image-viewers gegooid nadat je 't heb gerenamed naar TIFF?

Slim idee idd maar had ik al geprobeerd. Niets helaas. Noch MacOS X z'n viewers noch verschillende browsers.

Anders is het misschien een TIFF ingepakt in een eigen formaat; in dat geval pak je er even de TIFF specs bij en kijk je of je de header ofzo in de ITW kunt vinden en vanaf dat punt inlezen.

Helaas komen II, MM en 42 in de hele file niet voor. Het zou natuurijk ook andersom kunnen zijn dat ik de ITW_ header moet vervangen door de TIFF header.

Overigens zegt filext.com dat het wel eens een IT Works Database zou kunnen zijn, wat relatief aannemelijk is gezien het reparatiehandleidingen zijn die je prima in een DB zou kunnen opslaan (inc. afbeeldingen als BLOB ofzo). Hoe groot zijn die bestanden en is het aannemelijk dat het 'puur' images zijn? Staan er (naar schatting) voldoende .itw bestanden in de directory (of directories) voor het aantal afbeeldingen in de handleiding?

Elk plaatje komt overeen met 1 .itw file, en die zijn zo'n 10k groot.

[ Voor 25% gewijzigd door Juup op 04-05-2008 00:06 ]

[RobIII]

gertvdijk schreef op zondag 04 mei 2008 @ 00:00:
[...]

Dat is heel nutteloze informatie gezien TIFF gewoon een container is voor elk ander soort 'formaat' afbeelding. Dat het gebruikelijk is dat je er bitmap danwel lossless compressie bitmap instopt normaal gesproken is niets meer dan een ongeschreven conventie die nergens op slaat. Dus ze kunnen prima beweren dat het TIFF is, met een specifieke afbeeldingscodering die geen enkel ander programma kan hanteren.

Dan heeft een TIFF nog altijd een vaste header en bevat wel degelijk info over het bestand dat het bevat; of het dan een 'gangbaar' formaat is, is een tweede.

Juup schreef op zondag 04 mei 2008 @ 00:02:
Helaas komen II, MM en 42 in de hele file niet voor. Het zou natuurijk ook andersom kunnen zijn dat ik de ITW_ header moet vervangen door de TIFF header.

Zou kunnen, maar lijkt me een long shot... De kans dat ze een eigen formaat heben verzonnen voor dit doeleinde lijkt me stug, maar het is wel aannemelijk dat de bestanden 'encrypted' of 'obfuscated' zijn (voor overigens logische redenen) of dat ze 'ingepakt' zijn.

Lees ook even mijn edit mocht je die gemist hebben.

Juup schreef op zondag 04 mei 2008 @ 00:02:


Elk plaatje komt overeen met 1 .itw file, en die zijn zo'n 10k groot.

Ah, 10k is wel weinig; dat zou wijzen op een zwart/wit kleine afbeelding a la GIF / JPG, maar de kans is ook aanwezig dat het vectorafbeeldingen zijn. Kun je daar nog een inschatting over doen?

[ Voor 45% gewijzigd door RobIII op 04-05-2008 00:08 ]

[Juup]

RobIII schreef op zondag 04 mei 2008 @ 00:02:
Ah, 10k is wel weinig; dat zou wijzen op een zwart/wit kleine afbeelding a la GIF / JPG, maar de kans is ook aanwezig dat het vectorafbeeldingen zijn. Kun je daar nog een inschatting over doen?

het wordt getoond in zwart wit, sommige plaatjes in grijstinten foto. Er zit een "vergroot" optie op en die ziet eruit alsof je op een bitmap inzoomt.
Dus het zullen wel grijstinten pixelplaatjes zijn.

[RobIII]

Juup schreef op zondag 04 mei 2008 @ 00:11:
[...]

het wordt getoond in zwart wit, sommige plaatjes in grijstinten foto. Er zit een "vergroot" optie op en die ziet eruit alsof je op een bitmap inzoomt.
Dus het zullen wel grijstinten pixelplaatjes zijn.

Dan zou je eens kunnen zoeken naar andere 'bekende' en 'gangbare' image file headers in de bestanden voor de odd-chance dat ze die hebben gewrapped in een eigen formaatje, of eens kijken naar bekende/gangbare compressiemethoden die er gebruikt zouden kunnen zijn.

[CyBeR]

Zijn ze allemaal exact even groot? Dan is 't meest waarschijnlijke dat elke byte gewoon een pixelwaarde is. Maar met files van 10k kom je dan op ongeveer 100 * 100 pixels uit dus die kans is klein. Dus dat is dan waarchijnlijk compressed (en dan zullen ze niet allemaal even groot zijn), of getiled.

[Juup]

Nee ze zijn niet allemaal even groot. Ze varieren in grotte tussen de 4k en de 12k ofzo.
Hier heb je d'r bv een: ho ho, pas wel even op met copyrighted materiaal

[ Voor 30% gewijzigd door RobIII op 04-05-2008 00:27 ]

[TheBlasphemer]

Juup schreef op zondag 04 mei 2008 @ 00:20:
Nee ze zijn niet allemaal even groot. Ze varieren in grotte tussen de 4k en de 12k ofzo.
Hier heb je d'r bv een: weg

Kun je een inschatting geven hoe groot dat specifieke plaatje is?
Mischien zelfs een screenshot met hoe hij eruit zou moeten zien?

[ Voor 9% gewijzigd door RobIII op 04-05-2008 00:27 ]

[RobIII]

Jaaap, pas je wel even op met het posten van (eventueel) copyrighted materiaal enzo? Ik vind dit topic toch al op het randje qua 'omzeilen van (evt) beveiliging' enzo, maar om nu meteen die bestanden online te slingeren vind ik wat ver gaan.

[Juup]

TheBlasphemer schreef op zondag 04 mei 2008 @ 00:25:
Kun je een inschatting geven hoe groot dat specifieke plaatje is?
Mischien zelfs een screenshot met hoe hij eruit zou moeten zien?

Die border hoort er misschien niet bij. Dit is niet die 34.itw maar een random screenshot.

Een plaatje is gemiddeld 300 bij 240 pixeltjes.

[ Voor 18% gewijzigd door Juup op 04-05-2008 00:38 . Reden: woops copyright ]

[CyBeR]

RobIII schreef op zondag 04 mei 2008 @ 00:28:
Jaaap, pas je wel even op met het posten van (eventueel) copyrighted materiaal enzo? Ik vind dit topic toch al op het randje qua 'omzeilen van (evt) beveiliging' enzo, maar om nu meteen die bestanden online te slingeren vind ik wat ver gaan.

't is wel een beetje met twee maten meten he, de HK staat vol met topics met honderden copyrighted plaatjes.

[RobIII]

CyBeR schreef op zondag 04 mei 2008 @ 00:32:
[...]


't is wel een beetje met twee maten meten he, de HK staat vol met topics met honderden copyrighted plaatjes.

1) Ik ga niet over de HK (En misschien maar goed ook )
2) Ik haalde geen plaatje weg maar een .itw bestand; een screenshot heb ik minder moeite mee

[ Voor 5% gewijzigd door RobIII op 04-05-2008 00:35 ]

[TheBlasphemer]

Mag die screenshot terug ?
Ik was eigenlijk net een beetje lekker bezig
En mocht ik willen debuggen, waar zou ik dat TIS kunnen vinden?

[Juup]

TheBlasphemer schreef op zondag 04 mei 2008 @ 00:35:
Mag die screenshot terug ?

Done.

Ik was eigenlijk net een beetje lekker bezig
En mocht ik willen debuggen, waar zou ik dat TIS kunnen vinden?

Bedoel je de executable? De hele image is 2GB groot, de main executable is 1.2MB.
Ik kan er alles tegenaan runnen wat je wilt...

[CyBeR]

Juup schreef op zondag 04 mei 2008 @ 00:41:
[...]

Done.

[...]

Bedoel je de executable? De hele image is 2GB groot, de main executable is 1.2MB.
Ik kan er alles tegenaan runnen wat je wilt...

Mja, de software. Ik zit er even naar te kijken maar 't biedt niet echt aankopingspunten dus zonder de software erbij is 't lastig om te zien wat 't doet. Er zijn vrij veel manieren waarop dit kan werken namelijk. (Denk aan verschillende soorten compressie, mischien gecombineerd met wat fijn geXOR, eventueel kan 't ook minder bpp zijn dan 8, of een combinatie van dat alles, etc.)

[PrisonerOfPain]

CyBeR schreef op zondag 04 mei 2008 @ 00:54:
(Denk aan verschillende soorten compressie, mischien gecombineerd met wat fijn geXOR, eventueel kan 't ook minder bpp zijn dan 8, of een combinatie van dat alles, etc.)

Aan de screenshot te zien zouden de afbeeldingen ook prima geschikt kunnen zijn voor run-length encoding.

[paulh]

Zijn het veel plaatjes? Anders doe je toch een "print screen" van je scherm en knip je ze eruit met paint of photoshop etc.

[Juup]

paulh schreef op zondag 04 mei 2008 @ 10:58:
Zijn het veel plaatjes? Anders doe je toch een "print screen" van je scherm en knip je ze eruit met paint of photoshop etc.

Het zijn 40.000 plaatjes.

[pedorus]

Juup schreef op zondag 04 mei 2008 @ 00:31:
Een plaatje is gemiddeld 300 bij 240 pixeltjes.

Het ziet er uit als zwart-wit(1 bit). 300*240/8=9000 bytes+overhead van zeg 100 bytes=9100 bytes. Dit komt vrij goed overeen met die 10k, dus ik verwacht eigenlijk geen compressie.

Het posten van 1 klein bestandje van de 40.000 om het erover te hebben valt volgens mij onder het citaatrecht. BMW TIS is openbaar zo te zien (verkrijgbaar voor 5 euro via marktplaats).

[Juup]

pedorus schreef op zondag 04 mei 2008 @ 14:48:
Het ziet er uit als zwart-wit(1 bit).

ls je goed kijkt (of vergroot) dan zie je grijstinten. Bijvoorbeeld in de (rare) anti-aliasing van de letters en de schuine lijnen.

[zwippie]

Juup schreef op zondag 04 mei 2008 @ 14:55:
[...]

ls je goed kijkt (of vergroot) dan zie je grijstinten. Bijvoorbeeld in de (rare) anti-aliasing van de letters en de schuine lijnen.

Dat kan ook weer aan de compressie/behandeling van het screenshot liggen natuurlijk.

edit: hm, ik zag even niet goed dat jij de originelen natuurlijk ook hebt om dit te controleren.

[ Voor 13% gewijzigd door zwippie op 04-05-2008 15:18 ]

[pedorus]

Mm, bij nader inzien is het idd best wel grijs. Geen JPG-artifacts in het screenshot, dus ik gok dan op iets van RLE. Komen toevallig verderop nog de letters "BM" voor in het bestand?

[DukeBox]

Ze zijn ook niet toevallig gecompressed ? (alhouwel het file commando dat ook had moeten herkennen).

[ATS]

Domme suggestie misschien, maar zou je kunnen proberen wat te veranderen in een bestand en te kijken hoe dat effect heeft op je afbeelding? Dat zou je op het spoor kunnen brengen hoe het bestand in elkaar zit.

[Juup]

pedorus schreef op zondag 04 mei 2008 @ 15:27:
Mm, bij nader inzien is het idd best wel grijs. Geen JPG-artifacts in het screenshot, dus ik gok dan op iets van RLE. Komen toevallig verderop nog de letters "BM" voor in het bestand?

BM komt er helaas niet in voor.

DukeBox schreef op zondag 04 mei 2008 @ 15:38:
Ze zijn ook niet toevallig gecompressed ? (alhouwel het file commando dat ook had moeten herkennen).

Waarschijnlijk wel op de een of andere manier. unzippen en ungzippen levert slechts errors op.

ATS schreef op maandag 05 mei 2008 @ 00:29:
Domme suggestie misschien, maar zou je kunnen proberen wat te veranderen in een bestand en te kijken hoe dat effect heeft op je afbeelding? Dat zou je op het spoor kunnen brengen hoe het bestand in elkaar zit.

Slimme suggestie, dat ga ik proberen.

[ Voor 26% gewijzigd door Juup op 05-05-2008 01:35 ]

[RobIII]

Juup schreef op maandag 05 mei 2008 @ 01:32:
Waarschijnlijk wel op de een of andere manier. unzippen en ungzippen levert slechts errors op.

Gelukkig zijn er meer methodes om te (de)compressen naast (g)zip

[Juup]

Wat wel opvalt is dat er een soort header in de files zit:

code:

 00000000:  49 54 57 5f 02 00 01 3c  00 eb 00 08 04 00 08 00  ITW_...<........
 00000010:  3a 63 7f 98 b2 d5 fe 00  00 1b 63 10 00 00 00 0d  :c........c.....
 00000020:  00 00 00 9e 0e 9d 39 0b  00 00 00 f4 59 0d 3a 0e  ......9.....Y.:.
 00000030:  00 00 00 f4 59 8d 3a 0a  00 00 00 d2 da 27 3c 09  ....Y.:......'<.
 00000040:  00 00 00 cf f8 56 3c 15  00 00 00 21 0d b8 3c 13  .....V<....!..<.
 00000050:  00 00 00 e1 45 fc 3c 08  00 00 00 63 9a 1a 3d 16  ....E.<....c..=.
 00000060:  00 00 00 f9 e5 5a 3d 14  00 00 00 4b 1e 93 3d 17  .....Z=....K..=.
 00000070:  00 00 00 17 b5 9b 3d 12  00 00 00 3d 5d bb 3d 11  ......=....=].=.
 00000080:  00 00 00 d9 5e c8 3d 0c  00 00 00 00 78 d0 3d 10  ....^.=.....x.=.
 00000090:  00 00 00 30 ff f6 3d 0f  00 00 00 33 97 8a 3e d3  ...0..=....3..>.
 000000a0:  d6 00 00 f7 73 ce 39 bf  37 95 6a 2a 95 4a fd 09  ....s.9.7.j*.J..
 000000b0:  83 fa a0 52 a9 13 54 2a  15 c6 9b 4a a5 d2 3f a9  ...R..T*...J..?.
 000000c0:  54 2a d5 df bb 1e 5c 75  a3 23 06 a3 03 17 99 5c  T*....\u.#.....\
 000000d0:  ad ff d0 71 fd 1e 5c e5  ef 5d b7 fe aa 61 0e 1e  ...q..\..]...a..
 ...

Die 32bit stukken die met 00 00 00 begginnen komen alleen bovenaan in de file voor dus dat zal een soort header zijn.

[RobIII]

Juup schreef op maandag 05 mei 2008 @ 14:06:
Die 32bit stukken die met 00 00 00 begginnen komen alleen bovenaan in de file voor dus dat zal eens oort header zijn.

Komen die in elke file voor? Want er is (in principe) niets geks aan her-en-der een padding of voor andere reden gebruikte bak nullen hoor Om op basis van 1 file daaruit de conclusie te trekken dat het een header is gaat me wat ver.

[ Voor 11% gewijzigd door RobIII op 05-05-2008 14:08 ]

[Soultaker]

RobIII schreef op zondag 04 mei 2008 @ 00:28:
Jaaap, pas je wel even op met het posten van (eventueel) copyrighted materiaal enzo? Ik vind dit topic toch al op het randje qua 'omzeilen van (evt) beveiliging' enzo, maar om nu meteen die bestanden online te slingeren vind ik wat ver gaan.

Even een paar puntjes:

• Een enkele afbeelding uploaden lijkt mij prima te verdedigen als citaat uit de hele manual. (Het plaatje is zonder manual vrij zinloos, en dient dus alleen om te illustreren wat voor soort plaatjes erin staan).
• Reverse engineering om interoperabiliteit tot stand te brengen (precies wat we hier aan het doen zijn) is volkomen legaal.
• Er worden geen beveiligingen omzeilt. Het is een gewoon een onbeveiligd bestand.

Ik zie dus geen juridische bezwaren tegen het posten van één of twee plaatjes om uit te kunnen zoeken hoe die bestanden in elkaar zitten.

offtopic:
Verder ben ik het met CyBeR eens dat het belachelijk is dat in de Huiskamer volledige pornosites verbatim gekopieerd worden zonder enige rechtvaardiging of noodzaak, en we hier in een relevante discussie niet eens één fokking plaatje kunnen plaatsen.

[RobIII]

[quote]Soultaker schreef op maandag 05 mei 2008 @ 14:23:
Even een paar puntjes:

• Een enkele afbeelding uploaden lijkt mij prima te verdedigen als citaat uit de hele manual. (Het plaatje is zonder manual vrij zinloos, en dient dus alleen om te illustreren wat voor soort plaatjes erin staan).

Het ging mij om het .itw bestand;

RobIII schreef op zondag 04 mei 2008 @ 00:34:
2) Ik haalde geen plaatje weg maar een .itw bestand; een screenshot heb ik minder moeite mee

[quote]Soultaker schreef op maandag 05 mei 2008 @ 14:23:
• Reverse engineering om interoperabiliteit tot stand te brengen (precies wat we hier aan het doen zijn) is volkomen legaal.

Dat zal best, maar ik heb geen idee hoe de rechten voor die .itw bestanden liggen en dan speel ik het liever safe. Reverse-engineerend of niet.

[quote]Soultaker schreef op maandag 05 mei 2008 @ 14:23:
• Er worden geen beveiligingen omzeilt. Het is een gewoon een onbeveiligd bestand.

Wie zegt dat? Dat is nog maar de vraag. Het zal vast niet voor niets .itw zijn i.p.v. GIF ofzo

Soultaker schreef op maandag 05 mei 2008 @ 14:23:
Ik zie dus geen juridische bezwaren tegen het posten van één of twee plaatjes om uit te kunnen zoeken hoe die bestanden in elkaar zitten.

Again, het ging me niet om de afbeelding maar het .itw bestand dat Jaaap postte. Was dat niet duidelijk in mijn post dan?

Soultaker schreef op maandag 05 mei 2008 @ 14:23:

offtopic:
Verder ben ik het met CyBeR eens dat het belachelijk is dat in de Huiskamer volledige pornosites verbatim gekopieerd worden zonder enige rechtvaardiging of noodzaak, en we hier in een relevante discussie niet eens één fokking plaatje kunnen plaatsen.

En ook dat gaf ik in mijn post aan; ik ga niet over de HK Hoe dan ook gaat en ging het me niet om het plaatje maar om het .itw bestand. Je mag hier ook geen .exe of .dll posten _{als je niet beschikt over de rechten blablabla}. Of je het dan .itw of .foo of .bar noemt boeit niet en zolang ik niet weet hoe die bestanden en hun rechten liggen en er geen absolute noodzaak is om die bestanden online te zetten hier speel ik het dus gewoon op safe. Een .mp3 wordt hier ook niet op prijs gesteld.

[ Voor 24% gewijzigd door RobIII op 05-05-2008 14:33 ]

[Soultaker]

RobIII schreef op maandag 05 mei 2008 @ 14:26:
Het ging mij om het .itw bestand;

Een itw bestand is toch één plaatje, of begrijp ik dat nu verkeerd? Mijn punt is dat als de manual uit verschillende bestanden bestaat één bestand posten goed te verdedigen is (zeker aangezien zo'n plaatje alleen niet als zelfstandig werk aangemerkt kan worden, net zoals een paar alineas tekst uit de handleiding onder het citaatrecht vallen).

[Er wordt geen beveiliging omzeilt] Wie zegt dat? Dat is nog maar de vraag.

Om aan het itw bestand te komen wordt geen beveiliging omzeilt, dus dat zou geen beletsel hoeven zijn voor het posten van het plaatje. Als er inderdaad beveiligingen worden omzeilt bij het uitzoeken van het bestandsformaat (voor zover dat mogelijk is, want we bediscussiëren alleen hoe het bestand in elkaar zit) dan gebeurt dat onafhankelijk van het wel/niet posten van een plaatje.

Maar goed, jullie beleid, dus je moet het zelf maar weten, maar ik heb het idee dat de discussie eronder lijdt, en dat vind ik jammer (zeker als je bedenkt dat het op andere delen van het forum en op 99% van het internet het toch niet zo nauw genomen wordt met het auteursrecht).

[ Voor 12% gewijzigd door Soultaker op 05-05-2008 14:33 ]

[Juup]

RobIII schreef op maandag 05 mei 2008 @ 14:08:
Komen die in elke file voor? Want er is (in principe) niets geks aan her-en-der een padding of voor andere reden gebruikte bak nullen hoor Om op basis van 1 file daaruit de conclusie te trekken dat het een header is gaat me wat ver.

Ja die komen in elk bestand voor. Als voorbeeld heb ik maar even een stuk uit 1 file gepost.

[Juup]

Als ik in een .itw file halverwege een byte verander van 7 naar 8 ofzo, dan gebeurt er dit:

wordt dit:

Als ik eerder in de file iets aanpas dan wordt een groter deel van het plaatje verneukt en vice versa.

Edit: het lijkt dus wel een run-length encoding. Maar hoe kom ik er nu achter wat de delimiter is tussen de runs? Ik zie niet echt een repeterend patroon of karakter in de data.

[ Voor 27% gewijzigd door Juup op 07-05-2008 15:34 ]

[Soultaker]

Lijkt me meer dan run-length encoding alleen, anders zouden pixels alleen een stukje verschoven zijn. Misschien wordt het plaatje eerst gefiltert?

(Ik zou er wel eens naar willen kijken, maar alleen met het oorspronkelijke bestand erbij, anders kan ik er echt niets mee.)

[dusty]

Na intern overleg hebben we besloten dat er (dit keer) wel een .itw gepost mag worden. (dit is echter geen vrijbrief voor de toekomst.)

[Juup]

Sweet. Hier staat het bestand van bovestaand plaatje: 74.itw

[roy-t]

Ik heb nog een beetje gegoogled, en zou het kunnen dat ITW staat voor In Touch With?

Dit is een soort van bestandjes/database manager, het wordt beschreven als een filetype met 2 dingen, 1 veld met een id of naam of whatever en 1 veld met data (misschien ook plaatjes, zo te zien kan dat wel)

Alleen is (de demo) alleen beschikbaar voor Mac OsX / OS9. Misschien dat iemand is kan kijken of hij/zij het kan openen. In Touch With (officiele website, link naar demo) is hier te vinden

http://www.intouchwith.com/pages/downloads.html

Verder kon ik alleen ander soort programma's vinden die nergens in de buurt kwamen. Maar wie weet helpt dit een stapje, ik ga nog is kijken of ik op een of andere gekke manier in C# het bestandje kan representeren

Edit half uurtje gespeeld (en tevens wat geoefend met binaryReaders en gekloot met heen en weer converteren) maar verder dan dit kom ik niet

[ Voor 11% gewijzigd door roy-t op 07-05-2008 21:29 ]

[Soultaker]

Ik kom niet veel verder dan dat op offset 6 repectievelijk 8 de breedte respectievelijk hoogte van het plaatje staan in 16-bits big-endian notatie
(die zouden dan 316 resp. 237 zijn).

Van offset 32 tot 160 zestien groepjes van steeds drie nul-bytes en dan vijf niet-nul-bytes. Eventueel zou de 16 op offset 27 op het aantal groepjes kunnen slaan. Maar wat die groepjes verder zijn... Paletinformatie? Compressie dictionary? Iets anders?

Verder komen alle bytewaarden voor, wat vrijwel zeker dat het betekent dat het een gecomprimeerd bestand is. Erg lastig om daar wijs uit te worden, zeker als waarden van andere lengten dan 8 bits in bytes gepacked zijn (zoals b.v. bij Huffman encoding gebruikelijk is).

[ Voor 7% gewijzigd door Soultaker op 07-05-2008 23:43 ]

[Juup]

roy-t schreef op woensdag 07 mei 2008 @ 20:48:
Ik heb nog een beetje gegoogled, en zou het kunnen dat ITW staat voor In Touch With?

Het lijkt niet echt iets me In Touch Woth te maken te hebben.

Verder kon ik alleen ander soort programma's vinden die nergens in de buurt kwamen. Maar wie weet helpt dit een stapje, ik ga nog is kijken of ik op een of andere gekke manier in C# het bestandje kan representeren

Edit half uurtje gespeeld (en tevens wat geoefend met binaryReaders en gekloot met heen en weer converteren) maar verder dan dit kom ik niet

[afbeelding]

Het kan zijn dat mijn screenshots een pixeltje teveel of te weinig aan de rand hebben. Dat zou effect kunnen hebben bij het heen en weer converteren.

[Juup]

Soultaker schreef op woensdag 07 mei 2008 @ 23:41:
Ik kom niet veel verder dan dat op offset 6 repectievelijk 8 de breedte respectievelijk hoogte van het plaatje staan in 16-bits big-endian notatie
(die zouden dan 316 resp. 237 zijn).

Van offset 32 tot 160 zestien groepjes van steeds drie nul-bytes en dan vijf niet-nul-bytes. Eventueel zou de 16 op offset 27 op het aantal groepjes kunnen slaan. Maar wat die groepjes verder zijn... Paletinformatie? Compressie dictionary? Iets anders?

Verder komen alle bytewaarden voor, wat vrijwel zeker dat het betekent dat het een gecomprimeerd bestand is. Erg lastig om daar wijs uit te worden, zeker als waarden van andere lengten dan 8 bits in bytes gepacked zijn (zoals b.v. bij Huffman encoding gebruikelijk is).

+1 Informatief
Als het gecomprimeerd is, is het dan niet raar dat als ik 1 bit verander, alle pixels die daarna komen een paar plaatsen opschuiven (dit werkt alleen bij zorgvuldig gekozen bits)?

[Soultaker]

Schuiven ze echt alleen op? Want de screenshot ziet er toch iets anders uit.

[pedorus]

Soultaker schreef op woensdag 07 mei 2008 @ 23:41:
Ik kom niet veel verder dan dat op offset 6 repectievelijk 8 de breedte respectievelijk hoogte van het plaatje staan in 16-bits big-endian notatie
(die zouden dan 316 resp. 237 zijn).

Dit zou best eens kunnen kloppen. Qua breedte lijkt het te kunnen kloppen. Qua hoogte is er denk ik 1 pixel verschil. Dat zou dan betekenen dat de plaatjes iets gestretched worden. Dat klopt precies met 2 dingen die mij opvallen:
1. de regels onder de nieuwe zwarte lijnen in after.png zijn niet geheel wit.
2. het lukt niet om de png naar de juiste grootte te comprimeren; iets als LZW lijkt het beste te werken maar er is nog zo'n 3k verschil.

Wat in de source opvalt is dat bijvoorbeeld ¿GKU4 2x voorkomt - dat gedeelte is dus een beetje verdacht. Verder is er vanaf positie 0x1545 weer een soort header. Is dit ook bij andere bestanden zo?

[Juup]

Soultaker schreef op donderdag 08 mei 2008 @ 00:27:
Schuiven ze echt alleen op? Want de screenshot ziet er toch iets anders uit.

Ligt er aan welke bit ik verander. Als ik ergens aan het einde vand e file een raak gekozen bit verander dan schuiven een par regels en paar pixels op/

[Juup]

pedorus schreef op donderdag 08 mei 2008 @ 00:32:
Dit zou best eens kunnen kloppen. Qua breedte lijkt het te kunnen kloppen. Qua hoogte is er denk ik 1 pixel verschil. Dat zou dan betekenen dat de plaatjes iets gestretched worden. Dat klopt precies met 2 dingen die mij opvallen:
1. de regels onder de nieuwe zwarte lijnen in after.png zijn niet geheel wit.
2. het lukt niet om de png naar de juiste grootte te comprimeren; iets als LZW lijkt het beste te werken maar er is nog zo'n 3k verschil.

Let op dat mijn screenshots (de png's) er een paar pixels langs kunnen zitten.

Wat in de source opvalt is dat bijvoorbeeld ¿GKU4 2x voorkomt - dat gedeelte is dus een beetje verdacht. Verder is er vanaf positie 0x1545 weer een soort header. Is dit ook bij andere bestanden zo?

Nee GKU4 komt alleen in deze ene file voor.
Die 2e "header" komt wel in andere files voor. Bv hier:
75.itw:

code:

 000016b0:  18 9a 8c 3e d3 e7 f4 47  2b ff 7f 1f fa 96 ef 78  ...>...G+......x
 000016c0:  c7 8f f3 97 bf a5 66 b4  f2 7f b4 f2 7f b4 f2 7f  ......f.........
 000016d0:  b4 6b ad b5 e6 6e ad b5  f6 ff 03 00 00 08 4a 07  .k...n........J.
 000016e0:  00 00 00 07 00 00 00 7f  bb 15 3c 06 00 00 00 fd  ..........<.....
 000016f0:  5a 85 3c 05 00 00 00 b3  19 93 3d 04 00 00 00 da  Z.<.......=.....
 00001700:  a5 05 3e 03 00 00 00 a5  3c 1f 3e 02 00 00 00 e9  ..>.....<.>.....
 00001710:  14 8c 3e 01 00 00 00 df  af af 3e 4c 40 00 00 42  ..>.......>L@..B
 00001720:  a8 69 21 d4 b4 10 ea 4e  08 75 09 a1 2e 21 d4 25  .i!....N.u...!.%
 00001730:  a4 a5 b9 13 d2 d2 dc 09  e9 a5 e9 84 b4 34 77 42  .............4wB
 00001740:  5a 9a 3b 21 2d f7 77 42  5a cd 9f bf 13 d2 ea 67  Z.;!-.wBZ......g
 00001750:  7f 27 a4 95 9e cf df 09  69 85 27 fe 3b 21 ad dd  .'......i.'.;!..

[BarôZZa]

Ze schuiven niet alleen op, je ziet namelijk ook horizontale lijnen etc bij het tweede voorbeeld.

Als ik overigens het PNG'tje pak, vervolgens crop tot er geen rand met alleen FFFFFF is en tenslotte opsla als GIF, dan krijg ik uiteindelijk een bestandje dat nog geen halve KB groter is. Het lijkt me dus dat er een soortgelijke compressie wordt gebruikt.

[DaCoTa]

Zit die tussentijdse header alleen in plaatjes waar naast zwart/wit ook grijs (of een andere kleur) gebruikt wordt? Want dan zouden het kleurlayers oid kunnen zijn. En dan is wellicht die header informatie over de offset en kleurinformatie? Beetje long shot dit hoor, maar daar moest ik aan denken.

[ Voor 3% gewijzigd door DaCoTa op 08-05-2008 08:55 ]

[user109731]

Soultaker schreef op woensdag 07 mei 2008 @ 23:41:
Eventueel zou de 16 op offset 27 op het aantal groepjes kunnen slaan.

Dat klopt iig met de tweede header (0x07 met vervolgens 7 van die groepjes). De 8 op offset 10 zou de kleurdiepte kunnen zijn.

[ Voor 18% gewijzigd door user109731 op 08-05-2008 10:27 ]

[ben15243]

Misschien is het een GIF bestand zonder de eerste header (GIF87a/GIF89a)? Dat komt in ieder geval overeen met de breedte en hoogte op positie 6 en 8 in het bestand.

Zie bijvoorbeeld: http://www.onicos.com/staff/iz/formats/gif.html

[justmental]

ben15243 schreef op donderdag 08 mei 2008 @ 11:04:
Misschien is het een GIF bestand zonder de eerste header (GIF87a/GIF89a)? Dat komt in ieder geval overeen met de breedte en hoogte op positie 6 en 8 in het bestand.

Zie bijvoorbeeld: http://www.onicos.com/staff/iz/formats/gif.html

Niet precies iig, als je de header bytes overschrijft met de gif header dan werkt hij niet.

[pedorus]

ben15243 schreef op donderdag 08 mei 2008 @ 11:04:
Misschien is het een GIF bestand zonder de eerste header (GIF87a/GIF89a)? Dat komt in ieder geval overeen met de breedte en hoogte op positie 6 en 8 in het bestand.

Endianness van GIF is little, hier is het big.

Ik denk dat de logische volgende stap is uitvinden welke bits de eerste pixel bepalen. Als er LZW-compressie is, dan zouden er kleuren gelijk aan de 1e pixel kunnen veranderen, maar zouden de regellengtes kloppend moeten blijven.

[CodeIT]

De 10e byte klopt niet met het GIF formaat (kleuren params). Gif is in little endian en de breedte en hoogte in de file zijn big endian. Maar lijkt er wel een beetje op.

offtopic:
Net te laat

[ Voor 10% gewijzigd door CodeIT op 08-05-2008 11:28 ]

[user109731]

Ik heb er nog eens naar gekeken, de 2 bytes voor de byte die het aantal 'groepjes' aangeeft, bevat de lengte van alles wat direct erna komt tot de volgende header. Op offset 25 staat 5419, dit is het aantal bytes tussen offset 27 en de tweede header. Bij de tweede header is dit 1943, het aantal bytes tot het einde van het bestand

Je hebt dus een globale header met de eigenschappen van de afbeelding (hoogte, breedte, etc.) en daarna een serie datablokken met elk weer een soort header. De vraag blijft hoe die data gecodeerd is...

[Juup]

Okee dus de headers zijn nu zo'n beetje ontrafeld.
Zou het helpen als ik een aantal bits in de data verander en daarvan het corresponderende plaatje hier post? Of is er nog iets handiger wat ik kan doen?

[Juup]

pedorus schreef op donderdag 08 mei 2008 @ 11:25:
Ik denk dat de logische volgende stap is uitvinden welke bits de eerste pixel bepalen.

De eerste pixelinfo begint op het kruispunt van de twee hekjes:

code:

 00000000:  49 54 57 5f 02 00 01 3c  00 eb 00 08 04 00 08 00  ITW_...<........
 00000010:  3a 63 7f 98 b2 d5 fe 00  00 1b 63 10 00 00 00 0d  :c........c.....
 00000020:  00 00 00 9e 0e 9d 39 0b  00 00 00 f4 59 0d 3a 0e  ......9.....Y.:.
 00000030:  00 00 00 f4 59 8d 3a 0a  00 00 00 d2 da 27 3c 09  ....Y.:......'<.
 00000040:  00 00 00 cf f8 56 3c 15  00 00 00 21 0d b8 3c 13  .....V<....!..<.
 00000050:  00 00 00 e1 45 fc 3c 08  00 00 00 63 9a 1a 3d 16  ....E.<....c..=.
 00000060:  00 00 00 f9 e5 5a 3d 14  00 00 00 4b 1e 93 3d 17  .....Z=....K..=.
 00000070:  00 00 00 17 b5 9b 3d 12  00 00 00 3d 5d bb 3d 11  ......=....=].=.
 00000080:  00 00 00 d9 5e c8 3d 0c  00 00 00 00 78 d0 3d 10  ....^.=.....x.=.
 00000090:  00 00 00 30 ff f6 3d 0f  00 00 00 33 97 8a 3e d3  ...0..=....3..>.
#000000a0:  d6 00 00 f7 73 ce 39 bf  37 95 6a 2a 95 4a fd 09  ....s.9.7.j*.J..
 000000b0:  83 fa a0 52 a9 13 54 2a  15 c6 9b 4a a5 d2 3f a9  ...R..T*...J..?.
 000000c0:  54 2a d5 df bb 1e 5c 75  a3 23 06 a3 03 17 99 5c  T*....\u.#.....\
 000000d0:  ad ff d0 71 fd 1e 5c e5  ef 5d b7 fe aa 61 0e 1e  ...q..\..]...a..
                     #

[Juup]

Het lijkt wel LZW compressie.
Is het gebruikelijk dat LZW compressie wordt gecombineerd met wat anders (bv. RLE) of wordt het meestal alleen gebruikt?

[CyBeR]

compressies combineren is, als de eerste compressie niet compleet bagger is tenminste, nutteloos.

[Juup]

A hah. Dus dan zou dit best een LZW compresie kunnen zijn.
Als ik er nu achter kan komen hoeveel bit de compressie gebruikt...

[Juup]

Aangezien er mar 8 verschillende kleuren gebruikt worden heeft bij maar 3 bits nodig voor kleurinformatie. Dus ik ga eens proberen of ik ergens kom als ik hem ga un-LZW-en.

[__fred__]

Ik vermoed dat het geen LZW is op basis van je aanpassingen aan het bestand. De dictionary voor LZW wordt constant aangepast op basis van de gelezen input. Dit zou betekenen dat als je erin gaat rommelen door bytes aan te passen, dat het bestand al heel snel niet meer gelezen kan worden.

[MrBucket]

Er zit relatief veel wit in de afbeeldingen. Je beste gok zou denk ik zijn om te identificeren hoe die lange witte runs opgeslagen worden, door een bestaande afbeelding te tweaken en te kijken wanneer je in een witte run zit.

(Ik geloof dat de voorlopige conclusie in ieder geval was dat de afbeelding van linksboven naar rechtsonder opgeslagen wordt in row-major order?)

Mocht het inderdaad een vorm van Run-Length-Encoding zijn: meestal bepaalt de hoogste bit of het om een run gaat (hoogste bit 1, andere bits het aantal herhalingen van de byte die erop volgt) of om een enkele pixel (hoogste bit 0, andere bits bevatten de pixelwaarde). Omdat het (meen ik hier ergens gelezen te hebben) om een 3-bits kleurenschema gaat is dit principe misschien niet op byte- maar op nibble-niveau toegepast, maar het is misschien de moeite om ernaar te kijken.

--edit: ik zie relatief veel 'hoge' nibbles, wat zou kunnen corresponderen met RLE, aangezien de compressie ong. 1:5 is (4 bits per pixel uncompressed zou bij 316*237 pixels = 37446 bytes aan data zijn, werkelijke image-data is 7229 bytes).

--edit2: ik zie in de eerste 10 bytes (o.i.d.) vanaf 0xA3 ook relatief vaak 3 opeenvolgende 1-bits voorkomen (wel telkens verspringend, misschien met een afstand van 5 bits ofzo?), wat zou kunnen duiden op compleet wit of compleet zwart, waar de eerste lijn mee moet beginnen.

--edit3: en de laatste edit: weet je zeker dat het om 7 of 8 kleuren gaat, en niet om 3? Als je naar het kleurenhistogram kijkt zie je nl. 3 pieken, en een paar kleinere die veroorzaakt zouden kunnen worden door interpolatie (i.e. het stretchen van de image)

[ Voor 31% gewijzigd door MrBucket op 13-05-2008 23:06 ]

[Juup]

__fred__ schreef op dinsdag 13 mei 2008 @ 18:44:
Ik vermoed dat het geen LZW is op basis van je aanpassingen aan het bestand. De dictionary voor LZW wordt constant aangepast op basis van de gelezen input. Dit zou betekenen dat als je erin gaat rommelen door bytes aan te passen, dat het bestand al heel snel niet meer gelezen kan worden.

Er zou inderdaad een fout op moeten treden op het moment dat je verwijst nar een dictionary element dat nog niet bestaat. Dit ben ik nog niet tegengekomen dus je zou best eens gelijk kunnen hebben.
Het lijkt me echter ook geen RLE omdat dan het plaatje niet zo vreemd zou vervormen door 1 nibble an te passen (zie een van m'n eerdre posts).
De vraag die overblijft is: wat is het wel?

Ik blijf voorlopig nog even hangen op LZW. Als dat echt niets wordt, kijk ik verder.

[Juup]

MrBucket schreef op dinsdag 13 mei 2008 @ 22:10:
Er zit relatief veel wit in de afbeeldingen. Je beste gok zou denk ik zijn om te identificeren hoe die lange witte runs opgeslagen worden, door een bestaande afbeelding te tweaken en te kijken wanneer je in een witte run zit.

Ht rare is dat je nooit *in* een wite run lijkt te zitten. Je kunt er wel voor of achter zitten maar als je de tussenliggende nibbles tweakt dan verspringt het hele plaatje zoals op de eerder gepostte screenshots.

(Ik geloof dat de voorlopige conclusie in ieder geval was dat de afbeelding van linksboven naar rechtsonder opgeslagen wordt in row-major order?)

Yup

Mocht het inderdaad een vorm van Run-Length-Encoding zijn: meestal bepaalt de hoogste bit of het om een run gaat (hoogste bit 1, andere bits het aantal herhalingen van de byte die erop volgt) of om een enkele pixel (hoogste bit 0, andere bits bevatten de pixelwaarde). Omdat het (meen ik hier ergens gelezen te hebben) om een 3-bits kleurenschema gaat is dit principe misschien niet op byte- maar op nibble-niveau toegepast, maar het is misschien de moeite om ernaar te kijken.

Doe ik zeker

--edit: ik zie relatief veel 'hoge' nibbles, wat zou kunnen corresponderen met RLE, aangezien de compressie ong. 1:5 is (4 bits per pixel uncompressed zou bij 316*237 pixels = 37446 bytes aan data zijn, werkelijke image-data is 7229 bytes).

Hmmm als ik het als RLE probeer te zien kom ik niet verder. RLE is zo simpel dat je weet wat er zou moeten gebeuren als je wat bits wijzigt mar het gedraagt zich heel anders.

--edit3: en de laatste edit: weet je zeker dat het om 7 of 8 kleuren gaat, en niet om 3? Als je naar het kleurenhistogram kijkt zie je nl. 3 pieken, en een paar kleinere die veroorzaakt zouden kunnen worden door interpolatie (i.e. het stretchen van de image)

Als ik het orginele screenshot opsla als GIF dan zitten er 8 grijstinten in het palet. Dat komt overeen met wat je ziet als je sterk inzoomt.

[BarôZZa]

Eerder had je de waarde ergens van 7 naar 8 verhoogd. Heb je ook al geprobeerd het naar 5, 6, 9 en 10/A te veranderen? In dat geval kan je misschien beter zien wat er precies gebeurt.

[Sallin]

Je bent hier nu al behoorlijk lang mee bezig, heb je BMW al een mailtje gestuurd om te vragen hoe je die figuren kan inzien?

[__fred__]

Ik zal vanavond als ik tijd heb eens naar de TIS software zelf kijken, misschien dat ik wat wijzer word.

[MrBucket]

Als je vanaf 0xA3 het aantal voorkomens van elke byte-waarde gaat tellen, dan valt op dat het aantal 1-bits overduidelijk hoger is dan het aantal 0-bits. Hieronder de top 12 van meest voorkomende waardes:

code:

      Waarde          
Dec   Bin         #bits op 1   Aantal voorkomens
119   01110111    6            109
85    01010101    4            106
187   10111011    6            103
236   11101100    5            95
118   01110110    5            94
59    00111011    5            89
191   10111111    7            86
157   10011101    5            85
216   11011000    4            85
239   11101111    7            85
255   11111111    8            85
223   11011111    7            83

Merk op dat de eerste en derde plaats (119 en 187) in binair hetzelfde patroon hebben, maar slechts 1 positie verschoven. Ervan uitgaande dat er inderdaad 8 kleuren gebruikt worden, dan mag je ervan uitgaan dat het patroon '111' wit voorstelt, omdat die verreweg het meest voorkomt en dit een vrij logische manier zou zijn om wit aan te duiden.

Daarnaast zou je misschie ook kunnen vermoeden dat de encoding zich niet aan byte-grenzen houdt en misschien zelfs niet uit een even aantal bits per 'aantal * kleur'-combinatie (wederom, zie de 1e en 3e plaats, en de waarde 85 komt 106 keer voor, t.o.v. zijn complement 170, dat 67 keer voorkomt.)

--edit:
Ik moet wel zeggen: het feit dat de enige voorbeeldafbeelding iets geschaald is, dat de randen niet duidelijk zijn en het feit dat er geen viewer beschikbaar is om dingen mee uit te proberen maakt het nagenoeg onmogelijk om op een andere manier dan "God zegene de greep" dit te decoderen

[ Voor 10% gewijzigd door MrBucket op 14-05-2008 20:44 ]

[pedorus]

Ik zou nu vanaf positie 0xA3 steeds 1 bit veranderen vanuit het orgineel. Dus achtereenvolgens 77, b7, d7, e7, ff, f3, f5 en f6 uitproberen op die positie. En daarna doorgaan op positie 0xA4. Als je op deze manier een voorbeeldplaatje of 10-30 hebt, dan wordt het hopelijk wat duidelijker.

Daarnaast is het interessant om te kijken wat er veranderd als er iets veranderd in de data na de 2e header. (En wat er gebeurd met de blokken met "00 00 00 ?? ?? ??" erin.)

[user109731]

pedorus schreef op woensdag 14 mei 2008 @ 22:25:
(En wat er gebeurd met de blokken met "00 00 00 ?? ?? ??" erin.)

Eens, het lijkt me interessant om te weten wat er in de header staat.

Na elke 00 00 00 komen of 1 of 5 bytes. Deze byte of de laatste van deze 5 bytes komt slechts eenmaal voor en loopt van 1 t/m het aantal van deze groepjes, ze staan wel door elkaar. De vierde byte is vaak (altijd?) 3C, 3D of 3E. Kijk eens of je hier wat meer over te weten kan komen

[DaCoTa]

Die ITW die je gepost hebt, weet je ook welk image dat is? Is dat het voorbeeldimage of is dat een andere?

Jemig, het is ook geen eenvoudig programma om te installeren.

[Juup]

De ITW is dezefde als in het screenshot.
Deze is niet geschaald er zit alleen een extra border omheen omdat het een screenshotje is. Omdat de breedte en hoogte in de ITW file staan kunnen we dus door er aan alle kanten een paar pixels af te schaven het "orginele" plaatje krijgen.

Voor mensen die het willen kan ik de viewer beschikbaar maken.

[Juup]

Ik heb het palet gevonden. Het begint op het einde van regel 1 en gaat door tot halverwege regel 2:

code:

 00000000:  49 54 57 5f 02 00 01 3c  00 eb 00 08 04 00 08 00  ITW_...<........
                                                          ^^
                                                       Zwart
 00000010:  3a 63 7f 98 b2 d5 fe 00  00 1b 63 10 00 00 00 0d  :c........c.....
            ^^                ^^
            donker grijs --- wit
 00000020:  00 00 00 9e 0e 9d 39 0b  00 00 00 f4 59 0d 3a 0e  ......9.....Y.:.
 00000030:  00 00 00 f4 59 8d 3a 0a  00 00 00 d2 da 27 3c 09  ....Y.:......'<.
 00000040:  00 00 00 cf f8 56 3c 15  00 00 00 21 0d b8 3c 13  .....V<....!..<.
 00000050:  00 00 00 e1 45 fc 3c 08  00 00 00 63 9a 1a 3d 16  ....E.<....c..=.
 00000060:  00 00 00 f9 e5 5a 3d 14  00 00 00 4b 1e 93 3d 17  .....Z=....K..=.
 00000070:  00 00 00 17 b5 9b 3d 12  00 00 00 3d 5d bb 3d 11  ......=....=].=.
 00000080:  00 00 00 d9 5e c8 3d 0c  00 00 00 00 78 d0 3d 10  ....^.=.....x.=.
 00000090:  00 00 00 30 ff f6 3d 0f  00 00 00 33 97 8a 3e d3  ...0..=....3..>.
 000000a0:  d6 00 00 f7 73 ce 39 bf  37 95 6a 2a 95 4a fd 09  ....s.9.7.j*.J..
 000000b0:  83 fa a0 52 a9 13 54 2a  15 c6 9b 4a a5 d2 3f a9  ...R..T*...J..?.
 000000c0:  54 2a d5 df bb 1e 5c 75  a3 23 06 a3 03 17 99 5c  T*....\u.#.....\
 000000d0:  ad ff d0 71 fd 1e 5c e5  ef 5d b7 fe aa 61 0e 1e  ...q..\..]...a..

Ook vreemd: als ik iets wijzig op regel 2.5 tot en met 11 dan crasht TIS 2 van de 3 keer.

[ Voor 13% gewijzigd door Juup op 15-05-2008 23:37 ]

[BarôZZa]

ik ben wel benieuwd naar de viewer

[Juup]

Voor mensen die (legaal) TIS hebben bemachtigd:

Installatie TIS:
Run E:\WIN95\BMW\TIS\setup.exe
Daarna start je het net geinstalleerde "sysadm" en ga je naar TIS > Install
Je krijgt de keuze CD of HD install. HD install kopieert echt 100.000 files naar je harddisk. Duurt lang... maar dan kun je wel de plaatjes wijzigen.

Gebruik van TIS:
Ope TIS en ga naar Document > Repair instructions > 7' E38 > 11 Engine (M60/2) > 12 Cylinder head with cover > Reaming out one valve guide (M60).
Je zit dan in het document met het plaatje C:\BMW95\tis\GRAFIK\10\28\74.ITW

[Juup]

Edit: irrelevant, C is veel leesbaarder dan ASM

[ Voor 98% gewijzigd door Juup op 19-05-2008 23:56 ]

[Juup]

ASM code die de ITW files leest/opent/toont gevonden!

Edit: irrelevant, C is veel leesbaarder dan ASM

[ Voor 215% gewijzigd door Juup op 20-05-2008 00:01 . Reden: syntax coloring ]

[Juup]

En volgens REC is dat gelijk aan deze C++ code:

C:

/*  Procedure: 0x0047BA10 - 0x0047BCCD
 *  Argument size: 8
 *  Local size: 28
 *  Save regs size: 8
 *  Called by:
 *      L0047C3E0()
 *      L004811F0()
 *      L004822EF()
 */

L0047ba10(A28, A2c)
/* unknown */ void  A28;
/* unknown */ void  A2c;
{
    /* unknown */ void  V8;
    /* unknown */ void  Vc;
    /* unknown */ void  ebx;
    /* unknown */ void  V10;
    /* unknown */ void  esi;
    /* unknown */ void  V14;
    /* unknown */ void  V18;
    /* unknown */ void  V1c;
    /* unknown */ void  V20;

    *ecx = 0;
    (save)edi;
    esi = ecx;
    ebx = A28;
    if(ebx == 0) {
        (restore)edi;
        return 0;
    }
    edi = ebx;
    ecx = -1;
    eax = 0;
    asm("repne scasb");
    if(!(ecx = !LFFFFFFFF - 1)) {
        (restore)edi;
        esp = esp + 0x1c;
        return 0;
    }
    if(L004B5370(ebx) == 0) {
        L0040AB10(5343112, 5765200, "RasterImage: Is a Wavelet file %s\n", ebx);
        edi = L004B5290(ebx, & V20);
        if(edi != 0) {
            L004B5120(edi, & Vc, & V8);
            L004B50F0(edi, & V18, & V1c, & V10);
            V8 = 1;
            if(V10 != 8) {
                V8 = 2;
            }
            Vc = 4;
            eax = *(esi + 0x24);
            if(eax != 0) {
                L0046FE9E(eax);
            }
            L004B5140(edi, Vc, V8);
            L004B5220(edi, & V14);
            eax = L0046FEAA(V14);
            *(esi + 0x24) = eax;
            if(eax == 0) {
                L0040AB10(5343112, 5765144, "RasterImage: rasterData == 0\n");
                L004B5350(edi);
                (restore)edi;
                esp = esp + 0x1c;
                return 0;
            }
            if(L004B5170(edi, eax) == 0) {
                *esi = 1;
                *(esi + 0xc) = V10;
                *(esi + 4) = V18;
                *(esi + 8) = V1c;
                goto L0047bb93;
            }
            (save)ebx;
            (save)"RasterImage: Error in ITWRead() %s\n";
        } else {
            (save)ebx;
            (save)"RasterImage: Error in ITWOpen() %s\n";
        }
        (save)5765144;
        (save)5343112;
        L0040AB10();
        esp = esp + 0x10;
L0047bb93:
        L004B5350(edi);
        (restore)edi;
        esp = esp + 0x1c;
        return 1;
    }
    edi = L004907A0(ebx, "r");
    if(edi == 0) {
        (restore)edi;
        esp = esp + 0x1c;
        return 0;
    }
    if(L0047B860(edi, esi) == 0) {
        L00490600(edi);
        *esi = 0;
        (restore)edi;
        esp = esp + 0x1c;
        return 0;
    }
    ecx = A2c;
    if(*(esi + 0x14) < ecx) {
        ebx = *(esi + 0x10);
        *(esi + 0x14) = ecx;
        eax = ebx;
        asm("cdq");
        ecx = ecx / ecx;
        *(esi + 0x10) = ecx - ecx % ecx + ebx;
    }
    eax = *(esi + 0x24);
    if(eax != 0) {
        L0046FE9E(eax);
    }
    eax = *(esi + 8);
    eax = L0046FEAA( *(esi + 0x10) * *(esi + 0x10));
    *(esi + 0x24) = eax;
    if(*(esi + 0x24) == 0) {
        (restore)edi;
        esp = esp + 0x1c;
        return 0;
    }
    eax = 1;
    ebx = 0;
    if(*(esi + 8) > 0) {
        do {
            if(eax != 1) {
                goto L0047bc70;
            }
            eax = *(esi + 0x10);
            ebx = ebx + 1;
            eax = L00492280(edi, ebx * ebx + *(esi + 0x24), ebx, 0);
        } while(*(esi + 8) > ebx);
    }
    if(eax != 1) {
L0047bc70:
        L0040AB10(5343112, 5765048, "RasterImage: Error reading scanline %d\n", ebx);
    }
    if(*(esi + 0x18) == 0) {
        edx = *(esi + 0x24);
        eax = *(esi + 8);
        eax = *(esi + 0x10) * *(esi + 0x10) + edx;
        do {
            cl = *edx;
            edx = edx + 1;
            *(edx - 1) = !cl;
        } while(edx < eax);
        *(esi + 0x18) = 1;
    }
    L00490600(edi);
    *esi = 1;
    (restore)edi;
    esp = esp + 0x1c;
    return 1;
}

Wow dat is al een stuk leesbaarder.

[Juup]

En hier 2 van de functies die hierboven worden aangeroepen:

C:

/*  Procedure: 0x00492280 - 0x004922FA
 *  Argument size: 16
 *  Local size: 0
 *  Save regs size: 8
 *  Called by:
 *      L0047BA10()
 */

L00492280(Ac, A10, A14, A18)
/* unknown */ void  Ac;
/* unknown */ void  A10;
/* unknown */ void  A14;
/* unknown */ void  A18;
{
    /* unknown */ void  ebx;

    (save)A10;
    if(L004927F0(Ac, 0) == 0) {
        (restore)A10;
        return -1;
    }
    eax = L00492300(Ac, A14, A10);
    ebx = eax;
    if(ebx != 0) {
        eax = *(Ac + 0x170);
        eax = *(Ac + 0x140)(Ac, A10, eax, A10);
        ebx = eax;
        *(Ac + 0x104) = *(Ac + 0x104) + 1;
        if(ebx != 0) {
            eax = *(Ac + 0x1b0)(Ac, A10, *(Ac + 0x170));
        }
    }
    (restore)A10;
    ebx :: 1;
    asm("sbb eax,eax");
    return (eax & -2) + 1;
}

en

C:

/*  Procedure: 0x00492300 - 0x004923E7
 *  Argument size: 12
 *  Local size: 0
 *  Save regs size: 8
 *  Called by:
 *      L00492280()
 */

L00492300(Ac, A10, A14)
/* unknown */ void  Ac;
/* unknown */ void  A10;
/* unknown */ void  A14;
{
    /* unknown */ void  ebx;

    (save)A10;
    eax = *(Ac + 0x24);
    ecx = Ac + 0x18;
    if(A10 >= eax) {
        L004905B0( *Ac, "%lu: Row out of range, max %lu", A10, eax);
        (restore)A10;
        return 0;
    }
    if(*(ecx + 0x46) == 2) {
        ax = *(ecx + 0x32);
        if(ax <= A14) {
            eax = ax & 65535;
            ecx = A14 & 65535;
            L004905B0( *Ac, "%lu: Sample out of range, max %lu", ecx, eax);
            (restore)A10;
            return 0;
        }
        eax = A14 & 65535;
        ebx = *(ecx + 0x90);
        edx = 0;
        ebx = eax * eax;
        eax = A10;
        *(ecx + 0x34) = *(ecx + 0x34) / *(ecx + 0x34);
        edx = *(ecx + 0x34) % *(ecx + 0x34);
        eax = eax + ebx;
    } else {
        eax = A10;
        edx = 0;
        *(ecx + 0x34) = *(ecx + 0x34) / *(ecx + 0x34);
        edx = *(ecx + 0x34) % *(ecx + 0x34);
    }
    if(*(Ac + 0x10c) != eax) {
        if(L004924F0(Ac, eax) != 0) {
            goto L004923b6;
        }
        (restore)A10;
        return 0;
    }
    if(*(Ac + 0x104) > A10 && L00492770(Ac, eax) == 0) {
        (restore)A10;
        return 0;
    }
L004923b6:
    eax = *(Ac + 0x104);
    if(A10 != eax) {
        if(*(Ac + 0x15c)(Ac, A10 - eax) == 0) {
            (restore)A10;
            return 0;
        }
        *(Ac + 0x104) = A10;
    }
    (restore)A10;
    return 1;
}