Diskussion:Datamatrixcode

Natürlich werden Lesegeräte angeboten, die asynchron ein Bild mit sehr kurzen Integrationszeiten einlesen, so dass eine Bewegung bis zu 8m/sec möglich ist. Hier hängt es im wesentlichen von der Technologie des Sensors und der Beleuchtung ab. Bei Verwendung eines CCD Bildsensors muss dieser asynchron triggerbar sein. Bei Verwendung eines CMOS Bildsensors muss dieser über einen Snapshot Mode verfügen.

Zum Thema 1D- Barcode:

Es gibt nicht nur Barcode mit 2 verschiedenen Balkenstärken. Der Code 128 beispielsweise verfügt über 4 verschiedene Balkenstärken. Auch die Lücken eines Barcodes gehen in die Wertigkeit des Codes ein.

Der Data Matrixcode mit der geraden Zahl an Modulen ist der ECC200. Die Data Matrix Code mit einer ungeraden Zahl ist der ECC 000- 140 mit der Ziffer wird der Korrekturalgorithmus spezifiziert.

Der Data Matrix Code kann auch ein heller Code auf dunklem Hintergrund sein. Man spricht dann von einem Inverscode.

-- 84.58.153.22 16:29, 11. Jun. 2007 (CEST)

Habe den entsprechenden kurzen Abschnitt geändert (müßte eigentlich komplett geändert werden, gefällt mir immer noch nicht). Die Geschwindigkeit bei Verwendung einer Zeilenkamera hängt wesentlich von der Auflösung und der Zeilenfrequenz ab, d.h. auch mehr als 8 m/s wären möglich, bisher aber wohl nicht im Einsatz, weil der Transport von Briefen mit 25 km/h doch ziemlich heftig ist... --Chrysalis 16:12, 7. Jul. 2007 (CEST)

Varianten

Wie viel verschiedene Varianten gibt es in 1558 Bytes mit 8 Bit/Byte?--91.67.156.126 18:04, 20. Dez. 2008 (CET)

Mich würde interessieren: Ist die Verwendung dieses Codes einer Lizenzgebühr unterworfen oder kostenfrei?--217.91.66.220 15:38, 19. Mär. 2009 (CET)

Die Verwendung des Codes ist kostenfrei, d.h. es ist keine Lizenzgebühr erforderlich.

Eigenschaften: "bei bestimmten Seitenverhältnissen auch rechteckigen" Welche Logik... Gründe für die Verwendung von rechteckigen Codes sind Platzmangel oder gekrümmte Oberflächen. Insbesondere im Automobilbau kommt diese Form z.B. bei der Beschriftung von Nockenwellen zum Einsatz. Probleme sind die häufig stark reflektierende Oberfläche, was eine spezielle Ausleuchtung erfordert, sowie die stärker werdende Verzerrung bei zunehmender Codehöhe. Als Faustformel gilt: der DataMatrix Code sollte sich nicht mehr als 5% über den Umfang ausdehen. Alternativ werden Zeilenkameras verwendet und die Nockenwelle wird so lange gedreht, bis der Code gelesen wurde. Diese Alternative erfordert allerdings einen höheren Aufwand beim Maschinenbau. "Die Größe des ... Codebildes wird dabei aus einer großen Auswahlmenge bestimmt, die Symbol-Elemente sind quadratisch oder rund." a) Was für eine Auswahlmenge?? b) Im optimalen Zustand sollten die Elemente quadratisch oder rund sein. Wird ein Code auf Glas gelasert, ist dies aber Wunschdenken. "..nicht mehr zwei verschiedene Balkenbreiten in der Folge eindeutig bestimmt, wie beim eindimensionalen Barcode (1D-Code)..." Falsch. Es ist nur EINE Breite. Jeder Balken stellt ein Bit dar. Sind aufgrund der Codierung zwei Bits gesetzt, ist der Balken halt doppelt so breit. "...sondern die Anordnung der gleich großen Punkte innerhalb der Berandung (Suchmuster) und im Raster der Matrix." Falsch. Das Suchmuster - auch "L" genannt - bestimmt die Position und Orientierung/Lage. Das Taktmuster (äußere Zeile bzw. Spalte gegenüber vom "L") bestimmt die Ausrichtung und Größe der einelnen Elemente innerhalb der Matrix. "Die Punkte sind schwarze oder weiße Kästchen, die aneinander anschließen, oder runde Punkte mit Lücken dazwischen." Falsch. Besser: "dunkle und helle Kästchen". Mittlerweile werden fast nicht sichtbare Codes mit gerade mal 4% Kontrast aufgebracht. Dies kann z.B. rot auf etwas dunklerem rot sein. "...und der feste Symbolabstand allein schon machen das Lesen des Bildes und das Dekodieren der Information deutlich sicherer ..." Hier ist wohl der Abstand der einzelnen Elemente gemeint und nicht der "feste Symbolabstand".

Aufbau des Codebildes "2. Die den geschlossenen Kanten gegenüberliegende Ecke

   Diese Ecke erlaubt das schnelle Erkennen der Codeschemata. Beim Codeschema ECC 200 mit einer geraden Anzahl Zeilen und Spalten ist das Element in der oberen rechten Ecke stets weiß. Bei den anderen genormten Codeschemata mit einer ungeraden Zeilen- und Spaltenzahl ist das Element in der oberen rechten Ecke stets schwarz. "

Das Einzige, was man an der Ecke erkennen kann, ist, ob es sich um einen ECC200 Code handelt oder nicht. Anhand der Ecke kann keine Aussage getroffen werden, um welches Schema es sich im Bereich ECC 0-140 handelt. Wie schon zuvor von einem anderen User erwähnt, gibt es auch Inverscodes. Bei denen ist natürlich auch die Ecke oben rechts invertiert, so dass es eben nicht "stets schwarz" ist. "Mit dem DataMatrix-Code 144x144 ECC 200 (zuzüglich Suchmuster und Ausrichtungsmuster) lassen sich bis zu 1558 Bytes..." Worauf bezieht sicht das "zuzüglich Suchmuster und Ausrichtungsmuster"? Auf die Anzahl Zeilen/Spalten? Dann ist es falsch. Die Maximale Größe ist 144x144 Elemente INKLUSIVE der Muster. Oder bezieht es sich auf die Anzahl der möglichen Informationen im Code? Dann ist es ebenso falsch, da die Muster datenfrei sind.

Lesegeräte "Daher müssen 2D-Barcodes mit einer Lichtquelle flächig beleuchtet werden." 2D-Barcode: Eine Bezeichnung die von Laien fälschlicher Weise verwendet wird. Korrekt heisst es: 2D-Code. Dies ist etwa vergleichbar mit dem Wort Walfisch, wobei der Wal ja ein Säugetier ist und kein Fisch. Was bedeutet: flächig? Ist dies überhaupt ein Wort? Ist hiermit nicht eher gemeint: Daher müssen 2D-Codes mit einer Lichtquelle gleichmäßig beleuchtet werden. "Das vom 2D-Code reflektierte Licht wird dann in einer „Bildebene“, zum Beispiel einem CMOS-Sensor, scharf abgebildet." Scharf? Das entspricht wieder dem Theoretiker. In der Praxis kommt es insbesondere bei Direktmarkierungen vor, dass der Scanner das Bild zuverlässiger auswerten kann, wenn es etwas unscharf ist.

"Zeilenscanner sind ungebräuchlich und nicht so sicher in der Abbildung des Codebildes." Korrekt ist, dass sie seltener zu finden sind. Falsch ist jedoch die Aussage, dass sie nicht so sicher in der Abbildung des Codebildes seien. Ich würde in einer Applikation mit hohen gleichförmigen Geschwindigkeiten eine Zeilenkamera vorziehen.

Druckanforderungen "Der DataMatrix-Code stellt genau spezifizierte Anforderungen an Farbkontrast und Druckqualität..." Jein. Laut Spezifikation: ja. In der Praxis: nein. So wird laut Spezifikation ein Mindestkontrast von 20% angegeben. Wie zuvor erwähnt können heutige Bildverarbeitungsmechanismen in den Scannern ein Bild mit 4% Kontrast so aufbereiten, dass der Code ausgelesen werden kann.

"...lesbar über die Lebensdauer der gekennzeichneten Produkte" Manchmal wäre das schön. Ein Kolben im Brennraum wird aber seine gelaserte Markierung durch Abbrand nach einer Weile verlieren.

Allgemeines: Es sollte noch etwas über Markiertechniken mit Vor- und Nachteilen geschrieben werden. (nicht signierter Beitrag von 145.253.239.234 (Diskussion | Beiträge) 14:04, 18. Mär. 2010 (CET))

Ich befürchte Deine Anmerkungen werden hier vergammeln. Pflege sie doch gleich selbst in den Artikel ein. -- Krille 22:01, 28. Mär. 2010 (CEST)

Jedes Teilfeld kann wie ein einzelner DataMatrix-Code ausgewertet werden

Von 84.191.122.148 gelöschten Satz " Jedes Teilfeld kann wie ein einzelner DataMatrix-Code ausgewertet werden" wieder hergestellt, weil zutreffend. Siehe Google-Suche Liebe Grüße aus Darmstadt! Rolf29 19:19, 7. Mai 2010 (CEST)

Wie ich schon dem Typen geantwortet habe, der sagt, ich soll auf die Spielwiese: die Spezifikation sagt: "The data regions are separated from each other by two-module-wide alignment patterns. This will result in some of the symbol characters being split between two adjacent data regions.", dh einzelne Datenbytes sind über mehrere Regionen gestreut. Und wer versucht zB die linke obere Region des "Lorem ipsum" Symbols auf der englischen Wikipedia zu lesen, wird keinen Erfolg haben. Google mag sagen daß es geht, Theorie und Praxis sagen das Gegenteil ("Selbst wenn alle einer Meinung sind, können sie doch Unrecht haben" Bertrand Russell) (nicht signierter Beitrag von 84.191.122.148 (Diskussion | Beiträge) 19:43, 7. Mai 2010 (CEST))

Wenn dem so ist ("die Spezifikation sagt [hingegen]: "The data regions are separated from each other by two-module-wide alignment patterns. This will result in some of the symbol characters being split between two adjacent data regions.", dh einzelne Datenbytes sind über mehrere Regionen gestreut."), bietet sich doch eine im Artikeltext entsprechende, anschließende, einschränkende Information an. Ich kann das nicht einschätzen bzw. nicht beurteilen. Und: Beiträge in der Diskussion bitte signieren (mit den drei blauen ~~ unten ) Liebe Grüße aus Darmstadt! Rolf29 20:18, 7. Mai 2010 (CEST)

Doch, Du kannst das beurteilen, glaube an Dich! Vieleicht nicht das mit der Spec, die gibt die ISO nur gegen Geld raus. Aber wenn Du den Versuch mit dem linken oberen Teil des "lorem ipsum" Symbol (s.o.), oder einem anderen machst, wirst Du anschließend wissen, daß es praktisch nicht funktioniert. Dann hast hast Du Gewißheit und diese Diskussion wäre zu Ende. Abgesehen davon, wie sollte eine einschränkende Information aussehen: "Man kann die Regionen einzeln auswerten, aber egal wie man es macht, es wird nicht funktionieren" ;-) --84.191.122.148 21:08, 7. Mai 2010 (CEST)

Für Wikipedia genügt keine Selbsterkenntnis (eigene Beurteilung) als Beleg für die Abänderung, sondern Aussagen (Infos) sollten meines bisherigen Wissens nach durch zugängliche, renommierte Quellen (Links sind gut geeignet) allgemein nachlesbar sein. Liebe Grüße aus Darmstadt! Rolf29 21:40, 7. Mai 2010 (CEST)