ubuntuusers.de

Es geht um die Exif-Daten in einer DICOM-Datei, die ich mit Exiftool auslese. Soweit kein Problem.

Im Bash-Script funktioniert das seit vielen Jahren so:

exiftool -G -H -a "$FILE" > "$PNGFILE94TXT"

Führe ich den Befehl manuell aus, dann sehe ich zB

[DICOM]              - Start Of Item                   : �..LO.ELSCINT1�.9.UL.=�.�.LO.carevue_GN�.�.CS.FAST_NET�.�.CS.SECURED_CON �.�.LO.192.168.39.10 �.�.LO.22104 �.�.AE.carevueFIR�.�.CS.N �.�.LO.1.0.0.0
[DICOM]              - Pixel Data                      : (Binary data 524288 bytes, use -b option to extract)

Das sind ziemlich uninteressante Daten, lassen aber Pluma die Datei nicht öffnen, vim, Geany, etc können die Datei anzeigen. Es geht nun darum, dass die txt-Datei problemlos geöffent werden kann, auch unter Android, IOS, etc.

Wie kann ich die problematischen Zeichen am besten entfernen bzw. durch ein problemloses Zeichen ersetzen?, am besten vor der Umleitung über eine Pipe?

Schau dir in der manpage mal die Optionen --TAG bzsw. -x und -charset an. Vielleicht kommst du damit weiter.

Das folgende Skript stammt von ChatGPT 3.5.

Wenn dich oder jemand anderen die genaue Herleitung interessiert dann poste ich die ... ist wohl etwas länger.

Die Ursprungsfrage an ChatGPT war:

Schreibe mir bitte ein Bash-Skript, dass in allen Text-Dateien eines Verzeichnisses alle Sonderzeichen in diesen Text-Dateien löscht. Sonderzeichen sind all jene, die nicht im Ascii-Bereich zwischen 32 bis 126 dezimal liegen.

Das Skript funktionierte jedoch nicht, da es nicht bei UTF8 Unicode Text-Dateien funktioniert.

Es folgte folgendes Skript, getestet ... funktioniert:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

#!/bin/bash

verzeichnis="pfad/zum/verzeichnis"

for datei in "$verzeichnis"/*.txt; do
    if [ -f "$datei" ] && [ -r "$datei" ]; then
        # Nicht-ASCII-Zeichen entfernen und in eine temporäre Datei schreiben
        iconv -c -f UTF-8 -t ASCII//TRANSLIT "$datei" | tr -cd '\11\12\15\40-\176' > "$datei.tmp"
        # Die temporäre Datei zurück in die ursprüngliche Datei verschieben
        mv "$datei.tmp" "$datei"
        echo "Sonderzeichen aus $datei entfernt."
    else
        echo "Fehler: Kann $datei nicht lesen oder Datei existiert nicht."
    fi
done

echo "Alle Sonderzeichen in Textdateien im Verzeichnis $verzeichnis wurden entfernt."

In der Pipe sollte es wie folgt aussehen:

iconv -c -f UTF-8 -t ASCII//TRANSLIT | tr -cd '\11\12\15\40-\176'

Was bedeutet: iconv -c -f UTF-8 -t ASCII//TRANSLIT "$datei" | tr -cd '\11\12\15\40-\176'?
Antwort von ChatGPT:

Die Kommandozeile `iconv -c -f UTF-8 -t ASCII//TRANSLIT "$datei" | tr -cd '\11\12\15\40-\176'` hat zwei Teile:
1. `iconv -c -f UTF-8 -t ASCII//TRANSLIT "$datei"`:
   - `iconv`: ist ein Befehl zum Zeichenkodierungswandel.
   - `-c`: bedeutet "ignore" und weist `iconv` an, unkonvertierbare Zeichen zu ignorieren.
   - `-f UTF-8`: gibt die Eingabezeichencodierung an, in diesem Fall UTF-8.
   - `-t ASCII//TRANSLIT`: gibt die Zielausgabezeichencodierung an, in diesem Fall ASCII mit dem `TRANSLIT`-Modus, der versucht, Zeichen zu übersetzen, die nicht direkt in ASCII übertragen werden können. 

2. `tr -cd '\11\12\15\40-\176'`:
   - `tr`: steht für "translate" und ist ein Befehl, der Zeichen ersetzt oder löscht.
   - `-cd`: bedeutet "complement" und "delete", was darauf hinweist, dass alle Zeichen außer den angegebenen gelöscht werden sollen.
   - `'\11\12\15\40-\176'`: ist eine Zeichenklasse, die spezifiziert, welche Zeichen beibehalten werden sollen. Hier werden alle druckbaren ASCII-Zeichen im Bereich von 32 bis 126 beibehalten (dezimal angegeben), sowie Zeilenumbrüche, Tabulatoren und Wagenrückläufe (dezimal 9, 10, 13). Alle anderen Zeichen werden gelöscht.

Edit: Typo

Sonderzeichen sind all jene, die nicht im Ascii-Bereich zwischen 32 bis 126 dezimal liegen.

Ich denke man kann das nicht so annehmen. Keine Ahnung wie schlau die Software des CT ist, aber einen türkischen oder kroatischen Namen kann ich mir schon in den Metadaten vorstellen. Ich schreibe in meine Exifdaten eigener Fotos verschiedene UTF-8 Zeichen problemlos.

Ich habe jetzt keine Ahnung was

�

ist und ob das vielleicht unterschiedliche Zeichen sind. Ich stell mir sowas wie Linefeed und andere nicht druckbare Zeichen vor.

Schau dir in der manpage mal die Optionen --TAG bzsw. -x und -charset an.

Verwende -charset in einem anderen Script (

-charset UTF8

). Mein Gefühl sagt mir, das sind nicht druckbare Zeichen. Vielleicht kann man da mit sed experimentieren und alles zB bis ASCII 63 durch "_" ersetzen?

Das Problem von Pluma ist ja, dass es eine Binärdatei und keine Textdatei vermutet und sich weigert diese Datei zu öffnen.

Benutze bitte besser erst einmal iconv -c -f UTF-8 -t ASCII//TRANSLIT ohne den trBefehl. Der macht aus meiner Sicht keinen Sinn.
Teste es bitte auch nochmals selber.

var="Start Of Item                   : �..LO.ELSCINT1�.9.UL.=�.�.LO.carevue_GN�.�.CS.FAST_NET�.�.CS.SECURED_CON �.�.LO.192.168.39.10"

echo "$var" | iconv -c -f UTF-8 -t ASCII//TRANSLIT
Start Of Item                   : ?..LO.ELSCINT1?.9.UL.=?.?.LO.carevue_GN?.?.CS.FAST_NET?.?.CS.SECURED_CON ?.?.LO.192.168.39.10

Sieht ja gar nicht so schlecht aus. Habe damit schon in einem anderen Script mit uralten Digicams rumgetrickst, nur nicht mehr daran gedacht.

Ich denke man kann das so lassen, außer es hat noch wer eine andere Idee.

iconv -c -f UTF-8

Die Frage ist, ob UTF-8 die richtige Ausgangsbasis ist.

Ich habe mit die Daten von einer anderen Maschine des gleichen Radiologen angesehen, da sind die hier undefinierten Zeichen, Pfund und vor allem großes A in verschiedensten Varianten.

Kann man den Ausgangszeichensatz erraten lassen? Ich denke "-c" ist der entscheidende Punkt. Würde mich nicht wundern, wenn die Maschine doch nur ASCII kann. Die Felder sind auf Englisch bezeichnet und für Inhalt mit offensichtlich nicht US-ASCII habe ich keine Beispiele.

Edit: Habe das was BEI 6.1 gefunden: https://cdn0.scrvt.com/39b415fb07de4d9656c7b516d8e2d907/1800000004339938/c9b987129f73/dcs_syngo_via_vb20a-04339938_1800000004339938.pdf

ISO_IR 100, ISO_IR 101, SO_IR 109 und ISO_IR 110 stehen am ehesten zur Auswahl.

https://gist.github.com/erriapo/befa7c67df84b4416597b0fca84d0e48 listet:

CP819 IBM819 ISO-8859-1 ISO-IR-100 ISO8859-1 ISO_8859-1 ISO_8859-1:1987 L1 LATIN1 CSISOLATIN1

Ich probiere jetzt mal die Files bis Bilder kommen, wo es nicht passt.

exiftool -G -H -a "$FILE" | iconv -c -fISO-IR-100 -t ASCII//TRANSLIT > "$PNGFILE94TXT"

glaskugel schrieb:

Kann man den Ausgangszeichensatz erraten lassen?

Die Frage ist, ob man da überhaupt groß raten muss - in welchem Land stand die Maschine, die die Datei ursprünglich erstellt hat? Kannst du eventuell mal diese Zeile in eine Datei umleiten und anhängen (die sollte keine schützenswerten Daten enthalten) statt die aus der Shell zu kopieren?

glaskugel schrieb:

[DICOM]              - Start Of Item                   : �..LO.ELSCINT1�.9.UL.=�.�.LO.carevue_GN�.�.CS.FAST_NET�.�.CS.SECURED_CON �.�.LO.192.168.39.10 �.�.LO.22104 �.�.AE.carevueFIR�.�.CS.N �.�.LO.1.0.0.0

Das Problem ist wohl immer die Software und der Hersteller. Das Skript ist uralt und ich bastle da alle paar Jahre rum. Seit einiger Zeit haben die Dateien keine Endung, früher dcm. Man muss also immer mit Überraschungen rechnen.

In diesem Fall habe ich mich über die Metadaten

[DICOM]              - Software Version                : syngo CT VB20A

genähert. Das kann natürlich bei einer anderen Untersuchung anders zu sein. Es dürfte da für DICOM spezielle Zeichensätze geben. Siehe Posting davor. Da ist ein Link zur Software-Beschreibung.

Kannst du eventuell mal diese Zeile in eine Datei umleiten

Die Frage ist was es bringt, ich habe 2 Dateien, die total ähnlich sind, wie schon oben geschrieben, steht bei der anderen ein Pfund-Zeichen, etc. Aber wenn du meinst, macht Sinn, dann liefere ich das.

in welchem Land stand die Maschine

Kommt darauf an, Deutschland und Österreich.

Aber so wie es zur Zeit ist, passt es schon. Ich bekomme zeitweise für die speziellen Zeichen ein ? und dann einen . (Punkt). Ist egal, geht ja nur darum, dass der Rest der Text-Datei bei Bedarf mit allen Endgeräten lesbar ist. Mir geht es darum, dass das Script keine Probleme macht, wenn die DICOM-Dateien von einem anderen Hersteller sind.

Hintergedanke, der Arzt interessiert sich auf die schnelle für alte Aufnahmen und man schickt die dann schnell vom Handy als png und Txt-Datei. Warum jetzt die DICOM-Meta-Daten nicht nach png umkopiert wurden, muss ich auch erst recherchieren. Mit Bildern vor 2 Monaten mit einer anderen Maschine hat es gepasst. Aber dafür gibt es eben die Text-Datei und die Meta-Daten in png stehen da nur automatisch drinnen, wenn man medconv verwendet.

Übrigens neuerdings gibt es auch neben dicom noch jpg-Files, ob das viel Sinn macht? Keine Ahnung wie stark jpg komprimiert wurde. Kann man das mit Imagemagick abfragen? Jedenfalss ist jpg 8bit SRGB und das konvertierte dicom zu png 16bit Greyscale. Das DCIM-File hat 12-bit Bilevel Gray

Das könnte ein verkuhwedelter 8-Bit Zeichensatz (wenn es aus DE oder AT kommt, vermutlich Latin-1 bzw. Windows-1252) sein, das mal sorglos nach UTF-8 konvertiert wurde. Das Problem ist, dass man in dem geposteten Abschnitt nur ein allgemeines Platzhalterzeichen sieht (� - Specials_(Unicode_block)) - daraus kann man keine Rückschlüsse auf das ursprüngliche Zeichen ziehen.

DICOM unterstützt verschiedenste Zeichensätze, man sollte das heutzutage halt in den Metadaten der Dateien korrekt kennzeichnen.

Wenn ich meine beiden Dateien vergleichen, dann ist das � bei sonst gleichem Text bei der anderen Datei mit verschiedenen Zeichen dargestellt.

man sollte das heutzutage halt in den Metadaten der Dateien korrekt kennzeichnen.

heutzutage ist gut, ich spendiere meinen Fotos schon lange "ESC % G" mit exiftool. Wenn das fehlt, dann passt zB die Rotation nicht.

Aber letztlich ist es egal, die IP-Adresse kann man im Text auch so erraten und ist völlig nebensächlich. Mir ist es nur aufgefallen, weil es Pluma nicht öffnen konnte, mein Handy-Editor kann die Datei mit den speziellen Zeichen als Txt darstellen.

seahawk1986 schrieb:

glaskugel schrieb:

Kann man den Ausgangszeichensatz erraten lassen?

Ja, siehe: uchardet

uchardet mytextfilename

Die Frage ist, ob man da überhaupt groß raten muss - in welchem Land stand die Maschine, die die Datei ursprünglich erstellt hat? Kannst du eventuell mal diese Zeile in eine Datei umleiten und anhängen (die sollte keine schützenswerten Daten enthalten) statt die aus der Shell zu kopieren?

Das wäre hilfreich.

Ich verstehe da was noch nicht.

exiftool -G -H -a I1000000 > test-charset.txt

Pluma kann die Datei nicht öffnen.

exiftool -G -H -a I1000000 | grep "Start Of Item" > test-charset.txt
grep: (Standardeingabe): Übereinstimmungen in Binärdatei

Pluma kann das Ergebnis öffnen.

[DICOM]              - Start Of Item                   : ..SH.c404abd ...SH.L599061 ...LO.c404abd
[DICOM]              - Start Of Item                   : ..SH.MM Oncology OB...SH.99CT_VIA...LO.MM Onco + CT Bone
[DICOM]              - Start Of Item                   : .P.UI.1.2.840.10008.3.1.2.3.3.U.UI81.3.12.2.1107.5.1.4.83603.30000024030406410807600000010
[DICOM]              - Start Of Item                   : ..SH.113691...SH.DCM ...LO.IEC Body Dosimetry Phantom
[DICOM]              - Start Of Item                   : ..SH.c404abd ...SH.L599061 ...LO.c404abd
[DICOM]              - Start Of Item                   : @.LO.c404abd @.SH.c404abd @..SH.202403040761
[DICOM]              - Start Of Item                   : (Binary data 4210 bytes, use -b option to extract)

Wenn ich nun die Datei, die von Pluma nicht geöffnet werden kann, mit Geany ansehe, dann sehe ich:

[DICOM]              - Start Of Item                   : (Binary data 4210 bytes, use -b option to extract)
[DICOM]              - Start Of Item                   : £..LO.ELSCINT1£.9.UL.=£.Á.LO.carevue_GN£.Â.CS.FAST_NET£.Ã.CS.SECURED_CON £.Ä.LO.192.168.39.10 £.Å.LO.22104 £.È.AE.carevueFIR£.É.CS.N £.Ì.LO.1.0.0.0
[DICOM]              - Start Of Item                   : £..LO.ELSCINT1£.9.UL.=£.Á.LO.carevue_GN£.Â.CS.FAST_NET£.Ã.CS.SECURED_CON £.Ä.LO.192.168.39.10 £.Å.LO.22104 £.È.AE.carevueFIR£.É.CS.N £.Ì.LO.1.0.0.0
[DICOM]              - Start Of Item                   : £..LO.ELSCINT1£.9.UL.=£.Á.LO.carevue_GN£.Â.CS.FAST_NET£.Ã.CS.SECURED_CON £.Ä.LO.192.168.39.10 £.Å.LO.22104 £.È.AE.carevueFIR£.É.CS.N £.Ì.LO.1.0.0.0

Im Terminal unter XFCE sieht es so aus:

[DICOM]              - Start Of Item                   : (Binary data 4210 bytes, use -b option to extract)
[DICOM]              - Start Of Item                   : �..LO.ELSCINT1�.9.UL.=�.�.LO.carevue_GN�.�.CS.FAST_NET�.�.CS.SECURED_CON �.�.LO.192.168.39.10 �.�.LO.22104 �.�.AE.carevueFIR�.�.CS.N �.�.LO.1.0.0.0
[DICOM]              - Start Of Item                   : �..LO.ELSCINT1�.9.UL.=�.�.LO.carevue_GN�.�.CS.FAST_NET�.�.CS.SECURED_CON �.�.LO.192.168.39.10 �.�.LO.22104 �.�.AE.carevueFIR�.�.CS.N �.�.LO.1.0.0.0
[DICOM]              - Start Of Item                   : �..LO.ELSCINT1�.9.UL.=�.�.LO.carevue_GN�.�.CS.FAST_NET�.�.CS.SECURED_CON �.�.LO.192.168.39.10 �.�.LO.22104 �.�.AE.carevueFIR�.�.CS.N �.�.LO.1.0.0.0
[DICOM]              - Pixel Data                      : (Binary data 524288 bytes, use -b option to extract)

Jetzt müsst ihr mir nur mehr sagen wie ich das File erstellen soll. In Geany die Datei öffnen und den privaten Teil entfernen?

glaskugel schrieb:

Ich verstehe da was noch nicht.

exiftool -G -H -a I1000000 > test-charset.txt

Pluma kann die Datei nicht öffnen.

exiftool -G -H -a I1000000 | grep "Start Of Item" > test-charset.txt
grep: (Standardeingabe): Übereinstimmungen in Binärdatei

1. wie schon beschrieben hänge bitte mal Beispieldateien an.

2. Nutze uchardet oder file um die Dateien zu analysieren

3. du wirst sehen, das exiftool dir wenn notwendig UTF8 auswirft

4. grep "wandelt" den utf8 input von exiftool um in ASCII Text

Du kannst das reproduzieren, in dem du eine beliebige Bilddatei ohne Informationen nimmst und wie du beschrieben hast bearbeitest. Resultat ... Pluma kann es öffnen, da es Standard ASCII Text ist. Bearbeite nun mit dem Programm deines Vertrauens den Titel der Bilddatei und Kopiere dort z.B. kyrillische Zeichen hinein. Bearbeite es wie du beschrieben hast und Pluma kann es nicht Öffnen, da exiftool UTF8. nun liefert.

Das ist natürlich alles nur Mutmaßung, da ich kein Pluma habe 😢

Pluma kann ja doch UTF-8 😱.

It fully supports international text through its use of the Unicode UTF-8 encoding.

Quelle: Pluma_(text_editor)

Lange Rede kurze Sinn. Man benötigt dazu Dateien oder mindestens die Rückgabe von z.B. uchardet sowohl für die Datei, welche funktioniert und für jene, welche nicht funktioniert.