1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Alphakanal: Gimp verrät Geheimnisse…

Funktionsweise von "Löschen"

  1. Thema

Neues Thema Ansicht wechseln


  1. Funktionsweise von "Löschen"

    Autor: simon.budig 15.02.20 - 15:10

    Ich nochmal. Ich habe mein Image als sturer, besserwisserischer GIMP-Entwickler noch nicht genügend zementiert. :-)

    Hier in den Kommentaren sind einige Beschreibungen unterwegs die auf ein unvollständiges Verständnis von der Funktionsweise von GIMP hinweisen (durchaus auch von Leuten, die das aktuelle Verhalten verteidigen). Deswegen hier nochmal ein paar Bemerkungen:

    "Alphakanal". Im Kontext von GIMP meint das tatsächlich einen integralen Bestandteil der Pixeldaten einer Ebene. Der Unterschied zwischen einer Ebene mit und einer Ebene ohne Alphakanal ist, dass die Pixel einmal als "[(RGBA)(RGBA)....]" und einmal als "[(RGB)(RGB)...]" gespeichert werden.
    Ich kenne nun Photoshop bestenfalls schlecht, aber aus Beschreibungen habe ich entnommen, dass da zumindest in früheren Versionen der "Alphakanal" ein separates Etwas beschreibt, das separat manipuliert und bearbeitet werden kann/muss. In GIMP gibt es etwas vergleichbares, das läuft aber unter der Bezeichnung "Ebenenmaske" und kann im Ebenendialog zusätzlich an eine Ebene angehängt werden (Interne Speicherung: [(RGBA)(RGBA)...] + [(A)(A)...])

    Vor diesem Hintergrund ist die Erwartungshaltung, dass beim Löschen simultan mit dem Alphakanal auch die Farbdaten auf 0 gesetzt werden nachvollziehbar und verständlich.

    Weiter: quasi alle Operationen in GIMP werden auf die aktuelle Auswahl begrenzt. Wenn man ein Rechteck auswählt und anschließend das Pinselwerkzeug verwendet, wird es nur innerhalb der Auswahl malen. "Auswahl" ist aber nicht nur ein Bit pro Pixel, sondern ein Pixel kann "partiell" ausgewählt sein. Es gibt also pro Pixel einen weiteren Zahlenwert der mit einem Wert zwischen 0 und 100% beschreibt "wie stark" ein Pixel ausgewählt ist. Damit kann man zum Beispiel mit dem Rechteckwerkzeug in den Werkzeugoptionen "Kanten ausblenden" aktivieren und damit Rechtecke mit weichen Rändern erzeugen. Ein Problem an dieser Stelle ist, dass das in der Bildansicht aber nicht unbedingt sichtbar ist. Die "marschierenden Ameisen" die die Grenzen der aktuellen Auswahl anzeigen laufen in Wirklichkeit entlang der Grenze zwischen Pixeln die weniger als 50% ausgewählt sind und Pixeln die mehr als 50% ausgewählt sind, was natürlich die falsche Wahrnehmung "ein Pixel ist ausgewählt oder nicht" unterstützt.

    Eine andere Ansicht der Auswahl ist der Quickmask-Modus (Auswahl->Schnellmasken-Modus umschalten) in dem die Auswahl als rotes Overlay über dem Bild angezeigt wird. Damit kann man die weichen Grenzen einer Auswahl erkennen. In diesem Modus arbeiten die Malwerkzeuge/Plugins allerdings auf der Auswahl, so dass man z.B. mit dem Wischfinger selber gezielt Grenzen einer Auswahl verwischen kann.

    Das Rechteck-Auswahlwerkzeug resultiert zwar (ohne "ausblenden") effektiv in ausschließlich 100% oder 0% ausgewählten Pixeln, intern ist es aber letztlich genauso eine Maske die pro Pixel einen "analogen" Auswahlwert festlegt, nach einem Wechsel zu einem anderen Werkzeug ist die geometrische Information über das Rechteck auch erstmal verloren, es gibt nur noch ausgewählte und nicht ausgewählte Pixel.

    Wenn man nun die Auswahl (wieder im Modus mit den marschierenden Ameisen) mit z.B. rot füllt, dann bekommt man am Rand einen Bereich, in dem die Füllfarbe sanft in die existierenden Bilddaten übergeht. Rechnerisch steckt da im wesentlichen dahinter, dass zwischen dem Originalpixel und dem "gefüllten Pixel" mit dem Auswahlwert als Gewicht interpoliert wird.

    Ein 25% ausgewähltes blaues Pixel (0x0000ff) welches gerade mit rot (0xff0000) gefüllt wird hat also anschließend den Farbwert (0x4000bf), ein ins blaue tendierendes violett.

    Jetzt kommt der spannende Teil: Wir sind also in der Situation dass wir festlegen müssen, was bei einem partiell ausgewählten Pixel "Löschen" bedeutet. "Intuitiv" hätten wir gerne, dass bei einer weich auslaufenden Auswahl die Pixel sanft von "nicht gelöscht" zu "gelöscht" wechseln. Auf der Pixeldatenebene betrachtet bedeutet das, dass klarerweise der Alphakanal von 100% zu 0% wandern muss. Aber die Farbdaten?

    Wir arbeiten normalerweise intern mit Daten die nicht "pre-multiplied" sind. Das heißt wenn ein Pixel fließend zwischen "deckend" und "transparent" wandert, darf sich an den Farbwerten bei halbtransparenten Pixeln nichts ändern. Würden wir also für die partiell ausgewählten Pixel zwischen 0xffffffff (Weiß mit deckendem Alpha-Wert) und 0x00000000 (transparentes Schwarz) interpolieren und das Resultat anschließend über einen anderen Layer drübercompositen, dann würden wir in dem Übergangsbereich einen Grauschleier statt eines auslaufenden Weiß erhalten. Das sauber auslaufende Weiß erhalten wir nur, wenn wir zwischen 0xffffffff und 0xffffff00 interpolieren.

    Aber das hat genau das Resultat welches hier beklagt wird: Die Farbdaten bleiben sowohl in den halbtransparenten als auch in den volltransparenten Farben erhalten. Für volltransparente Pixel wären die Farbdaten technisch zwar egal (abgesehen von den Textur-Leuten), aber es wäre ein weiterer Durchgang (bzw. ein weiteres if()) über alle Pixel notwendig, der prüft, ob der Alpha-Wert genau 0 ist und erst dann die Farbdaten nullt. Wir müssten also deutlich Zusatzaufwand treiben und würden im Resultat Workflows von einigen Leuten zerstören.

    Das erstmal von meiner Seite zu dem technischen Hintergrund.

    Viele Grüße,
    Simon



    1 mal bearbeitet, zuletzt am 15.02.20 15:14 durch simon.budig.

  2. Re: Funktionsweise von "Löschen"

    Autor: mambokurt 17.02.20 - 18:56

    Jetzt hast du sehr viel geschrieben und ich nur die Hälfte gelesen aber was die User wollen ist dass du _beim Speichern_ das daufreundliche vorgibst. Das ist 'ich kanns nicht sehen - es ist weg'.
    Niemand hat ein Problem damit wenn du deine xfc (das hieß so bei gimp?) mit X Zusatzinfos und History ausstattest, nur ist Png _eigentlich_ ein Format zur Veröffentlichung und da brauchst du den ganzen Zinober doch gar nicht! Genau dafür gibts doch den Exportdialog!

    Ich bin ja sogar der Meinung dass das an sich kein Problem ist weil das keiner so macht aber es ist doch kein Problem bei Veröffentlichungsformaten zu sagen 'da dampfen wir standardmäßig zusammen und wer was anderes will setzt einmal den Haken und der wird erinnert'. Da bricht sich doch jetzt keiner einen ab und die Diskussion ist abgehakt, ich als Entwickler hätte das inzwischen schon aus lauter Sackgang so gemacht, allerdings mit der Rückinfo dass ich es für ein künstliches Szenario halte was quasi nie vorkommt -> End of Story, Ehre gerettet.

  3. Re: Funktionsweise von "Löschen"

    Autor: janoP 18.02.20 - 14:21

    Ein Kommentar auf GitLab beschreibt richtigerweise, dass ein Ändern der Default-Einstellungen beim Exportieren das Problem lösen würde.

    Dass GIMP intern nicht anders arbeiten kann, ist mir als langjähriger GIMP-Nutzer klar. Ich hätte auch nicht erwartet, dass gelöschte Teile im XCF-Format nicht mitgespeichert werden, zumal ja sogar mal zur Diskussion stand (steht?), in XCF-Bildern die Rückgängig-Historie mitzuspeichern.

    Spätestens beim Export wäre ich aber davon ausgegangen, dass „gelöschte“ Pixel weg sind. Dass es die Option gibt, ist ein kleiner Trost, denn Sicherheit ist immer auch ein Problem des User-Interfaces. Unischere und unintuitive Default-Einstellungen sind ein Sicherheitsproblem.

    Sicherheit ist dem Wortsinn nach das Schützen vor potentiellen Problemen, die konkret werden könnten. Sobald ein Problem konkret ist, ist es kein Sicherheitsproblem mehr. Dass das Problem nur potentiell ist, bedeutet aber, dass ein Nutzer das vermutlich so nicht auf dem Schirm hat, denn so funktionieren Menschen.

    Deswegen sind sichere Defaults wichtig: Wenn Nutzer durch die Default-Einstellung das Problem haben, dass ihre Textur-Daten nicht vollständig sind, ist das ein konkretes Problem. Das hat der Nutzer spätestens auf dem Schirm, sobald er die Texturdaten irgendwo verwendet. Er kann sich dann mit dem Problem beschäftigen und die Defaults ändern.

    Im Falle von fälschlich geteilten Informationen bemerkt der Nutzer das Problem erst, wenn es sich von einem potentiellen in ein konkretes Problem verwandelt hat. Dann ist es zu spät. The damage is done.

    Das Default zu ändern, hat mindestens folgende Vorteile:
    - Keine Gefahr mehr für Nutzer, die Daten anonymisieren wollen
    - Volle Flexibilität für Nutzer, die Gimp nutzen, um Texturen zu erstellen/aus sonstigen Gründen den Alphakanal brauchen
    - GIMP verhält sich intuitiver und Konformer zu Alternativsoftware
    - Vermutlich nur eine Zeile Code-Änderung
    - Gutes Image für GIMP, weil diesem Artikel entweder ein Nachsatz angehangen wird, oder ein zweiter Artikel folgt, in dem beschrieben wird, dass das Problem gelöst ist (und spätestens wenn GIMP sein eigenes Image nicht mehr unter Kontrolle hat, zweifel ich an seiner Qualität als „Image manipulation program“ ;) )

    Der Nachteil:
    - Die spezielle Gruppe der Leute, die GIMP für Texturen o. ä. benutzen, müssen eine Sekunden lang darüber nachdenken, welche Exporteinstellungen sie vornehmen müssen (falls sie das bei diesen Anforderungen nicht eh schon tun)



    1 mal bearbeitet, zuletzt am 18.02.20 14:25 durch janoP.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. HIS Hochschul-Informations-System eG, Hannover
  2. über duerenhoff GmbH, Raum Ulm
  3. Stadtwerke München GmbH, München
  4. Hays AG, Dresden

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. FIFA 20 für 27,99€, Dragon Ball Z Kakarot für 46,89€, Rainbow Six: Siege Deluxe für 8...
  2. (-20%) 47,99€
  3. (-70%) 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de