Ich suche ein Programm, das sicher alle Daten, die nicht Bilddaten sind, aus Bildern löscht. Dazu gehören alle standardisierten Metadaten und alle nicht standardisierten Daten. Die Betonung liegt auf letzterem. Es kann ja sein, dass jemand Daten einfügt, die von den standardisierten Exif Viewern nicht gesehen und angezeigt werden, aber mit Spezialprogrammen sichtbar gemacht werden können. Folglich würden Exif-Löschprogramme diese Daten auch nicht löschen. Ich weiß nicht ob das funktioniert aber vielleicht müsste so ein Löschprogramm eine neue Datei öffnen und dann ausschließlich die Bilddaten Bit für Bit und sonst nichts in diese neue Datei kopieren. Dann wäre sichergestellt, dass alles andere raus ist.
Hallo, ich nutze gerne jpg & png stripper. Für PDFs BeCyPDFMetaEdit. Gruß Carsten
Angehängte Dateien:
-
MusterOhneWert.jpg
21 KB
Steganography? Ein Bild verändern und wieder abspeichern wäre einfach. Es wäre jedoch möglich, dass Dein Foto nur Teil eines Kreuzworträtsels ist oder gerade der gelbe Fliegendreck eine entscheidende Info ist?
Irfanview kann das auch, wahrscheinlich sogar als Stapelverarbeitung .
Kolja L. schrieb: > Irfanview kann das auch, wahrscheinlich sogar als > Stapelverarbeitung . Kann es. Zumindest EXIF, IPTC, XMP. Aber der TO fragt ja nach nicht Standard Metadaten. Wobei ich mich prinzipiell Frage wie man etwas entfernt wo man weder weiß wie es aussieht, noch wo es steht!? Im Bild selbst kann man ja auch genug Daten verstecken wenn man möchte.
:
Bearbeitet durch User
Screenshot machen und als BMP speichern. Garantiert keine Metadaten.
Zui schrieb: > Ich weiß nicht ob das funktioniert aber vielleicht müsste so ein > Löschprogramm eine neue Datei öffnen und dann ausschließlich die > Bilddaten Bit für Bit und sonst nichts in diese neue Datei kopieren. https://de.wikipedia.org/wiki/Computergest%C3%BCtzte_Steganographie In diesem Fall ist es vermutlich am Einfachsten, wenn dir das nicht manipulierte Bild vorliegt.
Beobachter schrieb: > Screenshot machen und als BMP speichern. > Garantiert keine Metadaten. Doch, die kann es haben. (Bin ich eigentlich der einzige, der die Specs usw. von so Zeugs durchliest?) https://learn.microsoft.com/en-us/previous-versions/dd183376(v=vs.85) > If biCompression is BI_JPEG or BI_PNG, the biHeight member specifies the > height of the decompressed JPEG or PNG image file, respectively. Theoretisch kann man einfach einen Bitmap Header vor ein JPG / PNG file packen (natürlich mit den passenden Parametern), und hat ein bmp, mit Metadaten vom JPG/PNG darin her. Ich weiss aber nicht, ob / wie breit Bildanzeigeprogramme das unterstützen, ich hab es noch nicht ausprobiert.
:
Bearbeitet durch User
Nicht nur Specs durchlesen, sondern mit dem Editor Datei ansehen? Einfach planlos drin herum ändern wird wohl zu einer Fehlermeldung führen.
Specs durchlesen und planlos drin herum ändern sind zwei sehr verschiedene Dinge, ja eigentlich gar das Gegenteil. Solange man sich an die Specs hält, sollten die Dateien gültig sein.
Zui schrieb: > Ich suche ein Programm, das sicher alle Daten, die nicht Bilddaten sind, > aus Bildern löscht. Dazu gehören alle standardisierten Metadaten und > alle nicht standardisierten Daten. Schau mal hier: https://de.wikipedia.org/wiki/Digitales_Wasserzeichen "Wasserzeichen sind in eine Reihe von Attributdaten eingebettet, um zu verhindern, dass Angreifer Wasserzeichen zerstören." Michael
:
Bearbeitet durch User
abc schrieb: > https://de.wikipedia.org/wiki/Computergest%C3%BCtzte_Steganographie Wenn ich es richtig verstehe, könnte Folgendes Szenario denkbar sein: Ein Staat zwingt einen Smartphonehersteller dazu, die damit gemachten Fotos mit versteckten Informationen zu versehen, die den Rückschluss auf das konkrete Smartphone zulassen, mit dem das Foto geschossen wurde, indem eine Ursprungs-ID für das Smartphone vergeben wird. Da sich auf dem Smartphone in aller Regel die Daten des Besitzers finden, kann also jedes Foto diesem zugeordnet werden. Dies könnte auch dadurch geschehen, dass nur ein einziges Foto unter Realnamen gepostet wird, z-B- bei Wikipedia oder in diesem Forum hier. Kann auch nur ein einziges Foto einer realen Person zugeordnet werden, so kann jedes weitere Foto mit hoher Wahrscheinlichkeit auch dieser Person zugeordnet werden, wenn es ohne Angaben zur Person gepostet wurde oder sonstwie gefunden wird. Beispielsweise könnte ein proprietäres Betriebssystem (beim Smartphone gibt es nur solche) nach Hause telefonieren und die Ursprungas-IDs sämtlicher Fotos auf sämtlichen Smartphones des Herstellers weitergeben.
Dropel schrieb: > einziges Foto einer realen Person zugeordnet Dann nützt auch kein Wasserzeichen-Entferner, weil ein User nie weiß, wieviele Hintertüren in diesem Tool schon sind oder ob die KI alles findet. https://www.watermarkremover.io/de
Dropel schrieb: > Ein Staat zwingt einen Smartphonehersteller dazu, die damit gemachten > Fotos mit versteckten Informationen zu versehen, die den Rückschluss auf > das konkrete Smartphone zulassen, mit dem das Foto geschossen wurde, > indem eine Ursprungs-ID für das Smartphone vergeben wird. Also das, was Drucker schon seit vielen Jahren heimlich tun? https://de.wikipedia.org/wiki/Machine_Identification_Code Es ist anzunehmen, dass die Handys das auch bereits tun.
Kolja L. schrieb: > Irfanview kann das auch Macht es das automatisch beim abspeichern oder muss man irgendwas einstellen?
Daniel A. schrieb: > Theoretisch kann man einfach einen Bitmap Header vor ein JPG / PNG file > packen Testweise mal 2 solche Dateien im Anhang. Die erste ist mit dem alten BMP Header, das ist eigentlich obsolete / nicht mehr erlaubt. Bei der anderen hab ich den v4 Header genommen, dort ist PNG noch erlaubt. Die Colorspace Informationen habe ich nicht gesetzt, keine Ahnung, ob das erlaubt ist oder nicht.. Chrome, Edge, und Firefox, scheinen die Datei unter Windows anzeigen zu können. Andere Programme, die damit klar kommen, konnte ich nicht finden (weder unter Linux, noch unter Windows). Word hängt sich auf, wenn man ihm die Datei gibt. Unter Firefox ESR mit Linux ging die Datei nicht. Ich vermute, dass die Browser unter Windows die Datei direkt den entsprechenden WinAPI Funktionen geben, ohne extra Checks, und es dort deshalb geht. Oh, um zu zeigen, dass da wirklich einfach ein PNG nach den Headern ist, kann man mit dd checken:
1 | dd if=img3.bmp bs=1 skip=54 of=img3.png |
2 | dd if=img4.bmp bs=1 skip=122 of=img4.png |
Das simpelste Bildformat ist übrigens farbfeld. farbfeld support ist aber leider noch nicht besonders weit verbreitet. https://tools.suckless.org/farbfeld/
🐧 DPA 🐧 schrieb: > Das simpelste Bildformat ist übrigens farbfeld. farbfeld > support ist aber leider noch nicht besonders weit verbreitet. Da schau her. Warum PNM verwenden, wenn man das Rad nochmal erfinden kann... https://de.wikipedia.org/wiki/Portable_Anymap
Alt G. schrieb: > Kolja L. schrieb: > >> Irfanview kann das auch > > Macht es das automatisch beim abspeichern oder muss man irgendwas > einstellen? Da gibt es eine Stapelverarbeitung und dann unter Option, oder so... Ist schon lage her 😃
Grummler schrieb: > 🐧 DPA 🐧 schrieb: > >> Das simpelste Bildformat ist übrigens farbfeld. farbfeld >> support ist aber leider noch nicht besonders weit verbreitet. > > Da schau her. > Warum PNM verwenden, wenn man das Rad nochmal erfinden kann... > > https://de.wikipedia.org/wiki/Portable_Anymap Jenachdem kann das Erstellen der Bilder einfacher sein, und einfacher erweiterbar, da das Format flexibler ist. Aber insgesamt ist es viel Komplexer als farbfeld, insbesondere auch, wenn man es einlesen will. Da hat man Textzeilen, Ascii kodierte Zahlen, mehrere Typen, Kommentare, Extensions für z.B. 16bit, Farbraum/Transparenz. etc. (Auch bei der Binärversion!) Mit farbfeld hat man das alles nicht. Einfach die Grösse und Daten, fertig. Also immer noch viel einfacher.
Das Problem bei einem fertigen Programm ist ja, dass man nicht sicher wissen kann was das Programm macht wenn es Grafikdaten einliest oder abspeichert - dass dabei Metadaten mit übertragen werden ist im Normalfall ja kein Bug sondern ein Feature. Ich habe schon öfter versucht herauszufinden was genau jeweils passiert, das ist aber nur mit grossem Testaufwand möglich, die Dokumentationen helfen kaum. Ich hätte es z.B. gern so, dass bestimmte Metadaten mitgenommen werden (z.B. Aufnahmedatum und Uhrzeit eines Fotos), alle anderen nicht. Ich habe aber bisher keine handhabbare Möglichkeit gefunden einzeln auszuwählen, was erhalten bleibt und was nicht, abgesehen davon dass es hunderte genormte Metadaten gibt und dazu noch ungenormte. Auswählen artet da in echte Arbeit aus. Man kann mit dem Windows API eine Grafik in eine Bitmap im Speicher einlesen, die enthält dann garantiert nichts anders als die Bildpunkte, und diese wieder ausgeben in einem anderen Format, dafür gibt es Libraries. Dann sind die Bilddaten tatsächlich nackt, aber das ist meistens garnicht das erwünschte. Sowieso reichen die Pixel allein nicht, jedes real verwendbare Bildformat braucht ja noch Angaben zur Auflösung und Farbtiefe und ev. noch eine Lookup-Tabelle. Aber wenn man sich die nicht unerhebliche Mühe macht selbst so etwas zu programmieren weiss man wenigstens was passiert. Georg
Beitrag #7283816 wurde von einem Moderator gelöscht.
Georg schrieb: > Das Problem bei einem fertigen Programm ist ja, dass man nicht sicher > wissen kann was das Programm macht wenn es Grafikdaten einliest oder > abspeichert - dass dabei Metadaten mit übertragen werden ist im > Normalfall ja kein Bug sondern ein Feature. Das ist das schöne an OpenSource. Du musst es nicht unbedingt selber schreiben, aber jeder kann trotzdem in den Quellcode schauen, wenn er paranoid genug ist - oder wie z.B. bei vscode einen Fork machen, aus dem die nach-Hause-telefonier-Funktion entfernt wurde. > Ich habe aber bisher keine handhabbare Möglichkeit gefunden einzeln > auszuwählen, was erhalten bleibt und was nicht Mit exiftool (nein, das kann nicht nur exif) kann man solche Daten selektiv entfernen. https://exiftool.org/
Rolf M. schrieb: > Mit exiftool (nein, das kann nicht nur exif) kann man solche Daten > selektiv entfernen. Ich schrieb ja "handhabbar". In der Irfanview-Hilfe sind 35 IPTC-Tags und ca. 100 EXIF-Tags aufgeführt, dafür noch zahlreiche spezielle für bestimmte Kameras, man müsste also nahe 200 Auswahlen anklicken (sofern über GUI, sonst eben Kommandozeile). Aber das ist kein Problem einer bestimmten Software, es ist halt so umfangreich. Das einzige was schnell geht ist alles löschen, aber solche Informationen wie das Aufnahmedatum möchte ich schon behalten. Georg
Beobachter schrieb: > Screenshot machen und als BMP speichern. > Garantiert keine Metadaten. Das glaubst auch nur du. Wer sagt dir denn, dass der Bildinhalt mit einer Tiefe von 8/24 Bit (sw/Farbe) abgelegt ist? Wenn der Bildinhalt nur 7/21 Bit nutzt, hat man jeweils das unterste Bit frei, um dort Metadaten abzulegen, die der Betrachter nicht von Bildrauschen unterscheiden kann.
Wolfgang schrieb: > Wenn der Bildinhalt nur 7/21 Bit nutzt, hat man jeweils das unterste Bit > frei, um dort Metadaten abzulegen, die der Betrachter nicht von > Bildrauschen unterscheiden kann. und wenn ggf noch die Bildgrösse verändert wird? Erkennt eine "Bildrauschlesesoftware" den GeheimInhalt bei jeder Bildgrösse?
Georg schrieb: > Man kann mit dem Windows API eine Grafik in eine Bitmap im Speicher > einlesen, die enthält dann garantiert nichts anders als die Bildpunkte Woher weißt du, dass die "Bildpunkte" nicht auch Metadaten enthalten? Wolfgang schrieb: > Wer sagt dir denn, ...
Georg schrieb: > Das einzige was schnell geht ist alles löschen, aber solche > Informationen wie das Aufnahmedatum möchte ich schon behalten. Du kannst exiftool auch sagen, es soll alles außer dem Datum entfernen, wenn du das willst. Natürlich kann exiftool nur das entfernen, was es kennt, aber so kannst du z.B. alles entfernen außer dem Erzeugungsdatum:
1 | exiftool -all= -tagsfromfile @ -CreateDate meinfile.jpg |
:
Bearbeitet durch User
Wolfgang schrieb: > Beobachter schrieb: >> Screenshot machen und als BMP speichern. >> Garantiert keine Metadaten. > > Das glaubst auch nur du. Wer sagt dir denn, dass der Bildinhalt mit > einer Tiefe von 8/24 Bit (sw/Farbe) abgelegt ist? Du kannst auch einfach den Offset zu den Bilddaten erhöhen, und dort was rein tun. Aber eben, man kann da auch ein PNG oder JPEG als Bilddaten reinpacken, und die Metadaten dort rein tun, geht also auch "richtig".
🐧 DPA 🐧 schrieb: > Grummler schrieb: >> 🐧 DPA 🐧 schrieb: >> >>> Das simpelste Bildformat ist übrigens farbfeld. farbfeld >>> support ist aber leider noch nicht besonders weit verbreitet. >> >> Da schau her. >> Warum PNM verwenden, wenn man das Rad nochmal erfinden kann... >>... > ... > Mit farbfeld hat man das alles nicht. Einfach die Grösse und Daten, > fertig. Also immer noch viel einfacher. Dafür ist Farbfeld ziemlich verschwenderisch. Ob man 16 Bit Farbtiefe für einfache Grafiken zwingend braucht, ist nämlich fraglich und eine in das Bildformat eingebaute Kompression ist auch nicht vorgesehen. Klassische Formate wie BMP, PCX, PBM sind da weitaus sparsamer und ja, der Header muss natürlich geringfügig komplexer sein, wenn man sowohl Graufstufen, 8 Bit, 24 Bit usw. Farbtiefe anbieten will, aber das bisschen Overhead ist schnell in einem entsprechenden Parser berücksichtigt, wenn man den unbedingt einen eigenen schreiben muss. Es gibt ja bestehende Bibliotheken für so etwas. Warum das Rad neu erfinden?
Nano schrieb: > Ob man 16 Bit Farbtiefe für einfache Grafiken zwingend braucht, ist > nämlich fraglich und eine in das Bildformat eingebaute Kompression ist > auch nicht vorgesehen. Das ist absicht. Man soll einfach bestehende Kompression nehmen, wie bei Unix üblich. Dann hat man z.B. .ff.gz, oder .ff.xz, oder .ff.bz2, genau so wie man bei .tar auch .tar.gz, .tar.xz, usw. hat. Ist ja trivial, das durch gzip zu pipen. Wobei, auch das in einem Programm zu integrieren ist trivial, viel einfacher als die Kompression anderer Bildformate zu implementieren. Und laut den Erfindern soll das ganze ähnlich effizient sein, wie die integrierte Kompression in bestehenden verlustfreien Formaten.
🐧 DPA 🐧 schrieb: > Das ist absicht. Man soll einfach bestehende Kompression nehmen, wie bei > Unix üblich. Dann hat man z.B. .ff.gz, oder .ff.xz, oder .ff.bz2, genau > so wie man bei .tar auch .tar.gz, .tar.xz, usw. hat. So gesehen hätte MP3 unter Unix nie eine Chance. Manche Kompressionsverfahren, die ein bisschen tiefer ansetzen, wären mit dem Ansatz grundsätzlich zum Scheitern verurteilt. Es gibt unterschiedliche Räder - je nach Verwendungszweck.
🐧 DPA 🐧 schrieb: > Dann hat man z.B. .ff.gz, oder .ff.xz, oder .ff.bz2, genau > so wie man bei .tar auch .tar.gz, .tar.xz, usw. hat. Genau, wenn man damit leben kann mit keinem Abspielgerät außer einem Linux-PC seine Fotos anzusehen kann man diese Formate gerne nutzen.
Wolfgang schrieb: > Woher weißt du, dass die "Bildpunkte" nicht auch Metadaten enthalten? Weil mir der Aufbau einer Bitmap aus der Windows-Dokumentation bekannt ist. Sowas wie Aufnahmedatum oder Kameratyp ist da nicht enthalten. Eben nur eine Bitmap. Georg
Georg schrieb: > Weil mir der Aufbau einer Bitmap aus der Windows-Dokumentation bekannt > ist. Sowas wie Aufnahmedatum oder Kameratyp ist da nicht enthalten. Schau mal den Anhang weiter oben an: https://www.mikrocontroller.net/attachment/573065/img4.bmp Die Forensoftware kommt damit zwar nicht zurecht, aber dien Browser sollte damit klar kommen. Ein funktionierendes Bitmap, aber die Bilddaten sind ein PNG. Und das geht auch mit JPEG. In dem PNG hatte ich um es klein zu halten keine Metadaten eingebaut, aber das hätte ich durchaus tun können. (Übrigens, erstellt habe ich die BMPs auch anhand der MS Dokumentation, lies die nochmal genauer durch, besonders die neueren BMP Versionen und bV4V4Compression https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header). (Wobei es auch eine mittlerweile als obsolete merkierte Doku von MS mit dem alten Header gab, siehe oben das andere auch funktionierende BMP).
Le X. schrieb: > wenn man damit leben kann mit keinem Abspielgerät außer einem Linux-PC NetPBM ist älter als Linux. Wenn man will, dass Windows-Nutzer sich ein Bild nicht anschauen können, dann nennt man es aux.jpg oder nul.gif. :-) .bz2-Endungen versteht inzwischen sogar Windows und behandelt das Archiv wie jedes andere auch.
Georg schrieb: > Wolfgang schrieb: >> Woher weißt du, dass die "Bildpunkte" nicht auch Metadaten enthalten? > > Weil mir der Aufbau einer Bitmap aus der Windows-Dokumentation bekannt > ist. Sowas wie Aufnahmedatum oder Kameratyp ist da nicht enthalten. Eben > nur eine Bitmap. Wie oben schon erwähnt wurde, gibt es auch die Möglichkeit, in den Pixeldaten Informationen als unsichtbare "Wasserzeichen" zu verstecken. Michael D. schrieb: > Schau mal hier: > https://de.wikipedia.org/wiki/Digitales_Wasserzeichen
Jörg W. schrieb: > Le X. schrieb: >> wenn man damit leben kann mit keinem Abspielgerät außer einem Linux-PC > [..] > .bz2-Endungen versteht inzwischen sogar Windows und behandelt das Archiv > wie jedes andere auch. Ich schrieb auch bewusst "Abspielgeräte" und nicht "PC" weil ich auf einem PC immer irgendwelche Möglichkeiten habe, Codecs und Entpacker nachzuinstallieren, auch unter Windows. PCs sind aber immer weniger relevant. Ichn denke grad an Handys und Tablets, digitale Bilderrahmen, Fire-TV-Sticks oder Smart-TVs oder wo man halt sonst heutzutage seine Fotosammlung zur Schau stellt. Würd ich stark anzweifeln dass deren Bildbetrachter-Software aus dem Stand mit irgendwelchen Archiven zurecht kommt, wohl aber mit einer Vielzahl von Bildformaten.
:
Bearbeitet durch User
Le X. schrieb: > Ich schrieb auch bewusst "Abspielgeräte" und nicht "PC" weil ich auf > einem PC immer irgendwelche Möglichkeiten habe, Codecs und Entpacker > nachzuinstallieren, auch unter Windows. Nur, dass bzip2 halt da ganz ohne was Nachinstalliertes schon da ist. > Ichn denke grad an Handys und Tablets, digitale Bilderrahmen, > Fire-TV-Sticks oder Smart-TVs oder wo man halt sonst heutzutage seine > Fotosammlung zur Schau stellt. Dann musst du sowieso gucken, was die wirklich können, denn oft implementieren sie nur eine Untermenge der jeweiligen Standards. Ich habe hier einen Bilderrahmen, der bei interleaved JPEGs, wie sie mittlerweile von vielen Grafikprogrammen standardmäßig produziert werden, weil es bei Webanwendungen Vorteile bringt, nur den ersten ("matschigen") Frame darstellt. Da hilft es mir allein auch nicht, dass da "JPEG" als Etikett an der Datei steht. Bein Handys wiederum bist du inzwischen (fast) genauso flexibel wie bei PCs, was du alles noch installieren kannst. Gerade bei Videos dürfte es bei vielen so ziemlich die erste Aktivitäts sein, ein VLC zu installieren.
Das ist halt alles "könnte", "kann man", "geht irgendwie". Jetzt mal in einem Satz: hälst du es für praktikabel wie von DPA vorgeschlagen keine Codec-basierte Komprimierung mehr zu nutzen sondern die Bilder jeweils zu gz-en und durch gzip zu pipen?
:
Bearbeitet durch User
Le X. schrieb: > Jetzt mal in einem Satz: hälst du es für praktikabel wie von DPA > vorgeschlagen keine Codec-basierte Komprimierung mehr zu nutzen Für übliche Fotos sicher nicht, denn dort nutzen wir ja vor allem aus, dass JPEG halt eine lossy compression ist und dadurch bessere Kompressionsverhältnisse erreicht als lossless. Aber das war ja eh nur seine Antwort auf "farbfeld" um zu zeigen, dass es Vergleichbares bereits (sehr lange) gibt.
Hier noch ein kleines tool, das ich eben erstellt habe, um Text zwischen den Header und die Bilddaten eines BMPs einzufügen. Einfach BMP auswählen (oder auf file input schieben), Text eingeben, und wieder raus ziehen / Rechtsklick Speichern. Wenn man es wieder einfügt, hat man den Text wieder. Ist zwar nicht so versteckt wie wenn man es in die Bilddaten packt, aber dafür gibt es keine Grösseneinschränkung, und keine Änderungen an den Bilddaten. https://stuff-s.s.abrecht.li/bmgap.html
Zui schrieb: > Ich weiß nicht ob das funktioniert aber vielleicht müsste so ein Das Sicherste ist hier beispielos das Bild nicht raus zu tun sondern auf der eignen Festplatte zu halten. Ansonsten: 1. Anonymandroidhandy besorgen, 2. Entwicklunsmodus aktivieren. 3. Fake positionierer installieren 4. Fake positionierer aktivieren 5. Position setzen auf Nordpol oder Waldiwostock 6. Befragtes Bild mit dem Handy vom Bildschirm abfotografieren Und dann veröffntlichen. Das gibt ein angemessens HALLO! Hertzlichesten Glühstrumpf wie man früher so sagte.
Es gibt: 1. EXIF und vergleichbare Daten 2. Wasserzeichen 3. Steganografie 4. Der individuelle Fingerprint des Bildsensors 5. Sichtbare Daten im Bild Zu 1: Das wird man los, in dem man das Bild mit einer Bildbearbeitung wie Gimp lädt, das Bild ausschneidet und in eine neue Datei speichert. Zu 2. und 3. und 4. Hier könnte man einen Rauschfilter drüberlegen, der das 0. Bit für jeden RGBA Wert verändert. Das Problem: Manche Wasserzeichen und Steganografieverfahren sollen gegen so etwas robust sein. Ändert man auch das 1. Bit für jeden RGBA Wert, dann wird die Änderung leider bereits gut sichtbar. Zu 4. Hier hilft nur einrahmen und die Stelle einfärben. Noch eine weitere Anmerkung: Sollte das Bild eine verlustbehaftete Kompression verwendet haben, dann hat man beim nächsten Abspeichern mit einem vergleichbaren verlustbehafteten Kompressionsformat einen Informationsverlust.
Nano schrieb: > Zu 4. > Hier hilft nur einrahmen und die Stelle einfärben. Das sollte "zu 5." heißen.
Man könnte den gleichen Weg gehen, wie das ein sog. "SBC" (session border controller) bei VOIP macht: Die Nutzdaten aus dem Eingangs-Datenstrom "auspacken", ggf. umformen/transformieren und selber wieder "einpacken". Bei VOIP nutzt man das aus Sicherheitsgründen und zur Codec/Format-Wandlung on-the-fly. Setzt allerdings einige Programmier-Kenntnisse voraus ...
> Zu 2. und 3. und 4. > Hier könnte man einen Rauschfilter drüberlegen, der das 0. Bit für jeden > RGBA Wert verändert. > Das Problem: Manche Wasserzeichen und Steganografieverfahren sollen > gegen so etwas robust sein. Ändert man auch das 1. Bit für jeden RGBA > Wert, dann wird die Änderung leider bereits gut sichtbar. Man könnte mal probieren, den so entstehenden Farb-Fehler mittels Error-Diffusion auf die Nachbarpixel zu verteilen. Dann halten sich die optischen Auswirkungen in Grenzen
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.