ILDA Dateien auslesen in C#

[Tobias K. (tobias_k622)]

Hallo,

brauche folgende Anwendung: eine .ild Datei in C# auslesen (für eine 
Lasershow).

Brauche keine fertigen Code. Gibt es jedoch irgendwo ein gutes Tutorial 
oder eine Anleitung?

Bitte um kurze Rückmeldung.

MfG
Tobias

[jmp (Gast)]

Hallo Tobias, das kommt darauf an, ob das .ild ein Textfile oder ein 
binäres File ist.

Für Text:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/file-system/how-to-read-from-a-text-file

Für binär:
https://docs.microsoft.com/en-us/dotnet/api/system.io.binaryreader

--jmp

[Stephan (Gast)]

...und hier die "andere" seite:
https://www.ilda.com/technical.htm
Dort insb. "ILDA Image Data Transfer Format"

[Tobias K. (tobias_k622)]

Hallo,

keine Ahnung was .ild für ein Dateiformat ist. Im Anhang sieht man, dass 
der  ausgegebene Code komisch ist.

MfG
Tobias

[und zu (Gast)]

Tobias K. schrieb:
> keine Ahnung was .ild für ein Dateiformat ist.
Dann belasse es besser dabei.
Es sind XY-RGB-Daten zu einzelnen Stützpunkten die per Laser abgefahren 
werden.
Wenn Du der Meinung bist, dass der
> Im Anhang sieht man, dass der  ausgegebene Code komisch ist.
dann wirst Du es auch nicht hin bekommen einen Parser dafür zu bauen.
Btw. gibt es auch noch mehrere ILDA-Formate teilweise mit Farbpaletten 
usw.

[Tobias K. (tobias_k622)]

Ich frage genau deswegen im Forum, weil ich es eben nicht hinbekomme 
einen geeigneten Parser zu bauen. ;)

Gibt es irgendwelche Hilfestellungen im www, habe schon gesucht aber 
vergeblos

[Andreas M. (amesser)]

Ich würde vorschlagen die Spezifikation zu lesen und danach 
implementieren. Fertig. Lächerliche 22 Seiten, Überall im Internet zu 
finden.

[Tobias K. (tobias_k622)]

Wo finde ich so wichtige Infos? Suchen wie ILDA Files auslesen, etc. 
waren nicht sehr hilfreich :(

[Stephan (Gast)]

Tobias K. schrieb:
> Wo finde ich so wichtige Infos?

??
z.B. in meinem Beitrag von 14:03

[Andreas M. (amesser)]

https://www.letmegooglethat.com/?q=ilda+Format+specification

Sind sogar nur 17 Seiten.

[Hugo H. (hugo_hu)]

Stephan schrieb:
> z.B. in meinem Beitrag von 14:03

Und - wo ist der fertige Arduino-Code dazu? Mach mal hin ;-)

[Stephan (Gast)]

Hugo H. schrieb:
> Stephan schrieb:
>> z.B. in meinem Beitrag von 14:03
> Und - wo ist der fertige Arduino-Code dazu? Mach mal hin ;-)
s.u.a:
Tobias K. schrieb:
> Brauche keine fertigen Code.
;)

Lieber TO:
(kannst/willst/magst keinen Parser schreiben) || (weisst Du nicht wie 
das ILDA File-Format ist)

Für zweiteres: steht doch in der obigen Format-Beschreibung. ILDA.org 
war so freundlich, Dir das sogar alles aufzuschreiben.

Für ersteres: wie immer: was hast Du denn schon in (C#) codiert? und wo 
klemmt's genau...?

[Tobias K. (tobias_k622)]

Hallo,

Hier mein bisheriger Code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;

namespace test_ilda
{
    class Program
    {
        static void Main(string[] args)
        {
            FileStream fs = new FileStream("bandsag.ild", FileMode.Open);
            BinaryReader br = new BinaryReader(fs);

            int ausgabe;

            for(int i = 0; i<100;i++) //100 ist eine beliebige Zahl :)
            {
                ausgabe = br.ReadInt32();
                Console.WriteLine(ausgabe);
            }
            

            Console.ReadLine();
        }

    }
}

Problem: Was mache ich mit diesen Werten? Habe die .pdf schon 100x 
durchgelesen, kenne mich jedoch nicht aus.

[Oliver S. (oliverso)]

Tobias K. schrieb:
> Problem: Was mache ich mit diesen Werten?

Mal ganz blöd gefragt: wenn du nicht weißt, was das Datenformat 
überhaupt darstellt, und nicht weißt, was du mit dem Daten machen 
sollst, warum willst du da was parsen?

Oliver

[Tobias K. (tobias_k622)]

Warum werde ich wohl in einem Forum fragen? Genau, weil ich mich nicht 
auskenne. Deshalb gibt es ja ein FORUM um Hilfe von anderen zu bekommen, 
und keine abwägigen Kommentare zu erhalten. Anstatt mir unnützes Wissen 
reinzudrücken (ich möchte diejenigen jetzt nicht ansprechen, die mir 
schon besser geholfen haben mit Links zu hilfreichen Seiten, etc.) 
könntet ihr mir helfen oder es einfach lassen. Punkt aus!

[Oliver S. (oliverso)]

Und? Hast du das Data-Dokument auch gelesen?

Die Daten beginnen mit einem Header.

Dazu steht in dem Dokument:

4.2. Field Description
4.2.1. "ILDA"
Bytes 1 – 4. The ASCII letters ILDA, identifying an ILDA format header.
…

Du kannst jetzt mal raten, was dir diese Worte sagen wollen.
Wenn du drauf kommst, gehe weiter zu Byte 5 ff. Wenn nicht, such dir ein 
anderes Hobby.

Oliver

[Stephan (Gast)]

Tobias K. schrieb:
> ausgegebene Code komisch ist.

1.)
Wenn Du diese Ausgabe mit dem von Dir dargestellten Progrämmchen 
erstellt hast, dann ist VOR den eigentlichen ILDA-Daten noch etwas 
anderes (gefühlt 2kByte)

Die ILDA Daten fangen mit "ILDA" im Header an...
Das ist bei anderen IDLA-Files (die ich im Netz gefunden habe) auch so.
Auch die Datei "bandsag.ild" (die man ebenfalls im Netzfindet) fängt 
korrekterweise mit "ILDA" an...
Irgedwas ist also schon mal an Deiner Datei "krumm"...

2.)
Ansonsten: Byte(-gruppen)-weise nach einlesen und die eingelesenen Daten 
in Deine programminternen Strukturen/Klassen schreiben/mappen...
Schematisches Beispiel:
Byte(s) [1..4] nach HEADER.ILDA_ID[4]
Byte(s) [5..7] nach HEADER.RSVD_1[3]
Byte(s) [8] nach HEADER.FORMATCODE[1]
...
Byte(s) [32] nach HEADER.RSVD_2[1]

Durch die Daten dann blockweise UND FormatCode-längenabhängig 
durchiterieren. Endianess prüfen!

3.)
Was auch immer Du dann mit den Daten machen möchtest... nur zu.

[Random .. (thorstendb)]

Das ILDA Format ist recht simpel aufgebaut, meisst aus gleich großen 
Einträgen, die jeweils über einen Header erkannt werden.
Für einen Player (in C auf Cortex-M3) habe ich die komplette Spec in 
mehrere struct/union gegossen, so kann man da ganz einfach 
durchspazieren und spart sich buffer increments.
Achtung: Alle 16Bit Daten sind BE!

https://www.ilda.com/resources/StandardsDocs/ILDA_IDTF14_rev011.pdf

Vom Prinzip her:

typedef _PACKED struct {       // 1..32
  _PACKED union {
    unsigned char buf[32];      // 32 byte
    
    _PACKED struct {
      _PACKED union {
        char  key[4];           // 1..4   "ILDA"
        unsigned int keyNum;    
        
        _PACKED struct {
          char key1;
          char key2;
          char key3;
          char key4;
        };
      };
            
      char  ZERO0;              // 5
      char  ZERO1;              // 6
      char  ZERO2;              // 7
      char  formatCode;         // 8      Format Code
      
      _PACKED union {
        char  frameName[8];     // 9..16  Frame Name
        char  paletteName[8];   // 9..16  Palette Name
      };
      
      char  companyName[8];     // 9..16  Frame Name
      
      _PACKED union {
        short totalPoints;      // 25..26 Total points
        short totalColors;      // 25..26 Total colors
      };
      
      _PACKED union {
        short frameNumber;      // 27..28 Frame Number
        short paletteNumber;    // 27..28 Palette Number
      };
      
      short totalFrames;        // 29..30 Total Frames
      char  scannerHead;        // 31     Scanner Head
      char  future;             // 32     Reserved for future use
    };
  };
} ILDA_Header_t;

[weiter weg (Gast)]

Random .. schrieb:
> Achtung: Alle 16Bit Daten sind BE!

Dass diese Abkürzung mit Indianern zu tun hat ist nicht
jedem Anfänger klar, daher dürftest du hier ruhig ohne
Abkürzung schreiben.

[Random .. (thorstendb)]

weiter weg schrieb:
> Random .. schrieb:
>> Achtung: Alle 16Bit Daten sind BE!
>
> Dass diese Abkürzung mit Indianern zu tun hat ist nicht
> jedem Anfänger klar, daher dürftest du hier ruhig ohne
> Abkürzung schreiben.

Werd ich dann beim nächsten Frühstücks-Ei machen 🙈 🤣🤣🤣

Für die nicht eingew(ei)hten: BE = Big Endian. Die Motorola-CPUs, welche 
für die ersten ILDA Anwendungen verwendet wurden, speichern und 
bearbeiten ihre Daten im Big Endian Format. Für gängige Mikrocontroller 
und den PCs muss man das nach LE = Little Endian konvertieren, was bei 
16 Bit im Endeffekt eine Vertauschung der beiden Bytes bedeutet.

Auf dem Cortex-M recht elegant per Intrinsic lösbar:

uint16_t outVal = __REVSH(inVal);

Achso, was hat das ganze mit dem Frühstücks-Ei zu tun? Die Frage nach 
BE/LE ist fast so alt wie die, auf welcher Seite man das Ei am besten 
aufschlägt 🤣
Beides hat Vor- und Nachteile, LE scheint sich mehr durchgesetzt zu 
haben.

[weiter weg (Gast)]

Beim nächsten Erscheinen von LE/BE ist es wieder scheisse
weil Abkürzungen mit zwei Buchstaben einfach zu wenig
Eindeutigkeit bzw. Aussagekraft haben.

[Random .. (thorstendb)]

weiter weg schrieb:
> Beim nächsten Erscheinen von LE/BE ist es wieder scheisse
> weil Abkürzungen mit zwei Buchstaben einfach zu wenig
> Eindeutigkeit bzw. Aussagekraft haben.

Der kontextbasierte Leser weiss mehr!

[weiter weg (Gast)]

Random .. schrieb:
> Der kontextbasierte Leser weiss mehr!

... erst ab dem Zeitpunkt ab dem er mit der unzulänglichen
Abkürzung vertraut gemacht worden ist.

weiter weg schrieb:
> Beim nächsten Erscheinen von LE/BE ist es wieder scheisse

meint dass ein neuer Thread mit dieser Abkürzung unter den
selben Missverständnissen bzw. Uneindeutigkeiten zu leiden
hat.

[Hugo H. (hugo_hu)]

Oliver S. schrieb:
> Und? Hast du das Data-Dokument auch gelesen?

Möglicherweise kann er seine Schuhe selbst binden :-)

[Andreas M. (amesser)]

Tobias K. schrieb:
> Hier mein bisheriger Code:

Ohje, das ist ja nicht viel mehr als Öffnen und Dateinhalt ausgeben. 
Parsen von Binärdateien hast Du vermutlich noch nie gemacht? Ich habe 
mal kurz gesucht, aber ein wirkliches Beispiel in C# an dem Du dich 
langhangeln könntest habe ich dafür nicht gefunden.

Vielleicht mal so als Startpunkt: Im Prinzip musst du die Datei Stück 
für Stück einlesen und die einzelnen Datenelemente enstprechende der 
Spezifikation interpretieren. Fangen wir mal mit dem Header an:

ILDA_IDTF14_rev011.pdf, Figure 2: Achtung ich habe wenig ahnung von C#. 
Offsets in der Spec sind 1 referenziert ( normalerweise beginnt man bei 
0)

BinaryReader br = new BinaryReader(fs);

byte[] header = new byte[32];

/* read header */
br.Read(header, 0, 32);

if(header[0:4] != "ILDA")
  parse_error();

/* read format code offset 8 */
byte format_code = BitConverter.ToUInt8(header, 8 - 1);

byte[] palette_name = header[9-1:16-1];
byte[] company_name = header[17-1:24-1];

/* ILDA data is big endian, need to swap bytes */
if (BitConverter.IsLittleEndian)
{
  Array.Reverse(header, 25-1,2);
  Array.Reverse(header, 27-1,2);
...
}

uint number_of_records = BitConverter.ToUInt16(header, 25-1);
...

Und so weiter.

[Edit:] Nachtrag der Code oben ist nur als Startpunkt zu sehen, da lässt 
sich noch einiges massiv optimieren oder besser kapseln. Paar 
Syntaxfehler korrigiert, lesen sollte man auch können :-).
[Edit2]: Brauch mehr Kaffee ...

[Andreas M. (amesser)]

Random .. schrieb:
> Einträgen, die jeweils über einen Header erkannt werden.
> Für einen Player (in C auf Cortex-M3) habe ich die komplette Spec in

Ich weis nicht wie Deine Compiler/MPU settings sind, aber Packing 
alleine kann bewirken, dass der Compiler beim Zugriff jedes Byte einzeln 
einliest und dann zusammensetzt. Das ergibt dann sehr viele 
Instruktionen. Wenn man weis, das die Datenstruktur immer auf anständig 
alignten Adresse liegt, dann kann man beim gcc zusätzlich zum packing 
das alignment Attribut nutzen um dem compiler zu hefen. Bei 
parse-lastigen Funktionen kann das zu einer drastischen Code Reduktion 
und Performanceverbesserung führen. (Das Byte-weise Einlesen eines 
uint32_t benötigt 7 einzelne Instruktionen)

Ich habe bei dem folgenden Beispiel absichtlich mal das compiler flag 
angeschaltet, so das der gcc sich nicht auf die MPU verlässt. Es kommt 
auch ein bisl auf die Hardware/Speicherbereich an, wo man sich bewegt ob 
ein unalignter Zugriff ne Excpetion auslöst oder von der MPU/MMU korrekt 
behandelt wird)

https://godbolt.org/z/E7eejPGrG

[Random .. (thorstendb)]

Andreas M. schrieb:
> aber Packing
> alleine kann bewirken, dass der Compiler beim Zugriff jedes Byte einzeln
> einliest und dann zusammensetzt.

Die Daten werden in einen globalen Byte-Buffer per fread() eingelesen, 
und dann über Pointer auf die structs und deren Member verarbeitet. Da 
sollte nichts schiefgehen, und mir ist im Assembly auch nichts 
aufgefallen.

Die structs sind dicht, __packed dient nur dazu, dass der Compiler nicht 
auf dumme Gedanken kommt, wie z.B. das Umsortieren oder komplette 
Zerreissen eines structs im Speicher. Die structs dienen letzlich nur 
als Schablone zum Ablesen der Daten.