GDPicture: Unterschied zwischen den Versionen
Silvan (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Silvan (Diskussion | Beiträge) |
||
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Im Helper nutzen wir GDPicture (https://www.gdpicture.com) um Bilder und PDFs anzeigen zu lassen, diese direkt vom Benutzer editieren zu lassen oder Bearbeitungen via Serverjobs vorzunehmen. | Im Helper nutzen wir GDPicture (https://www.gdpicture.com) um Bilder und PDFs anzeigen zu lassen, diese direkt vom Benutzer editieren zu lassen oder Bearbeitungen via Serverjobs vorzunehmen. | ||
= Problemstellung = | |||
Ein Vorteil von GDPicture ist, dass es Problemlos über 100 verschiedene Dateitypen lesen und bearbeiten kann. Ebenfalls unterstützt wird die Konvertierung von Dateityp zu Dateityp. Der Nachteil daran ist, dass dadurch einige Bildinformationen und Details verloren gehen können. Um zu verstehen wieso das passiert müssen wir uns vor Auge führen wie es GDPicture überhaupt schafft so viele Dateitypen zu unterstützen. Sie haben unmöglich für jedes einzelne Format zum Beispiel eine Funktion geschrieben um einen Kreis in ein Bild zu zeichnen. GDPicture öffnet eine Datei und konvertiert diese im Arbeitsspeicher in ein eigenes Format. Basierend auf diesem Hausinternen Format werden dann alle Bildmanipulationen durchgeführt. Zum Schluss wird dieses interne Format wieder in eine "lesbare" Datei (zB. jpg oder png) konvertiert und auf dem Dateisystem abgespeichert. Die Quintessenz davon soll sein, dass GDPicture beim speichern IMMER eine NEUE Datei erstellt. Sowas wie "Öffne dieses File, zeichne einen Kreis und lass allen Rest gleich" gibt es nicht, da die Datei zuerst in das GDPicture interne Format konvertiert und danach exportiert wird. | Ein Vorteil von GDPicture ist, dass es Problemlos über 100 verschiedene Dateitypen lesen und bearbeiten kann. Ebenfalls unterstützt wird die Konvertierung von Dateityp zu Dateityp. Der Nachteil daran ist, dass dadurch einige Bildinformationen und Details verloren gehen können. Um zu verstehen wieso das passiert müssen wir uns vor Auge führen wie es GDPicture überhaupt schafft so viele Dateitypen zu unterstützen. Sie haben unmöglich für jedes einzelne Format zum Beispiel eine Funktion geschrieben um einen Kreis in ein Bild zu zeichnen. GDPicture öffnet eine Datei und konvertiert diese im Arbeitsspeicher in ein eigenes Format. Basierend auf diesem Hausinternen Format werden dann alle Bildmanipulationen durchgeführt. Zum Schluss wird dieses interne Format wieder in eine "lesbare" Datei (zB. jpg oder png) konvertiert und auf dem Dateisystem abgespeichert. Die Quintessenz davon soll sein, dass GDPicture beim speichern IMMER eine NEUE Datei erstellt. Sowas wie "Öffne dieses File, zeichne einen Kreis und lass allen Rest gleich" gibt es nicht, da die Datei zuerst in das GDPicture interne Format konvertiert und danach exportiert wird. | ||
=== Was heisst das für die Profile === | === Was heisst das für die Profile === | ||
Die Profile muss für jedes einzelne Dateiformat und Feature testen, wie sich GDPicture verhält und gegebenenfalls Attribute, Einstellungen und Metadaten beim öffnen Zwischenspeichern und am Ende wieder Einfügen, um | Die Profile muss für jedes einzelne Dateiformat und Feature testen, wie sich GDPicture verhält und gegebenenfalls Attribute, Einstellungen und Metadaten beim öffnen Zwischenspeichern und am Ende wieder Einfügen, um Informationsverlust vorzubeugen. Zum Beispiel: Gegeben ist ein spezifischer Farbraum in einem TIFF. Es gibt bestimmte Fälle, bei welchen diese Information verlogen kann (zB. ein Bild einfügen). Wir müssen also bei TIFFs Code schreiben, welcher sicherstellt, das dies nicht geschieht. Eine ausführliche Liste mit schon unterstützen Features finden Sie weiter unten. | ||
=== Was heisst das für das BSB === | === Was heisst das für das BSB === | ||
Dem Mindset "Nur etwas ändern alle andere gleich lassen" muss abgesagt werden. Es muss ganz konkret die Ausgangslage definiert werden zB. ein JPG, Farbraum: RGB, Farbtiefe: 24 Bpp, XMP Metadatum Kameratyp. Das gleiche Spiel beim Ergebnis zB ein TIFF, Farbraum: RGB, Farbtiefe: 24 Bpp, TIFF-Compression: 60 %. Alles was nicht definiert ist, wird dem handling von GDPicture überlassen und es kann je nach Editierungen und Konvertierungen zu leichten Abänderungen der Bildinformationen kommen. | Dem Mindset "Nur etwas ändern alle andere gleich lassen" muss abgesagt werden. Es muss ganz konkret die Ausgangslage definiert werden zB. ein JPG, Farbraum: RGB, Farbtiefe: 24 Bpp, XMP Metadatum Kameratyp. Das gleiche Spiel beim Ergebnis zB ein TIFF, Farbraum: RGB, Farbtiefe: 24 Bpp, TIFF-Compression: 60 %. Alles was nicht definiert ist, wird dem handling von GDPicture überlassen und es kann je nach Editierungen und Konvertierungen zu leichten Abänderungen der Bildinformationen kommen. | ||
= Features = | |||
Dies ist eine Liste von Features, welche bereits Unterstützt werden beziehungsweise in Arbeit sind. | Dies ist eine Liste von Features, welche bereits Unterstützt werden beziehungsweise in Arbeit sind. | ||
=== ICC Profil (JPG, TIFF) === | === ICC Profil (JPG, TIFF) === | ||
Falls gewünscht wird das ICC Profil exportiert und vor dem Speichern wieder eingefügt. | Falls gewünscht wird das ICC Profil exportiert und vor dem Speichern wieder eingefügt.<br> | ||
Status: Aktiv | Status: Aktiv<br> | ||
Unittests: TODO | Unittests: TODO | ||
=== Bild Typ bleibt gleich (PNG, TIFF, JPG, PDF) === | === Bild Typ bleibt gleich (PNG, TIFF, JPG, PDF) === | ||
Falls eine Datei mit Typ X geöffnet wird, wird diese ebenfalls wieder als solche abgespeichert. | Falls eine Datei mit Typ X geöffnet wird, wird diese ebenfalls wieder als solche abgespeichert.<br> | ||
Status: Aktiv | Status: Aktiv<br> | ||
Unittests: Vorhanden | Unittests: Vorhanden | ||
=== Farbtiefe bleibt gleich (JPG, TIFF) === | === Farbtiefe bleibt gleich (JPG, TIFF) === | ||
Die Farbtiefe (zB. 24 Bit per Pixel) bleibt bestehen. | Die Farbtiefe (zB. 24 Bit per Pixel) bleibt bestehen.<br> | ||
Status: In Entwicklung | Status: In Entwicklung<br> | ||
Unittests: TODO | Unittests: TODO | ||
=== Farbraum bleibt bestehen (JPG, TIFF) === | === Farbraum bleibt bestehen (JPG, TIFF) === | ||
Falls das Bild mit einem Farbraum X geöffnet wird, soll dieses auch so wieder gespeichert werden. | Falls das Bild mit einem Farbraum X geöffnet wird, soll dieses auch so wieder gespeichert werden.<br> | ||
Gültige Farbräume: RGB, CMYK, Greyscale (Alle weiteren Räume werden generell nicht von GDPicture unterstützt) | Gültige Farbräume: RGB, CMYK, Greyscale (Alle weiteren Räume werden generell nicht von GDPicture unterstützt)<br> | ||
Status: In Entwicklung | Status: In Entwicklung<br> | ||
Unittests: TODO | Unittests: TODO | ||
=== XMP/IPTC Metadaten bleiben gleich (JPG, TIFF) === | === XMP/IPTC Metadaten bleiben gleich (JPG, TIFF) === | ||
Definierte Metadatentags bleiben bestehen. Ein Beispiel dafür wäre Kameratyp. Jegliche XMP Daten welche direkt mit dem Bild zusammenhängen (zB. Höhe, Pixeldichte, Änderungsdatum) können logischerweise nicht geschützt werden. Zudem wird sichergestellt, dass Bilder welche durch GDPicture editiert wurden, nach wie vor durch KostVAL validiert werden können. | Definierte Metadatentags bleiben bestehen. Ein Beispiel dafür wäre Kameratyp. Jegliche XMP Daten welche direkt mit dem Bild zusammenhängen (zB. Höhe, Pixeldichte, Änderungsdatum) können logischerweise nicht geschützt werden. Zudem wird sichergestellt, dass Bilder welche durch GDPicture editiert wurden, nach wie vor durch KostVAL validiert werden können.<br> | ||
Status: In Entwicklung | Status: In Entwicklung<br> | ||
Unittest: TODO | Unittest: TODO | ||
=== Orientation EXIF wird berücksichtigt (JPG, TIFF) === | === Orientation EXIF wird berücksichtigt (JPG, TIFF) === | ||
Einige Bilder enthalten ein Orientation EXIF Tag, welches beim Azeigen des Bildes berücksichtigt werden soll. Abzuklären bleibt, ob das Bild beim schliessen korrekt gedreht werden soll, oder einfach das Orientation EXIF Metadatum bestehen bleiben soll. | Einige Bilder enthalten ein Orientation EXIF Tag, welches beim Azeigen des Bildes berücksichtigt werden soll. Abzuklären bleibt, ob das Bild beim schliessen korrekt gedreht werden soll, oder einfach das Orientation EXIF Metadatum bestehen bleiben soll.<br> | ||
Status: In Entwicklung | Status: In Entwicklung<br> | ||
Unittest: TODO | |||
=== Kompression (TIFF) === | |||
Das TIFF soll mit der gleichen Kompression abgespeichert werden, wie es geöffnet wurde.<br> | |||
Status: Aktiv <br> | |||
Unittest: TODO | Unittest: TODO | ||
Aktuelle Version vom 2. Dezember 2021, 16:25 Uhr
Im Helper nutzen wir GDPicture (https://www.gdpicture.com) um Bilder und PDFs anzeigen zu lassen, diese direkt vom Benutzer editieren zu lassen oder Bearbeitungen via Serverjobs vorzunehmen.
Problemstellung
Ein Vorteil von GDPicture ist, dass es Problemlos über 100 verschiedene Dateitypen lesen und bearbeiten kann. Ebenfalls unterstützt wird die Konvertierung von Dateityp zu Dateityp. Der Nachteil daran ist, dass dadurch einige Bildinformationen und Details verloren gehen können. Um zu verstehen wieso das passiert müssen wir uns vor Auge führen wie es GDPicture überhaupt schafft so viele Dateitypen zu unterstützen. Sie haben unmöglich für jedes einzelne Format zum Beispiel eine Funktion geschrieben um einen Kreis in ein Bild zu zeichnen. GDPicture öffnet eine Datei und konvertiert diese im Arbeitsspeicher in ein eigenes Format. Basierend auf diesem Hausinternen Format werden dann alle Bildmanipulationen durchgeführt. Zum Schluss wird dieses interne Format wieder in eine "lesbare" Datei (zB. jpg oder png) konvertiert und auf dem Dateisystem abgespeichert. Die Quintessenz davon soll sein, dass GDPicture beim speichern IMMER eine NEUE Datei erstellt. Sowas wie "Öffne dieses File, zeichne einen Kreis und lass allen Rest gleich" gibt es nicht, da die Datei zuerst in das GDPicture interne Format konvertiert und danach exportiert wird.
Was heisst das für die Profile
Die Profile muss für jedes einzelne Dateiformat und Feature testen, wie sich GDPicture verhält und gegebenenfalls Attribute, Einstellungen und Metadaten beim öffnen Zwischenspeichern und am Ende wieder Einfügen, um Informationsverlust vorzubeugen. Zum Beispiel: Gegeben ist ein spezifischer Farbraum in einem TIFF. Es gibt bestimmte Fälle, bei welchen diese Information verlogen kann (zB. ein Bild einfügen). Wir müssen also bei TIFFs Code schreiben, welcher sicherstellt, das dies nicht geschieht. Eine ausführliche Liste mit schon unterstützen Features finden Sie weiter unten.
Was heisst das für das BSB
Dem Mindset "Nur etwas ändern alle andere gleich lassen" muss abgesagt werden. Es muss ganz konkret die Ausgangslage definiert werden zB. ein JPG, Farbraum: RGB, Farbtiefe: 24 Bpp, XMP Metadatum Kameratyp. Das gleiche Spiel beim Ergebnis zB ein TIFF, Farbraum: RGB, Farbtiefe: 24 Bpp, TIFF-Compression: 60 %. Alles was nicht definiert ist, wird dem handling von GDPicture überlassen und es kann je nach Editierungen und Konvertierungen zu leichten Abänderungen der Bildinformationen kommen.
Features
Dies ist eine Liste von Features, welche bereits Unterstützt werden beziehungsweise in Arbeit sind.
ICC Profil (JPG, TIFF)
Falls gewünscht wird das ICC Profil exportiert und vor dem Speichern wieder eingefügt.
Status: Aktiv
Unittests: TODO
Bild Typ bleibt gleich (PNG, TIFF, JPG, PDF)
Falls eine Datei mit Typ X geöffnet wird, wird diese ebenfalls wieder als solche abgespeichert.
Status: Aktiv
Unittests: Vorhanden
Farbtiefe bleibt gleich (JPG, TIFF)
Die Farbtiefe (zB. 24 Bit per Pixel) bleibt bestehen.
Status: In Entwicklung
Unittests: TODO
Farbraum bleibt bestehen (JPG, TIFF)
Falls das Bild mit einem Farbraum X geöffnet wird, soll dieses auch so wieder gespeichert werden.
Gültige Farbräume: RGB, CMYK, Greyscale (Alle weiteren Räume werden generell nicht von GDPicture unterstützt)
Status: In Entwicklung
Unittests: TODO
XMP/IPTC Metadaten bleiben gleich (JPG, TIFF)
Definierte Metadatentags bleiben bestehen. Ein Beispiel dafür wäre Kameratyp. Jegliche XMP Daten welche direkt mit dem Bild zusammenhängen (zB. Höhe, Pixeldichte, Änderungsdatum) können logischerweise nicht geschützt werden. Zudem wird sichergestellt, dass Bilder welche durch GDPicture editiert wurden, nach wie vor durch KostVAL validiert werden können.
Status: In Entwicklung
Unittest: TODO
Orientation EXIF wird berücksichtigt (JPG, TIFF)
Einige Bilder enthalten ein Orientation EXIF Tag, welches beim Azeigen des Bildes berücksichtigt werden soll. Abzuklären bleibt, ob das Bild beim schliessen korrekt gedreht werden soll, oder einfach das Orientation EXIF Metadatum bestehen bleiben soll.
Status: In Entwicklung
Unittest: TODO
Kompression (TIFF)
Das TIFF soll mit der gleichen Kompression abgespeichert werden, wie es geöffnet wurde.
Status: Aktiv
Unittest: TODO