Diskussion:DataMatrix-Code

Lesegeräte

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.

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)

1-D-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.-- 84.58.153.22 16:29, 11. Jun. 2007 (CEST)

Korrekturalgorithmus

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. -- 84.58.153.22 16:29, 11. Jun. 2007 (CEST)

Inverscode

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)

Varianten

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

2^(1558*8) = 2^12464 ~= 10^(3*1246.4) = 10^3739, also ungefähr Googol^37 —Chrysalis (Diskussion) 21:18, 28. Dez. 2018 (CET)

Lizenzgebühren

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.

Überarbeitung

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)

An der ersten Stelle im Code wird das Funktionszeichen 1 (FNC1) integriert.

Ich häng mich mit der Aussage einfach mal an und frage, was denn dieses ominöse FNC1 ist. --84.147.121.251 10:33, 18. Sep. 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)

Sorry, falls es falsch rübergekommen ist. Das ganze war auch nicht primär zur Selbsterkenntnis gedacht. Ich habe ein für jedermann nachvollziehbares Experiment beschrieben mit dem man die Aussage widerlegen kann. Das ist (auch wenn es in diesem Fall etwas hochtrabend klingt) Wissenschaft. Und der traue ich mehr wie Tante Google. Probier es aus und dann lebe mit dem Widerspruch. Bye. (nicht signierter Beitrag von 84.191.122.148 (Diskussion | Beiträge) 22:39, 7. Mai 2010 (CEST))

Artikeltext um Quelle und Texteil einer Gerätehersteller-Information ergänzt ("Jedes Teilfeld kann wie ein einzelner DataMatrix-Code ausgewertet werden, wodurch die gesamte Bildauswertung erleichtert wird"). Liebe Grüße aus Darmstadt! Rolf29 23:36, 7. Mai 2010 (CEST)

Dieser Abschnitt stand im Artikel:

Natürlich kann man die Regionen nicht einzeln auswerten. Die einzig gültige Instanz dazu ist die Norm, in der es dazu heißt "... This will result in some of the symbol characters being split between two adjacent data regions. ...". Da ein Verlinken auf das, kostenpflichtige, Angebot der ISO untersagt ist und der Weg in eine Bibliothek für die an der Diskussion beteiligten eine Zumutung zu sein scheint, hier noch ein paar weitere Hinweise. Versucht man eine einzelne Region eines Symbols mit mehreren Regionen mit Hilfe der unten genannten Decoder (Kaywa, Drhu) zu entschlüsseln, gibt es nur Fehlermeldungen. Glaubt man der oben erwähnten Werbebroschüre, dann besteht ein 104x104 Symbol aus 16 Regionen (s Seite 2). Laut der Tabelle auf Seite 5 kann ein 104x104 Symbol maximal 1222 Zeichen darstellen, ein 26x26 Symbol maximal 64. Wenn man für einen Augenblick annimmt, daß 16 * 64 = 1024, dann stellt sich die Frage, wo die fehlenden 198 Zeichen kodiert werden. Auf der Rückseite?

In der Formulierung kann er dort nicht stehen. Ich habe ihn daher hierher verschoben.--Juliabackhausen 09:16, 23. Mai 2010 (CEST)

Wieso darf eine eine korrekte Aussage, die Deinem ästhetischen Empfinden widerspricht nicht im Artikel stehen, schön formulierter Unsinn, der nachweislich mit in sich widersprüchlichen Werbeprospekten belegt wurde, aber schon? Wenn Dir die Formulierung nicht paßt: ändere sie. Oder besser: beende Deine Prinzipienreiterei und fange an zu argumentieren (meine kennst Du: es funktioniert weder lt Spec noch in der Praxis). Habe ich die Spec aufgrund meiner schlechten Englischkenntnisse falsch verstanden, oder bin damit einfach inhaltlich überfordert? Sind zusätzlich die Decoder von Kaywa und Drhu fehlerhaft? Und gibt es atmosphärische Bedingungen unter denen 16 * 64 = 1222 gilt? Allein die Tatsache, daß etwas weit oben in der Google-Trefferliste steht, hat nichts zu bedeuten (erinnere Dich an die Sache mit dem Rheinlänge: einmal falsch gemessen/aufgeschrieben, dann schreibt einer vom anderen ab ...). Ich nehm den Blödsinn mal wieder raus, bis ich Argumente höre.--84.191.66.214 23:20, 23. Mai 2010 (CEST)

Beispiel Data Matrix Code

Hallo Zusammen,

macht es nicht Sinn einen deutschen Text als Beispiel DMC zu codieren. Mich interessiert ziemlich wenig, was Carlos in seinem Block über Reisen, Fotografieren, Basketball, etc. schreibt. (nicht signierter Beitrag von 80.254.148.83 (Diskussion) 11:41, 11. Jan. 2012 (CET))

Habe das Bild durch das des englischen Artikels ersetzt. Inhalt: "Wikipedia, the free encyclopedia". Zwar nicht deutsch, aber besser als Werbung für ein Blog. --46.5.45.18 20:52, 25. Aug. 2012 (CEST)

Standards

Es gibt neben GS1 Datamatrix unter anderem die VDA Empfehlung 4902 Datamatrix, die im Automobilbereich häufig Anwendung findet - vielleicht lässt sich das auch noch sinnvoll integrieren. (nicht signierter Beitrag von 37.209.18.240 (Diskussion) 19:02, 29. Jun. 2015 (CEST))

Deplaziert

Gehört der Satz aus dem Abschnitt Druckqualität: "Ähnliche Codes sind der QR-Code nach ISO/IEC 18004, der MaxiCode nach ISO/IEC 16023, der Aztec-Code, der Mesa Code und andere, teilweise proprietäre Codes." nicht z.B. in die Einleitung. (nicht signierter Beitrag von 193.47.161.114 (Diskussion) 10:10, 19. Jan. 2017 (CET))

Hauptkomponenten

Der Abschnitt "Aufbau des Codebildes" bedarf einer Überarbeitung. Die Aussage "besteht aus vier oder fünf Hauptkomponenten" gehört so schwammig nicht in die Wikipedia. Anstrich 1 vereinnahmt mit "und unterbrochener" und "für die Aufrichtung" gleich Anstrich 4 für sich. Anstrich 3 ergibt sich automatisch aus Anstrich 4 und ist damit schon mal gar keine eigenständige Komponente. Ob das Alignment Pattern zum Finder Pattern gehört kann ich nicht beurteilen, daraus resultiert jedoch, ob von zwei oder drei Hauptkomponenten gesprochen werden muss. (nicht signierter Beitrag von 79.211.170.190 (Diskussion) 14:22, 21. Jul. 2020 (CEST))

Lemma

Das aktuelle Lemma "DataMatrix-Code" mit Binnenmajuskel widerspricht Wikipedia:Namenskonventionen#Abweichungen_von_den_Rechtschreibregeln. Auch die Deutsche Post verwendet hier in der Beschriftung eines Beispiels die Schreibweise „Datamatrixcode“. Verschieben, Artikel anpassen und auf abweichende Schreibweise hinweisen? --130.180.18.14 18:41, 24. Mai 2022 (CEST)