data bending

Schwellen in Index-Einzelfarben in Photoshop

Das Ausgangsbild hat folgenden Graustufenverlauf:

wp-hg-silvered2

Danach stelle ich eine äusserst schlechte Qualität ein beim Abspeichern als Jpeg, Stufe 1 

wp-hg-silvered2kl

Man erkennt die Farbschwellen, die den Farbverlauf imitieren sollen. Sobald ich es in Photoshop wieder öffne und im Modus “Indexfarben” einstelle, habe ich die Wahl ob mir das Bild in Webfarben, einzelne seperate Farben oder andere Farbpaletten aufgerastert werden soll. Wähle ich nun “Custom” kann ich eingeben, wieviele es sein sollen.  Ich nehme “6” und gebe “Diffusion” unten bei dem Rastermuster ein. Nun entscheidet sich nahezu willkürlich, wo und wie diese wenigen Punkte an die Schwelle treten.

wp-hg-silvered2kl-index-greyscale-diffusiongif

- HIER DAS BILD IN DER VOLLEN AUFLÖSUNG (!) -


Databending intra extrafile.org/

 

Folgendes Originalbild als .bmp in Extrafile:

test

Danach  speichere ich es als typische xtrafile-Formate  ab.  Manche haben andere Komprimierungen und Pixelreihenfolgen. Am besten erkennt man dies bei farb- und flächenarmen Grafiken:

.cci und danach .bmp

test-cci-low-bmp

.4bc und danach .bmp

test-4bc-bmp

.bascii und danach .bmp

test-bascii-bmp

.blinx und danach .bmp

test-blinx-bmp

.mcf und danach .bmp

test-mcf-bmp

.xff und danach .bmp

.uscpec und danach .bmp

 test-uspec-bmp


 

 

Binärcode editieren der extrafiles

Das Testbild ist ein .tif

141017172246_imagealsjog


Ich öffne es mit Extrafile für OSX und speichere es im programmspezifischen 4bc-Format ab

4bc-icon128

141017172246_4bc-jpg

Diese Datei öffne ich im 0xED Hex Editor. Sie besteht in der ascii-Anzeige fast nur aus “w”. Ich übe folgende binäre Anordnungsänderungen durch:

0xED-glitchedBlox


Das Ergebnis sieht so aus:

141017172246_4bcglitched

 

 


Micro Databending mit 1 dpi und Dekoderieren zur Ansicht

 

Zunächt wähle ich ein Originalbild aus.Es ist handelt sich um ein übliches Mainstram-jpeg und hat eine Größe von 210×170 px mit 170 dpi.

headerbild170dpi

Es wird nun auf 1 dpi heruntergerechnet mit einer Größe von 7×6 px

headerbild-1dpi7x6px

Das Ziel war es, zu erfahren, welche Auswirkungen es hat, wenn man diese winzige Datei databendet, dann vergrößert (von 1dpi auf 1 MB in einem Hexa Editor), ob überhaupt etwas passiert, und wenn ja, wie sehr.
Dazu habe das Bild mit 1dpi, 7x6px auf 1 MB im Hexaeditor vergroessert und danach eine beliebige Bitstream Füllung (einer anderen Datei) hineingesetzt (links) Den Header habe ich nicht markiert, da sonst die Datei schnell komplett kaputt geht. Genau dasselbe BIld habe ich anschliessend ERST gefüllt (datagebended) und DANN auf 1 MB vergrößert (rechts)
Ich habe es (hier direkt) etwas vergrößert. Die Abbildungen entsprechen dem Dateisymbol auf meinem Desktop (ohne sie zuöffnen)

headerbild-1dpi7x6px-auf1MBvergroessert-dannfilled- headerbild-1dpi7x6px-filled-dannauf1MBvergroessert

Jede Datei habe ich also einfach seperat abgespeichert. Wenn ich auf Dateiinformationen aufrufe, hat sich bei den Grunddaten der Bilder lediglich das Gewicht der Datei verändert, auf 1 MB. Alles andere blieb gleich.

Nun stellt sich heraus, wie die Datei aussieht, wenn man sie einmal im Photoshop öffnet und
einmal im Irfan View (vgl. Vorschau bei Apple)

Und so sieht die Datei aus, die ich erst vergrößert und dann gebendet habe, wenn ich
sie im Photoshop öffne (oben) und so sieht die Datei aus, die ich erst gebendet habe
und dann vergrößert (unten) .

(Zoom jeweils auf 1200%)

dannfilled-1200prozentzoom

dannvergrößert-1200prozentzoom

Man erkennt anhand der vergrößert dargestellten Pixel eine andere Anordnung. Es ist also ein Unterschied, ob ich im Hexa Editor zuerst ein Bild vergrößer und dann databende oder andersherum.

Was passiert, wenn ich die geometrische Größe der Bilder wieder auf 210x180px vergrößere (im Photoshop)? So sieht die Datei aus, die ich im Hexa Editor erst vergrößert und dann gebendet habe, wenn ich sie im Photoshop öffne und größer ziehe (links) , und rechts dasselbe mit der Datei, die ich im Editor erst gebendet und dann vergrößert habe.

vergroessert-dannbended bended-dannvergroessert


Hier nebenbei mal ein Vergleich, wenn ich die gebendeten Dateien in einem anderen Bildansichtsprogramm öffne. Man erkennt übrigens keinen Unterschied zwischen den zwei Versionen

headerbild-1dpi7x6px-auf1MBvergroessert-dannfilled-ps-1dpi-21opx-low-gespeichert-geöffnet-in-iv

Wir merken hier, dass es schon einen Unterschied macht, ob man Bildgrößen von ein und demselben Bild ändert (intraProgramm) und danach glitcht, oder erst glitch und dann das Bild vergrößert.

Interessant hierbei ist, wie merkbar sich die Pixelboxen und -anordnungen ändern, wenn man beim Abspeichern im Photoshop ie Bildqualität ändert

1 8 10

 


Macro Bug Hug mit interlaced-raw und planar-raw

Zunächt wähle ich ein Originalbild aus.Es ist handelt sich um ein übliches Mainstram-jpeg und hat eine Größe von 210×170 px mit 170 dpi. Dieses habe ich verluststark auf eine Fläche von 3000×3000 px mit 300 dpi importiert und hochgezogen.
Hier ein Abbild. Man erkennt die schönen “Verschmutzungen” die eine Großskalierung mit sich bringen. Schon Fotokünstler wie Thomas Ruff zeigen simpel konzipierte und doch so geniale Bilderreihen mit Pixellandschaften, die uns bei stark komprimierten Bildern sonst nur als störend und unsauber vorkommen. (Kann man also hier auch von Glitch Art reden?)

abfotovorlage3000x3000

Abgespeichert als raw wähle ich einmal die Version A mit Option “interleaved” (beim Speichern angeordnete Pixel von Pixelblock zu Pixelblock “RGBRGBRGB…), und einmal die Version B mit Option “per Channel” (angeordnete Pixel von Farbkanal zu Farbkanal “RRRRRGGGGBBBB)
Das raw hat keinen Header und ich kann es
besser in einem Hexa Editor verarbeiten.

Datei A und Datei B habe ich nun im Editor gebendet. Dazu habe ich in der Asccii-Code Ansicht (nicht in der Hex Ansicht) jeden Punkt (“.”) mit einem “x” ersetzt. Mir fiel da schon auf, dass es bei der interleave-Ablage eine andere Anzahl an Punkten hat, als die mit der non-interleave Ablage.
Danach speichere ich jede Datei ab und öffne sie in Photoshop. Da ein raw vor dem Öffnen ersteinmal interpretiert werden muss, gibt es bei Bildprogrammen Optionen, die man anwählen kann. Da ich den Glitch im raw richtig und authentisch dargestellt haben möchte, wähle ich die originale Farbtiefe und Maße der Datei an. (16 Bit, 3000x3000px, 300 dpi) Bei A “interleaved” und bei B nicht interleaved.

A (mit interleaved angewählt) = auch B (mit nicht interleaved)
headerbild-raw-300dpi-3000x3000-echt-psopen-16bit-kl


Ein Bug Hug ist nicht wirklich ein Glitch. Man spielt eher mit der Darstellungs-und Speicherungsproblematik, die uns beim Öffnen oder Speichern eines Bildes gerne hin und wieder nervt, aber ihren Sinn hat. Selbst ein herkömmliches digitales Foto wird in einem Bildprogramm anders dargestellt als in einem anderen. Es gibt Programme, die sind schon so voreingestellt, dass sie selbst entscheiden, wie das Bild interpretiert wird. Andere wiederum lassen dem Benutzer viele Offenheiten zu entscheiden, wie das Bild dekodiert wird, vorrausgesetzt man öffnet ein unkomprimiertes Bild, z.B. ein raw oder ein tiff.

Da ich den Bug Hug (Bild ist dasselbe bereits gebendete Bild) im raw verfälscht dargestellt haben möchte, gebe ich Photoshop beim Öffnen falsche Informationen und wähle eine andere Farbtiefe (nur 8 Bit, 3000x3000px, 300 dpi) Bei A “interleaved” und bei B nicht interleaved.

A
eins

B
zwei

Hier eine vergrößerte (gezoomte) Ansicht von Version A und B, um zu veranschaulichen, wie sich die Pixel zu den Farbkanälen verhalten.

ausschnitt-headerbild-glitched-rawinPSgeoeffnet-300prozent

ausschnitt-headerbild-glitched-noninterl-rawinPSgeoeffnet-300prozent

Als eine leichte und oberflächliche Form eines Hacks könnte man also einen Bug Hug beschreiben, andere Künstler wiederum empfinden dieses Verfahren ebenfalls als einen Glitch. Wiederum andere behaupten, das geht eher in Richtung Design.

Eine “tiefere” Variante des Bug Huggens wären dann weitere falsche Eingaben zum Öffnen des Bildes, z.B. wenn man “interleaved” und “non-interleaved” austauscht.

A
headerbild-raw-300dpi-3000x3000JETZT-NONinterl

Zoom:

headerbild-raw-300dpi-3000x3000JETZT-NONinterltoom

B

headerbild-raw-300dpi-3000x3000noninterl

Zoom

headerbild-raw-300dpi-3000x3000noninterlzoom

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>