nicht angemeldet
Hi,
Ja, auch viele die nicht in den Specs stehen. Vielleicht kann exif_read_data() auch nur die Namen der Offsets nicht ermitteln, bzw. kennt exif_read_data() diese Tags einfach nicht. Letzeres ist wohl anzunehmen, da exif_read_data() "UndefinedTag" meldet, manche Tags aber sehr wohl Daten enthalten, die man bei etwas Phantasie sogar selbst interpretieren könnte ;-).
Ah, dann ist also nur der EXIF-Reader kaput bzw nicht uptodate.
Aber, um ehrlich zu sein, ich faende es jetzt nicht _so_ unwahrscheinlich, das sich die Hersteller ihr individuelles eigenes Sueppchen kochen *sigh* :-}
Mit Verlaub, aber: hae? Macht das irgendeinen Sinn, den wir augenblicklich nicht verstehen, oder ist die Gebrauchsanleitung so besch...eiden?
Zuerst zum "Orientation"-Tag: Wenn ich
http://www.exif.org/Exif2-2.PDF (Seite 142, Explication Table 3)
richtig verstanden habe, wird dieser bei Rotation explixit auf 1 gesetzt. Daher scheidet er als Kriterium zur Dreh-Erkennung wohl aus.
Der "Orientation"-Tag wird ebenda auf Seite 18 behandelt und kann Spiegelung und Drehung beschreiben, wenn auch nur 90 Grad weise, da nur die Positionen von Zeile respektive Spalte 0 beschrieben wird. Aufgrund des Defaults ist normalerweise das Pixel {0,0} oben links.
Also ich kann Bilder in der Vorschau meiner Kamera drehen. Soweit, so gut. Aber das gedrehte Bild wird nicht als gedreht gespeichert. Die Gebrauchsanleitung der Kamera meinst Du? Nein, da steht nichts dazu, enthält lediglich informationen zur Bedienung, nicht aber zur rechnergesteuerten Auswertung.
Ich glaube die Speicherung im Kameraspeicher eines mittels einer auf der Kamera befindlichen Software bearbeiteten Bildes ohne weitere externe Hilfsmittel ist durchaus der Bedienung eben jener Kamera zuzurechnen, meinst Du nicht? ;-)
imagecreatefromjpeg()
imagetruecolortopalette()
http://de.php.net/manual/de/function.imagepalettecopy.php bzw. so ähnlich wie imagepalettecopy_exact() aus den "User Contributed Notes".
...
Ah,nein, nicht ganz so. Du hast einfach zuviele Farben in der Pallete und die Groesse des Hashes ist auch viel zu hoch. Je weniger Farben die Pallete dabei hat (na, nicht ganz. Ich denke mal so zwei Hand voll sollten es schon mindestens sein ;-) und je besser die im Spektrum verteilt sind, desto besser das spaetere Ergebniss. Die Groesse des Hashes betraegt dabei mindestens 4 Pixel (2x2), in deinem Fall waeren es aber besser 16 (4x4).
In Deinem Fall kaeme dann z.B. raus, das zwei benachbarte Ecken blau sind (Himmel) und die beiden gegenueber gruen (oder rot, habe das jetzt nicht ausprobiert). Damit und der Ratio bekaemst Du dann sofort die Drehrichtung raus. Problem: das ist dann nicht sauber von einer Spiegelung unterscheidbar, dafuer braeuchtest Du pro Seite noch einen aussermittigen Punkte mehr. Deshalb auch meine Empfehlung mit 16 Pixeln.
Fuer den Winkel der Rotation waere in diesem Beispiel jedoch mehr Aufwand noetig falls die Genauigkeit 90 Grad ueberschreiten soll.
Die Komprimierungsrate hat in sofern damit zu tun, daß beim Erstellen über imagejpeg ( int im [, string filename [, int quality]] ), bei identischem Orginal, je nach quality, den Pixeln mit gleichen Koordinaten verschiedene Farbwerte zugewiesen werden, was ja auch zu erwarten ist. Dies hat mit Sicherheit auch Auswirkung auf die Farbpalette.
Ja, eben, deshalb sollst Du das auch anders machen.
Auf die Feststellung "Datt funktioniert so nich!" sollte bei einem gutem Ingenieur normalerweise die Frage "Wie kann man das dann anders machen?" auf dem Fusse folgen, oder? ;-)
Ja, das menschliche Auge ist nunmal ein unuebertroffener Mustererkenner ;-)
Warum habe ich das nur nicht schon früher erkannt?
Vielleicht hast Du ja das Muster nicht erkannt? ;-)
Mmh ... ich glaueb nicht, das das so funktioniert, JPEG ist eine Kompressionstechnik mit Verlust.
Ja, aber die Verluste müsste doch bei ähnlichen Bildern ähnlich bzw. nachvollziebar sein, sofern die Komprimierungsraten gleich sind, oder?
Ja, aber eben nur _aehnlich_. Die Methode der Kompression ist dadurch, das sie aus Prinzip mit Verlust arbeitet im Grunde genommen recht beliebig, es muss nur moeglich sein, aus dem Endergebniss etwas rauszuziehen, die Datenstruktur JIF muss valide sein, das ist schon alles.
Es ist auch bei verlustlosen Kompressionsalgorithmen nicht unaehnlich, da hast Du trotz valider Datenstruktur verschiedene Dateigroessen der komprimierten Daten. Die verschiedenen ZIP-Programme packen zwar unterschiedlich gut, aber jedes ZIP-Programm kann normalerweise das von anderen Programmen gepackte wieder auspacken.
So ist das auch bei JPEG.
Den Code werde ich demnächst mal online stellen und zum Test freigeben. Zuvor möchte ich ihn aber noch ein bisschen säubern ;-)
Ach komm:"Release early and often!", denn vielleicht findet sich ja ein Dummer, der fuer Dich saubermacht? ;-)
so short
Christoph Zurnieden
Gunnar Bittersmann