www.LaserFreak.net

Hallo Freaks,

nach nunmehr fünf Jahren Beratungszeit ist auf der Webseite der International Laser Display Association endlich ein Entwurf für die neue Spezifikation das 'ILDA Image Data Transfer Format' zu finden. Link (unter Technology -> Technical Standards)

Dieser enthält die Erweiterung des Formats um 24 Bit RGB-Farbe.

Auch werden die Headerinformationen nun anders interpretiert, so dass es möglich ist unbekannte Blöcke sicher zu überspringen. Die alte, unsichere Vorgehensweise, blind nach dem nächsten Vorkommen der Zeichenfolge 'ILDA' zu suchen ist damit abgelöst. So ist der Weg auch für zukünftige (auch Herstellerspezifische) Erweiterungen frei, ohne dass man Inkompatibilitäten befürchten müsste.

Ich habe mal eine Testdatei mit RGB-Farbformat erzeugt:
truecolor.ild - Datei mit RGB-Format (gezipt)
truecolor-colortable.ild - Datei mit RGB-Format und Farbtabelle (gezipt)
notruecolor.ild - Normales ILDA-Format, keine RGB-Farbe (gezipt)
(Alle Dateien gezipt)

Dann bin ich mal gespannt, ob es schon Software gibt, die diese Dateien lesen kann.

Liebe Programmierer von Lasershowsoftware, lasst uns das Farbtabellen-Desaster möglichst bald beenden.

Grüße,
afrob

Tjaja, als die "neuen" Änderungen, an denen 5 Jahre herumgepopelt wurden, im Oktober in Las Vegas vorgestellt wurden, hats nicht wirklich irgendjemanden vom Stuhl gerissen.
Ist so ähnlich wie "Himem.sys" bei MS-DOS.
Überall was dazugepatcht, um ja abwärtskompatibel zu bleiben.
Der Vorschlag, das Format doch komplett zu überdenken, und den heutigen technischen Anforderungen anzupassen, hat in Las Vegas fast zum Eklat geführt. Einige deutsche Teilnehmer haben fast Harakiri begangen, so dass dieser jetzige Standard von allen Teilnehmern widerwillig angenommen wurde - um ein weiteres Blutbad zu verhindern.

Fazit: das Format ist ein schlecht zusammengebastelter Murks, aber ist eben wie in der Politik. Nix halbes und nix ganzes.

Man bedenke: Die ILDA hat für diesen Meilenstein in der Lasertechnologie 5 Jahre lang gebraucht

moing mong,


jipieeeeee

jetzt muss man nur noch alle alten Files umwandeln....
ne quatsch bei seite. Vielleicht wird das ja endlich mal was.
Ich werd`s mir "reinziehen"

Gruß
Erich

Eines von 3 Files läßt sich darstellen. Habe mit Anarchy und dem Ilda Import von LDS getestet. Okay, Anarchy konnte nur das erste Frame dastellen, wobei man nicht von Rainbow Colors sprechen kann. Habs dann sein gelassen. LDS PicEdit hat da schon mehr gebracht. Aber Afrob, mußte es wirklich so viele Points sein?
Okay die Ausgabe sieht nicht wirklich gut aus. Eigentliche Verbindungslinien, die Farbig in der Vorschau dargestellt werden, haben plötzlich Unterbrechungen durch Blanking. Naja, kann ich mich nur Jürgen anschließen, haut mich erst mal nicht um. Aber die Vorschau sieht schon mal nett aus.

komische sache.

im grunde hat man nicht wirklich viel geändert an diesem format.
wieso so umständlich über die farbtabelle? man könnte doch gleich die rgb daten zu jedem punkt hinzufügen. also x/y/z/r/g/b mehr braucht man doch nun wirklich nicht.

meine meinung

mfg thomas

ThomasF hat geschrieben:komische sache.

im grunde hat man nicht wirklich viel geändert an diesem format.
wieso so umständlich über die farbtabelle? man könnte doch gleich die rgb daten zu jedem punkt hinzufügen. also x/y/z/r/g/b mehr braucht man doch nun wirklich nicht.

meine meinung

mfg thomas

Damit verlierst du die Abwärtskompatibilität.

John

PS. Pangolin 3.50 quittiert Afrobs Frames mit einem "Falscher Dateityp" und zeigt kein Frame. Was nützt abwärtskompatibles Dateiformat, wenn die Software unbekannte Teile nicht wie in dem Standard beschrieben überspringt???

also x/y/z/r/g/b mehr braucht man doch nun wirklich nicht.

Tja, theoretisch würde RGB reichen, praktisch ist es eher eine billige Lösung. Den Unterschied merkt man sehr schnell, wenn noch andere Farben hinzukommen, wie ein UV-nahes Blau. In nächster Zukunft wird es diese auch bei Festkörperlasern geben, deshalb sollte man sich da nichts verbauen.

Bei der Abwärtskompatibilität ist es aber fraglich, wieweit es sinnvoll ist.
Das ILDA-Format war ja bisher doch nur eine Notlösung. Die meisten Profisysteme verwenden ihr eigenes Format und benutzen ILDA nur um fremde Shows mal zu importieren. Bzw., wenn es darum geht, bei einem Festival o.ä. Shows von verschiedenen Leuten vorzuführen. Wobei die Qualität solcher Vorführungen sowieso eher bescheiden ist, als wenn man es selber in die Hand nehmen würde.

Wozu sollte in einem Format sämtliche Komatibilitäten untergebracht werden. Man könnte auch genauso gut eine alte ILDA-Show über <Importieren> in sein System laden.

Gruß.

Thomas hat geschrieben:[Die meisten Profisysteme verwenden ihr eigenes Format und benutzen ILDA nur um fremde Shows mal zu importieren.
...
Man könnte auch genauso gut eine alte ILDA-Show über <Importieren> in sein System laden.

Genau dazu war ILDA gedacht. Es ist ein "Transferformat", kein Showausgabeformat. Allerdings auf dem Stand von "Amiga"-zeiten.

Und hast Du schon mal eine ILDA-Datei importiert und "schnell mal eben abgespielt"?. Da das Format keinerlei Zeitinformation enthält, passt michts mehr. Man siehts z.B. an den ganzen Shows im LDS, welche aus ILDAs importiert wurden - kann man alle vergessen.

Es gibt übrigens einen Grund, dass das ILDA-Format so unvollständig ist: Die Softwarefirmen wollen nicht, dass Ihre Shows ohne Qualitätsverlust auf ein anderes System transferiert werden.

Wenn man die alten QM32 Frames mit Ilda(256 Col) vergleicht die sind fast gleich.
Ebenso ist das LDS Frameformat(das jetzige) genauso Inhalts(-farb)arm und leicht zu lesen

Stufenlose Farben verlangen viele PpS sonst wirken die nicht.

Welche Systeme benutzen denn mehr Farben wie 256 von möglichen 2 xxx xxx je Frame ?

LTF von Rolf & mir entworfen unterstützte damals nur LA-Studio ....... jetzt unter Pangolin Vermarktet auch noch ?

Lobo stellte mal eine Anfrage wer die Rechte hat und ob Sie es benutzen dürften.

In meinen Augen ist Ilda nur eine Basis um Frames zu gebrauchen und keine Show.

Ist Ätzend eine Pangolinshow ins LDS umzuwandeln bei Frameraten die schwanken zwischen 20-90 Frames je Sekunde .... es geht so eben , aber mehr nicht. (Da muß ich JoJo recht geben)

lg Gento

p.s. das neue Ilda noch nicht ganz kapiert hat

Moin,

Richtig Gento, die LDS Frams haben nur 64 Farben . Für einen Farbverlauf werden die dazwischenligenden Farben in Realtime erzeugt. Eine für mich recht fragliche Lösung.

Nehmen wir halt eine Frameformat welches 6 mal 8 bit Farbtiefe hat. Unsere Festplatten werden auch immer Größer. Wieso dann diese Kompression.

Moderne Shows will ich nicht auf einem Amiga abspielen...

Gruß Thomas

ThomasF hat geschrieben:Nehmen wir halt eine Frameformat welches 6 mal 8 bit Farbtiefe hat.

Soviel braucht man nicht.
Theoretisch reicht RGB (16 Mio Farben).
Das Problem ist nicht die Speicherung der Farben, sondern die Umsetzung bei verschiedenen Farbsystemen.

Wie soll ein 8 Kanal PCAOM mit RGB angesteuert werden?
Wie soll ein RGB-DPSS mit 6 Farben angesteuert werden?

Moin,

richtig. Muß halt jede Software das umrechnen. Es ist eh jeder Laser anders auch Kristalle muß man unterschiedlich ansteuern.

daher meine Vorschlag:

Kopf
erkennung
framename
Scannspeed - 16 bit
dies kann man ja in den ersten zwei zeilen unterbringe

dann kommen die punkte je eine zeile mit:

x/y/z- 16bit
R/G/B- 8bit

das sollte doch jede software lesen können...

Gut ist natürlich das Problem mit der Show weitergabe.

Gruß Thomas

Bei dem 'Neuen' Ilda Format ist mir einiges nicht ganz klar

Dürfen Format 0 + 1 + 3 vermischt werden innerhalb eines Files ?
Wie handhabt Ihr das ............... ?

Hab ich was übersehen oder hat man das Z im Format 3 unterschlagen ?

Gruß Gento

Moins,

ich mag das alte ILDA-Format nicht. Ich sah mir ILDA RGB an und mochte es noch weniger. Warum muss man Exchange und Ausgabeformat so weit trennen ? Ist RGB mit 8 Bit Tiefe nicht genug ?
Ich denke ULF wird noch interessant , auch für viele Hobbyprogrammierer. Wenns fertig ist es ein Ausgabeformat mit Echtzeitinfos , RGB und kann sogar innerhalb des Showfiles neben ILDA Frames auch TTL und DMX Frames tragen. Jojo bastelt gerade dran, eine frühe Version verwendet mein ILDA-Player für DAC und Easylase.

Gento hat geschrieben:Dürfen Format 0 + 1 + 3 vermischt werden innerhalb eines Files ?

Format 0 und 1 sind 3D und 2D Frames. Diese sind identisch zum alten Standard.
Format 3 sind die neuen "true color" Daten die für jeden Punkt des darauf folgenden Frames (Format 0 oder 1) jeweils ein Byte für Rot Grün und Blau enthalten.

Die Datei sollte also folgendermassen aufgebaut sein:
Format 3: Farben für Frame 1
Format 0 oder 1: Frame 1 XY(Z) Koordinaten mit Paletten-Farbe; genau wie im alten Standard
Format 3: Farben für Frame 2
Format 0 oder 1: Frame 2 XY(Z) Koordinaten und Paletten-Farbe
...

Ein altes Programm wird dann lesen:
Format 3: unbekannt , such nach nächstem "ILDA"
Format 0 oder 1: normales Frame 1 nach altem Standard
Format 3: unbekannt , such nach nächstem "ILDA"
Format 0 oder 1: normales Frame 2 nach altem Standard
...

Also wird das Programm nach altem ILDA-Standard die Datei auch korrekt lesen.

Guido hat geschrieben:Ich denke ULF wird noch interessant ,

Ein zweites LTF? So lange Pangolin, Laseranimation und LOBO es nicht unterstützen ist es als Austauschformat uninteressant. Jeder Hersteller hat sein eigenes, viel, viel besser Showformat...

Grüsse,
afrob

Hai Afrob .

In dem File sind Fehler: truecolor.ild - Datei mit RGB-Format (gezipt)

'Scanner_Blank:=Ilda_2D[P_Menge].Status_Pos AND $40' meldet immer der Laser ist an, also 0. (Status Code)

Grüße Gento

Habe die Datei gerade noch mal mit dem Hex-Editor überprüft: Bei den geblankten Punkten ist Farbe 0 gewählt und das Blanking-Bit gesetzt, der Status-Code ist also 0x4000. Vielleicht erwischst du mit Status_Pos nicht das richtige Byte?

Grüsse,
afrob

mein fehler

Das Du @Afrob eins der ganz wenigen , sparsam gesähten 2D Ilda Files (XY) im Verbund (einmalig) mit Truecolor geschrieben hast hab ich in der 2 D Deklaration Byte '37-38' verdreht.

Ilda_3D_Array = RECORD
X_Pos : Integer ;
Y_Pos : Integer ;
Z_Pos : Integer ;
Status_Pos : Byte ;
Col_Pos : Byte ;
END;

Ilda_2D_Array = RECORD
X_Pos : Integer ;
Y_Pos : Integer ;
Col_Pos : Byte ; <<<<<<<<<<<<<<<< hier
Status_Pos : Byte ; <<<<<<<<<<<<<<<< & hier
END;


Ilda_Col_Array = Record
R :Byte;
G :Byte;
B :Byte;
end;
VAR
Ilda_2D : ARRAY[0..30000]OF Ilda_2D_Array;
Ilda_3D : ARRAY[0..30000]OF Ilda_3D_Array;
Ilda_Col : ARRAY[0..30000]OF Ilda_Col_Array;
Array_Datei : FILE;


Wenn man die Farben nur benutzt fiel das nicht auf.



lg Gento

halli hallo,

also....
erst mal kurz zur Erinnerung:

Format 3: Farben für Frame 1
Format 0 oder 1: Frame 1 XY(Z) Koordinaten mit Paletten-Farbe; genau wie im alten Standard
Format 3: Farben für Frame 2
Format 0 oder 1: Frame 2 XY(Z) Koordinaten und Paletten-Farbe

das bedeutet dann, wenn gerade ein Format_3 "Header" und die dazugehörenden farben eingelesen wurden, dass beim darauf folgenden Format 0 bzw 1 die Farbnummern Ignoriert werden müssen, sonst stimmts ja wieder nicht.


Frage: ist es IMMER so, dass erst format 3 und dann format 0 oder 1 kommt? Oder kann das auch anders rum sein? (das währ äußerst dumm!!!!! sonst müsse man ja noch eine Abfrage mit rein bauen, war RGB schon da, oder kommts am ende noch????)

Noch eins:
Ist es , wenn RGB Daten im Ilda File verwendet werden trotzdem erlaubt eine Farbtabelle (Format 2 Header) im Ilda File mit zu liefern? Das ist doof.... weil ich meine Software jetzt a bisserl geändert habe. Sie verwendet nach wie vor eine Farbtabelle, aber jetzt mit viel mehr farben. Tauchen RGB Farben auf, dann "Ermittle" ich anhand der RGB werte die korekte Farbnummer aus meiner Farbtabelle.
Wenn jetzt aber die Ilda datei ZUSÄTZLICH eine Farbtabelle dabei hat, dann stimmt natürlich meine Ermittlung der Farbnummer nicht mehr, weil die Farbtabelle jetzt andere Farben bekommen hat. (ich bestimme die Farben per formel... welche farben tatsächlich in der tabelle sind juckt dabei nicht).
Denn dadurch versaut sich das RGB wieder

Irgendwie ist Ilda format DOOF!!!!!!!!

früher hatte ich in meinem eigenen Dateiformat (hes) zu jedem Punkt die RGB daten gespeichert. Dann bin ich (wegen ILDA und weil doch schöner zu bedinen) auf Farbtabelle umgestiegen (254 farben). Jetzt hab ich die Farbtabelle erweiter..... (weil bei RGB sonst kaums schöne Farbverläufe zu machen sind).

JETZT währe es wieder besser, ich verwende zwar eine Farbtabelle, speichere aber für jeden Punkt doch wieder die RGB Farbwerte, damit das "Ilda File" zufrieden ist

Naja...

ich lass meine Soft jetzt so... kann RGB ildas lesen, kann farbtabellen lesen, und was weis ich.. und wenns nicht klapt, dann ligts am ILDA MISCHMASCH....

Gruß derweil
Erich

Tschosef hat geschrieben:Frage: ist es IMMER so, dass erst format 3 und dann format 0 oder 1 kommt?

Ja. Die Truecolortabelle MUSS laut Standard VOR dem Koordinatenframe kommen.

Tschosef hat geschrieben: Ist es , wenn RGB Daten im Ilda File verwendet werden trotzdem erlaubt eine Farbtabelle (Format 2 Header) im Ilda File mit zu liefern?

Ja. Da im Koordinatenfile ja trotzdem eine Angabe zur Palettenfarbe stehen kann, kann wahlweise die Farbpalette oder die Truecolortabelle genommen werden. Das Leseprogramm muss beides lesen können, kann aber selbst entscheiden, ob Truecolor oder Palette genommen wird.
Beides gleichzeitig ist natürlich Quatsch, aber durchaus möglich.
Am besten nimm Truecolor, wenn ein Truecolorframe Typ 3 vorausgeht und nimm Palette, wenn dieser nicht vor einem Typ 0,1-Frame kommt.

Joachim