TIFFs unter Sierra – Anfrage ans Zollsoft-Team

Question

Liebes Zollsoft-Team,

schwarz angezeigte TIFF-Scans unter Sierra waren schon mehrfach Gegenstand des Forums, siehe hier: .TIF anzeigen auf Mac? und auch hier: Update von Yosemite auf Sierra Gibt es was zu beachten?

Wir haben auch Ärger mit einigen Alt-TIFFs.

Nun habe ich Folgendes beobachtet: Es betrifft bei uns grundsätzlich TIFFs mit 256 Graustufen. Es reicht, den Farbraum des jeweilige Bildes mit GraphicConverter auf 16 Bit Graustufen zu ändern, um diese TIFF dauerhaft auch für macOS normal anzeigbar zu machen. Man muß also auch nicht den von Herrn Koll. Hainich vorgeschlagenen Umweg über eine PDF nehmen. GraphicConverter kann diese Veränderung auch im Batch-Betrieb für alle in einem bestimmten Verzeichnis oder in einer bestimmten Auswahl befindlichen TIFFs auf einmal ausführen.

Und hier nun meine Frage an Sie: Man könnte nun auf die Idee kommen, auf den Server zu gehen und in den Unterverzeichnissen des files-Verzeichnisses alle betroffenen TIFFS im Batch-Betrieb umzuwandeln. Dann wäre das Problem ein für alle Mal gelöst. Aber geht das, ohne an der tomedo-Datenbank was kaputt zu machen oder sie durcheinander zu bringen? Wenn ein Eingriff durch uns Nutzer zu gefährlich ist, ginge das vielleicht von zollsoft-Seite?

Klar ist: Die genannten TIFFs haben dann nicht mehr den Orginalzustand. Aber wenn das Original nur umständlich anzeigbar ist, ist es eh witzlos. Die Anzeige mit XNView halte ich wegen der grottig schlechten Benutzeroberfläche gerade bei mehrseitigen Scans für keine sinnvolle Alternative.

Vielen Dank im Voraus,

Mike Prater

Answer 1

Hallo Herr Prater,

bei tomedo werden die Dateien nicht in der Datenbank gespeichert (wie in fast allen Programmen).

In der Datenbank wird ein Link zu der Datei angelegt.

Die Dateien selber finden Sie im Verzeichnis tomedo_Server, Files.

Hier werden Ordner für die Jahre angelegt, also 2017, 2016, 2015. In den Ordnern finden Sie Ordner für die Monate, 1, 2, 3 bis 12 und darin die Dateien.

Wenn Sie also etwas probieren wollen, dann würde ich dringend dazu raten, zunächst eine Sicherung zu machen, dann haben Sie eine aktuelle Kopie der Datenbank und des Files Ordner. Als alter EDVler würde ich dann nochmal den Ordner Files im Verzeichnis tomedo_Server kopieren und dann mal mit den Dateien probieren.

Nun ist die Frage, was Ihr Programm so kann. Im schlimmsten Fall müssten Sie in jedem Unterordner einmal die Batch starten.

Schon nach dem ersten Durchgang wissen, ob es klappt oder nicht.

Besten Gruß aus Hamburg,

herzlich Axel Tubbesing

Comments

Ganz lieben und freundlichen Dank. Den Ordner "files" hatte ich schon gefunden. Ob GraphicConverter rekursiv sucht, weiß ich noch nicht.

Allerdings hatte ich von den Zollsoftlern selbst (als den Machern des Ganzen) wissen wollen, ob ich mit einer Veränderung der Datein ggf. irgendwelche Zeitstempeleinträge in der Datenbank durcheinanderbringe. Vermutlich aber nicht, denn ich habe schon beobachtet, daß tomedo etwa mit Veränderungen von DOCX-Dateien nicht durcheinander kommt, auch wenn zwischendurch tomedo abgeschmiert und die Verbindung damit abgerissen war.

Der Tip, vorher eine Kopie des Verzeichnisses anzulegen, ist natürlich Klasse, Sie haben völlig recht.

Viele Grüße nach Hamburg.

---

Ja, hier haben Sie recht Herr Prater. Jede Datei in tomedo hat einenn sogenannten Hash Wert in der Datenbank, damit tomedo weiss ob die Datei clientseitig geändert worden ist. Wenn Datei und Datenbank auseinander liegen, so wird die Datei ggf nochmal heruntergeladen und überprüft. Das kann zu Verzögerungen führen (bzw. wir hatten eine Version die dann 30min einen Platzhalter angezeigt hat).

---

Vielen netten Dank für die rasche Reaktion. Eben wegen der von Ihnen angesprochenen Umstände (bzw. weil ich damit rechnete) habe ich es vermieden, solche Manipulationen auf dem Server durchzuführen. Der normale Anwendungsfall erzeugt ja das Szenario: Hash in der Datenbank und Dateidatum stimmen erst mal überein, Datei wird auf dem Client verändert und an den Server geschickt. Das Szenario "Datei wird direkt auf dem Server verändert" ist ja davon verschieden.

Eine Lösung gibt es in jedem Falle: Wenn eine schwarze TIFF auftaucht, wird sie mit GraphicConverter geöffnet, noch mal mit anderem Farbraum abgespeichert und funktioniert dann für immer. Und damit kommt tomedo ja auf jeden Fall zurecht.

Wenn sich (ohne Eile) eine sichere Ein-für-allemal-Lösung finden ließe, wären aber sicher etliche Kollegen mit Alt-TIFFs dankbar. 

---

Eine Möglichkeit die wir überlegen (und die ich favorisieren würde) wäre es eine client-seitige "TIIF-beim-Anzeigen-automatisch-Umwandeln"-Option einzubauen, welche (wenn aktiviert) die von Ihnen beschriebenen Schritte (oder alternativ die Umwandlung in PDFs) bei Aufrufen einer Patienten-Kartei (bzw. beim Aufruf der entsprechenden Bilder) automatisch vornimmt. Die Schwierigkeit hier besteht vor allem darin die Umwandlung möglichst verlustfrei hinzubekommen und das am besten noch mit den "Bordmitteln" von Apple (bzw. einer freien Bibliothek, die den Client nicht zu sehr aufbläht). Das ist uns bislang nicht so wirklich gelungen. Von daher ganz vielen Dank für den Hinweis mit dem Farbraum... das war mir noch nicht bekannt und gibt mir die Möglichkeit, noch mal in eine andere Richtung zu suchen, als bisher...

 

Bzgl. der Batch-Umwandlung: So wie von Ihnen überlegt gehen wir auch vor, wenn es darum geht Bilder bzw. Dokumente aus Datenkonvertierungen umzuwandeln (z.B. bei Dateien im ".CMP"-Format, oder bei der Umwandlung von alten, nicht mehr darstellbaren .doc-Dokumenten in .pdfs). Wie von Dr. Thierfelder beschrieben gibt es dabei aber einen "Fallstrick" der mit der lokalen (Offline-)Verfügbarkeit der Clients zusammenhängt. Wenn Sie den aber beachten, können Sie durchaus die "serverseitige Dateimanipulation" durchführen.

 

Konkret sollten Sie wie folgt vorgehen:

1. tomedo-Server stoppen

2. Backup machen (vor allem auch die zu ändernden Dateien noch mal separat sichern)

3. Änderungen an den Dateien durchführen

4. tomedo-Server starten

5. An ALLEN Clients die Basis-Daten neu laden BEVOR dort weitergearbeitet wird (unter Einstellungen -> Arbeitsplatz -> Lokale Datenbank löschen)

Den letzten Schritt kann man sich übrigens sparen bzw. abkürzen, indem ein tomedo-Update durchgeführt wird, dann werden die Basis-Daten automatisch neu geladen.

 

Noch zwei sehr wichtige Punkte wenn Sie Dateien serverseitig verändern:

* Die Dateinamen und -Pfade dürfen nicht verändert werden, sonst findet der Server die Dateien nicht mehr und

* die Zugriffsrechte auf die Dateien müssen gleich bleiben bzw. es muss weiterhin gewährleistet werden, dass der Server volle Schreib- und Leserechte auf die Dateien hat, sonst kann der Server sie unter Umständen nicht mehr ausliefern bzw. Änderungen vornehmen.

 

Wenn Sie wie beschrieben vorgehen und alle Punkte beachten, dann werden die Hash-Werte der geänderten Dateien bei Bedarf automatisch neu berechnet und die von Dr. Thierfelder erwähnten Platzhalter sollten höchstens ein paar Sekunden lang angezeigt werden, bevor die Clients die jeweils aktuelle Version der Dateien anzeigt. Das Ganze funktioniert allerdings NICHT im Multi-Server-Betrieb (der ist aktuell aber ohnehin noch in der Test-Phase), da hier die Dateisynchronisation deutlich länger dauert. Für Nutzer mit mehreren synchronisierten tomedo-Servern sollten Datei-Änderungen auf dem Server grundsätzlich immer nur durch uns durchgeführt bzw. mit uns abgestimmt werden. Auch sonst ist es natürlich ratsam das genauer Vorgehen noch mal mit uns abzustimmen und uns im Zweifelsfall noch mal drauf schauen zu lassen...

---

Lieber Herr Zollmann,

ganz freundlichen Dank nach Jena. Nach gegenwärtigem Stand würde ich erst mal die betreffenden TIFFs bei Bedarf umwandeln und warten, ob zollsoft eine komfortable Lösung findet. Wenn nicht, würde ich mich mit sehr vielen Vorsichtsmaßnahmen an die Manipulation auf dem Server trauen, vielleicht erst mal mit einer weniger wichtigen Datei anfangen.

Vielleicht noch ein kleiner Hinweis: Bei uns habe ich (siehe oben) beobachtet, daß es TIFFs mit 256 Graustufen betrifft und die wieder funktionieren, wenn man sie auf 16-Bit-Graustufe setzt. Weiß aber nicht, ob macOS prinzipiell Probleme mit diesem Farbraum hat oder vielleicht die Scanner-Software beim Abspeichern Parameter falsch gesetzt hat, so daß andere Nutzer vielleicht Probleme mit ganz anderen Farbräumen haben, je nach konkreter Macke der jeweiligen Scan-Software.