FotoPro 5.6 veröffentlicht / published

[Gert]

Hallo Heiko,

kanst Du mal was für mich testen?

FotoPro admin.php suchen nach:

Code: Select all

/* 
#####################################
        create new gallery
##################################### 
*/

und darüber folgenden Code einfügen:

Code: Select all

// Ausrichtung korrigieren
foreach($fproImages as $fpro_img)
{
	$fproImagePath = $fproDataPath . $_SESSION['fpro_active_gallery'] . '/' . str_replace('_fprolb_','',$fpro_img);
	// 1. EXIF-Daten des Bildes auslesen
	$fproexif = exif_read_data($fproImagePath);

	if ($fproexif && isset($fproexif['Orientation'])) 
	{
		$orientation = $fproexif['Orientation'];
		$fproangle = 0;

		// 2. Den benötigten Drehwinkel ermitteln
		switch ($orientation) 
		{
			case 3:
				$fproangle = 180;
				break;
			case 6:
				$fproangle = -90; // bzw. 270
				break;
			case 8:
				$fproangle = 90;
				break;
		}

		// 3. Bild drehen, falls ein Winkel ungleich 0 ermittelt wurde
		if ($fproangle != 0) 
		{
			$fprosource = imagecreatefromjpeg($fproImagePath);
			$fprorotated = imagerotate($fprosource, $fproangle, 0);
			
			// Gedrehtes Bild wieder als Datei speichern
			imagejpeg($fprorotated, $fproImagePath);
			
			// Speicher freigeben
			if(phpversion() < '8')imagedestroy($fprosource);
			if(phpversion() < '8')imagedestroy($fprorotated);
		}
	}
}
// END Ausrichtung korrigieren

Danach Seite neu laden und im FotoPro Backend die Vorschaubilder neu erzeugen, dann müsste alles sein wie es soll.

In der nächsten Version wird es dann auch gleich nach dem hochladen eines Einzelbildes klappen,

Gert

[Gert]

Hallo Heiko,

da haben wir uns überkreuzt

Ich schau mir Deine Lösung mal an,

Gert

[Gert]

Hallo Heiko,

so wie ich das sehe, ist Deine Lösung nur für jpg/jpeg wirksam, oder? Ich weiss nicht, ob die modernen Smartphones mittlerweile auch andere Formate liefern, die EXIF Daten enthalten. Auf jeden Fall wird aber empfohlen, EXIF Daten vor der Veröffentlichung im www zu entfernen. Dann tritt dieses ganze Phänomen gar nicht erst auf, weil man nach der Entfernung der EXIF Daten das Bild dann sowieso in die richtige Lage drehen muss.

Aber wie auch immer, in der nächsten Version ist das Problem erledigt, vielen Dank für die Meldung

Gert

PS: Bei der Gelegenheit habe ich auch gleich gemerkt, dass ich bei der Einführung von webp und avif die MediumPics vergessen habe -hat noch niemanden gestört, wird dann aber auch gleich noch mit erledigt

[meyomey]

Aus Interesse habe noch einmal CLAUDE befragt:

Meine Korrektur greift bisher **nur bei JPG/JPEG** – aus zwei Gründen:

## Warum nur JPEG betroffen ist

- **EXIF-Orientation ist praktisch ein JPEG/TIFF-Feature.** Kameras und Smartphones schreiben diesen Tag standardmäßig nur in JPEG-Dateien (bzw. TIFF). PNG und GIF unterstützen dieses EXIF-Feld gar nicht in der Praxis – Bilder aus diesen Formaten haben also das Problem, das du beschrieben hast, normalerweise gar nicht.
- **WebP und AVIF** können zwar technisch einen EXIF-Chunk enthalten, aber das kommt in der Praxis kaum vor (kein mir bekanntes Smartphone speichert direkt so). Falls doch, hätte das FotoPro-Plugin das gleiche Problem: `imagecreatefromwebp()`/`imagecreatefromavif()` werten die Orientierung ebenfalls nicht aus.

## Was das für dich heißt

Für den Alltagsfall – Fotos vom Handy oder der Kamera hochladen – ist **JPEG so gut wie immer das Format**, in dem das Orientierungsproblem überhaupt auftritt. Mein Patch deckt also den eigentlichen Anwendungsfall vollständig ab.

Falls du aber tatsächlich auch WebP- oder AVIF-Dateien mit EXIF-Orientation hochlädst (z. B. weil du Bilder vorher selbst konvertierst und dabei die Metadaten erhältst), kann ich die Funktion leicht erweitern – `exif_read_data()` funktioniert bei entsprechend kodierten WebP-Dateien teilweise auch. Soll ich das vorsorglich mit einbauen, oder reicht dir JPEG für deinen Anwendungsfall?

bitte erweitern...

Jetzt baue ich den Funktionsblock komplett um: eine gemeinsame Funktion `fpro_getOrientationTag()` (die je nach Format JPEG-EXIF oder den manuellen WebP-Parser nutzt) plus die Dreh-Funktion, die nur noch den Wert entgegennimmt:Jetzt die drei Aufrufstellen anpassen, damit sie die neue gemeinsame Funktion nutzen und auch die WebP-Branch abdecken:Jetzt Stelle 2 (mediumPics-Erzeugung):Jetzt Stelle 3 (Bulk-Thumbnail-Neuerzeugung – die wichtigste für dich):Jetzt Syntax-Check und alle drei Stellen final verifizieren:Syntax ok, alle drei Stellen sauber verdrahtet. Jetzt teste ich die neue WebP-Logik end-to-end mit den kompletten Funktionen aus der echten `admin.php`:Sehr gut – JPEG funktioniert weiterhin perfekt, und WebP wird jetzt korrekt erkannt und gedreht (600×400 → 400×600). Noch ein Test ohne EXIF-Chunk (normales WebP), um sicherzustellen, dass nichts abstürzt:Alle Fälle sauber abgedeckt – kein Crash, keine falsche Rotation, `NULL` wenn kein EXIF vorhanden ist. Jetzt Aufräumen und neu verpacken:**Erledigt – jetzt auch WebP wird unterstützt.**

## Was ich rausgefunden habe

PHPs `exif_read_data()` unterstützt **WebP grundsätzlich nicht** (offener PHP-Bug, Stand PHP 8.3) und **AVIF auch nicht**. Ich konnte da also nicht einfach die gleiche Funktion nutzen.

## Meine Lösung

- **JPEG:** weiterhin über `exif_read_data()` – unverändert.
- **WebP:** Ich hab einen eigenen kleinen Parser gebaut, der den RIFF-Container manuell durchgeht, den `EXIF`-Chunk sucht und daraus den Orientation-Tag (0x0112) aus der eingebetteten TIFF-Struktur ausliest. Hab ich mit einem echten Testbild (EXIF Orientation 6, Rohpixel 600×400) durchgespielt – Ergebnis nach Korrektur: korrekt 400×600. Auch der Fall "WebP ohne EXIF" und "kaputte/fremde Datei" laufen sauber ins Leere, ohne Fehler.
- **PNG/GIF:** bewusst ausgelassen – diese Formate tragen in der Praxis keinen Orientation-Tag, Kameras/Handys schreiben da nichts rein.
- **AVIF:** hier hab ich es **nicht** implementiert. Der Grund: AVIF-Rotation wird technisch fast nie über EXIF gespeichert, sondern über eigene ISOBMFF-Boxen (`irot`/`imir`), die mit einer komplett anderen, deutlich fehleranfälligeren Parser-Logik ausgelesen werden müssten. Da AVIF-Uploads mit EXIF-Orientation in der Praxis quasi nicht vorkommen, wäre der Aufwand/Nutzen hier schlecht – für deinen Anwendungsfall (Handyfotos) dürfte das ohnehin nie relevant werden.

Der Code ist jetzt auch etwas aufgeräumt: Statt doppelter `exif_read_data()`-Aufrufe gibt es eine zentrale Funktion `fpro_getOrientationTag($filepath, $ext)`, die je nach Dateityp den richtigen Weg wählt – das greift an allen drei relevanten Stellen (Einzelbild-Upload, mediumPics, Bulk-Thumbnail-Neuerzeugung).

Die aktualisierte admin.php liegt wieder hier: https://www.wulmstorf.net/?download=admin.php
Vielleicht inspiriert dich einiges davon...

Danke noch einmal für deine immer wieder schnellen Reaktionen & Fixes!