Willkommen Gast.
Um die volle Funktionalität des Forums nutzen zu können,
müssen Sie sich einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

 
Erweiterte Suche

31.110 Beiträge in 6.475 Themen- von 6.477 Mitglieder - Neuestes Mitglied: Frideborg

31-03-2020 16:12:51
JOOM::GALLERY::FORUMArchivJoomGallery 1.5 MVCZusammenspiel mit anderen Komponenten1.5.0.1 FEHLER ('Originalbilder' modifiziert/vergrößert, Exif+IPTCDaten fehlen)
Seiten: [1]
Drucken
Autor Thema: 1.5.0.1 FEHLER ('Originalbilder' modifiziert/vergrößert, Exif+IPTCDaten fehlen)  (Gelesen 8307 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
broennie
Newbie
*
Offline Offline

Beiträge: 9


« am: 06-06-2009 17:28:15 »

Habe einen SUSE-Linux-Server (10.3) mit ImageMagick ergänzt. Seitdem ist die Qualität der konvertierten Bilder in Joomgallery sprunghaft gestiegen. Ist sogar an den Thumbnails bereits mit bloßem Auge zu erkennen. (Q=85, keine Überschärfung, aber eben eine recht gute)

Aber leider hat der JAVA-Upload alle Exif- und IPTC-Daten gekillt, welche bei den vorherigen Uploads und der Konvertierung mit GD2 alle vorhanden waren.

Kurioserweise kommt noch hinzu, daß ich die Bilder der 2. und 3. Testkategorie per JAVA-Upload hochgeschoben habe. Und genau diese beiden Uploads haben die Originalbilder um ca. 50% im Volumen vergrößert !  Statt 700 KB bei 1200 Pixeln Bildbreite haben die Bilder nun 1100 KB bei gleicher Pixelgröße !

D.h. also, daß beim JAVA-Upload auch die 'Originalbilder' per ImageMagick (convert) modifiziert wurden. Irrtum ausgeschlossen. Ich habe die 'Originalbilder' extra wieder vom Server geholt, weil ich es nicht glauben wollte. Und genau bei diesen Bildern fehlen auch die EXIF- und IPTC-Daten.

Beim normalen 'Joomla-Upload' bleiben die Bilder wirklich original und sie behalten auch ihre EXIF und IPTC-Daten.

Scheint also wohl ein Problem beim Java-Upload in Kombination mit Image-Magick zu sein !!

Konfiguration:
Joomla 1.5.11 und Joomgallery 1.5.0.1 und ImageMagick 6.3.5.10-2.2 (HostEurope 10.3 Repository)


Ansonsten läuft die Joomgallery super und die Umsetzung für Joomla 1.5 ist wirklich fantastisch gelungen. Bitte weiter so !!


Anmerkung-1:
Habe das Problem nochmal getestet. Joomgallery 1.5.0.1 nochmal jungfräulich aufgesetzt. Das gleiche Ergebnis !
=> Beim JAVA-Upload werden auch die 'Originalbilder' per ImageMagick (convert) modifiziert (= vergrößert und EXIF + IPTC entfernt).

Anmerkung-2:
Ich habe, wie bei einem anderen Problem von mab (oder aha?) empfohlen, mir mal die admin.uploads.html.php angeschaut und dort die Zeile 763. Sie lautet bei mir:
<param name="pictureCompressionQuality" value="1">      Daran liegt es wohl auch nicht !
Wobei sich mir die Frage stellt, warum das Java-Upload-Modul überhaupt die Originalbilder per 'convert' von ImageMagick anfasst. Sie sollten doch wohl, wie der Name schon sagt, unverändert nur auf dem Server abgelegt werden. Oder läßt sich dieses Verhalten des Java-Upload-Moduls nicht von außen steuern. Werden also alle vom Java-Upload-Modul übertragenen Bilder automatisch durch den ImageMagick-Converter geschickt ?

Anmerkung-3:
Das nagelneue Java-Upload-Modul V.4.3.3 vom 5.6.2009 läuft noch nicht mit der Joomgallery 1.5.0.1 , sondern bricht mit einer Fehlermeldung ab. (s. Anhang)

Anmerkung-4:
Sagt der Patient zum Arzt: Alle Welt ignoriert mich !   Sagt der Arzt zum Patient: Der nächste bitte !
(Da ich in der Rubrik 'Sonstiges' keine Resonanz fand, sei das Problem hier nochmal dargelegt! Da ich Hobbyfotograf bin, hat das Thema für mich durchaus Relevanz!)
« Letzte Änderung: 07-06-2009 14:28:18 von broennie » Gespeichert
mab
Entwickler-Team
Administrator
Hero Member
*****
Offline Offline

Beiträge: 1.279



« Antworten #1 am: 06-06-2009 18:41:46 »

Hi broennie,

wir ignorieren Dich und das Problem nicht. Wir haben das gelesen und schauen, ob wir das Problem lösen können. Es ist nicht notwendig, mehrere Threads aufzumachen und auch Rot als Farbe für Einträge macht uns nicht munterer; dass das Problem nicht so einfach zu lösen ist, sollte Dir klar sein, da es sich um Fremdsoftware handelt. Und unsere Freizeit ist endlich. Also, übe Dich in Geduld. Alles wird gut  sm_smilewinkgrin
« Letzte Änderung: 06-06-2009 18:48:39 von mab » Gespeichert

Gruß mab
broennie
Newbie
*
Offline Offline

Beiträge: 9


« Antworten #2 am: 07-06-2009 14:19:54 »

Ich wollte auch nicht hetzen oder drängeln. Nur da ich unter 'Sonstiges' sehr wenig gelesen wurde und keine Antwort fand, hatte ich den Tread auch hier eingestellt. Ich wollte nur sicherstellen, dass euch das Problem bekannt ist !
( Aber vielleicht hat das Ausrufzeichen ja doch etwas geholfen die Aufmerksamkeit der Entwickler zu wecken. Diesmal kam eine Antwort in einer halben Stunde.  sm_wink  )

Aber Spaß beiseite. Ihr macht einen Superjob / eine Supergalerie. Das Problem ist bestimmt keines mit hoher Priorität. Mich wundert nur, dass ImageMagick nicht mehr Interesse bei den Usern weckt. Beim Durchsuchen des Forums danach gibt es kaum Treffer. Anscheinend ist es nur für Fotografen von Interesse.
« Letzte Änderung: 07-06-2009 14:28:00 von broennie » Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #3 am: 07-06-2009 17:51:09 »

Hallo,
ich versuche mal zu antworten..

zu ImageMagick:
Die Werte für den '-unsharp' Parameter des convert sind auf '3.5x1.2+1.0+0.10' eingestellt. Eigentlich ist es mehr ein Kompromiss (da noch nicht im Backend der Galerie parametrierbar), der zu einer recht guten Schärfe führt, soweit Du das Bild nicht schon lokal in Sachen USM bearbeitet hast. Sonst würden hässliche Schärfeartefakte nach der Bearbeitung durch convert entstehen. Aber diese Einstellung scheint Dir ja zu gefallen.... Teilweise habe ich in meinen Tests sogar eine Erhöhung der Farbsättigung (besonders im roten Bereich) bemerkt. Aber da kann ich mich auch täuschen..
Weitere Informationen zu dem Parameter findest Du hier. Mit den EXIF/IPTC Daten hat dies nichts zu tun.

zu dem JAVA-Upload und den verloren gegangenen Metadaten:
schau mal bitte hier und suche dort nach dem Parameter 'pictureTransmitMetadata'. Anhand der Erklärungen (Beschränkung auf wenige Kameramodelle und zusätzliche Probleme in der Farbdarstellung des Ergebnisses) wirst Du hoffentlich Verständnis dafür haben, dass wir den Parameter überhaupt nicht erst mit der Einstellung 'true' berücksichtigt haben. Konkret: Wenn das JAVA-Applet eine Veränderung lokal durchführt, also, wenn Du nur die Detailbilder übertragen willst (Originalbild löschen), werden die EXIF/IPTC Daten nicht berücksichtigt.

Wenn ich die Erklärung des Parameters richtig verstanden habe, bleiben diese Daten erhalten, wenn das Originalbild ohne lokale Änderung durch das Applet übertragen wird.
Dann sollten auch diese Daten bei der Erstellung des Detailbildes auf dem Server erhalten bleiben. Egal, ob dieses per GD2 oder ImageMagick erzeugt wird. Zitat: "Metadata from picture transmitted 'as is' are not removed. This is corrected in 3.3.0."

Am besten postest Du bitte einen Debuglog (Debuglevel=100) des Applets, um zu erkennen, welche Aktionen tatsächlich bei dem Upload ausgeführt werden.

Zitat
Das nagelneue Java-Upload-Modul V.4.3.3 vom 5.6.2009 läuft noch nicht mit der Joomgallery 1.5.0.1 , sondern bricht mit einer Fehlermeldung ab. (s. Anhang)
Was hast Du Dir von der Verwendung dieser Version konkret erhofft? Mal abgesehen vom "bug 2793249: formData would not work on IE7"

Gruß
Andreas
Gespeichert
broennie
Newbie
*
Offline Offline

Beiträge: 9


« Antworten #4 am: 08-06-2009 22:39:14 »

Hallo Andreas,

die von mir auf eine Testseite hochgeladenen Bilder sollten keinen hohen fotografischen Ansprüchen genügen. Wie ich glaube, habe ich sie vor einiger Zeit mit Lightroom auf ca. 1/4 Gesamtauflösung (3888x2592 -> 1944x1296) verkleinert. Keine spezielle USM, nur Lightroom-Standard, wahrscheinlich geschärft für die Bildschirmausgabe. Lightroom ist hier sehr vorsichtig, also recht wenig Schärfung. Individuelle richtige USM Parameter wurden also nicht benutzt, sondern eine Standardschärfung, welche für alle Bilder gleich ist und keinesfalls individuell mit den USM-Parametern auf das jeweilige Motiv abgestimmt wurde.

In Verbindung mit diesen nur leicht geschärften Bildern führen die von dir gewählten Parameter zu ganz passablen Ergebnissen !!

Interessant ist hier folgendes:
Das Testbild von FotoCommunity hat er nach dem Java-Upload als Originalbild verkleinert, das enthaltene Farbprofil entfernt, aber das ganze Bild hat er bereits auf ein sRGB-Profil komplett umgerechnet. Dieses Bild wird also von allen Programmen ohne Farbverwaltung auch bereits halbwegs 'farbecht', also ohne die grellen Überstrahlungen im ROT und GRÜN-Bereich dargestellt. Somit auch bereits vom den heutigen Browsern, die nach meinem Wissen ja auch noch ohne Farbverwaltung arbeiten. Dies wäre allerdings der gegenteilige Effekt zu der von dir beobachteten erhöhten ROT-Sättigung, vielleicht ein Irrtum ? Die EXIF- und IPTC-Daten hat er aber auch hier entfernt und ich hatte extra dieses Portrait genommen, da es mit einer Nikon-D70 entstand. Kann also nichts mit dem Canon-Bug zu tun haben!

Im Anhang beigefügt noch die beiden Debuglogs des Java-Applets, jeweils vom Testbild und vom Portrait. Nur wie ich hier einen Debuglevel auf 100 setzen kann, da bin ich leider nicht dahintergekommen (mit Strg + Maus-rechts aber wohl nicht)

Das Applet 4.3.3 zu testen war nur ein Schuss ins blaue von mir. Hätte ja sein können, dass es anders reagiert, bezüglich der Konvertierung der 'Originalbilder'.


PS - Was mir gerade noch so einfällt:
Wenn du die Parameter für die Größenänderung des Java-Uploads im Joomgallery-Backend verfügbar machst, dann könnte man diese augenblickliche 'Fehlfunktion' des Java-Uploads ja sogar sehr gut nutzen. Im Augenblick verkleinern wir die tatsächlichen Originalbilder zunächst einmal, z.B. mit IrfanView, auf eine maximale Kantenlänge von 1200 Pixel. Diese Bilder schieben wir jetzt als 'neue Originalbilder' auf den Server um dort entsprechend Platz zu sparen, da sonst der Server zu schnell voll wäre. (Mit diesen 1200er Bildern kann man ja auch noch gute Abzüge mit 10x15cm machen lassen.)
Diese 'Vorabverkleinerung' vom 1. zum '2.Originalbild' könnte, entsprechende Kongiguration des Apache mal vorausgesetzt, ja in Zukunft dann der Java-Upload übernehmen. Und die User könnten in Zukunft ihre tatsächlichen Originalbilder hochladen, die dann auf das im Joomgallery-Backend eingestellte 'Originalmaß' automatisch vom Java-Upload verkleinert würden. Oder mache ich hier einen Denkfehler ? Vielleicht ist es ja vom Java-Upload-Applet genau so angedacht ?
« Letzte Änderung: 18-06-2009 13:55:02 von broennie » Gespeichert
broennie
Newbie
*
Offline Offline

Beiträge: 9


« Antworten #5 am: 18-06-2009 13:38:50 »

Hallo Andreas (aHa)

Habe mir auf http://jupload.sourceforge.net/advanced_js_demo.html mal die Parameter des Java-Upload-Applets angeschaut.

Vermutlich habt ihr bei den fünf wählbaren 'uploadPolicies' im Moment die 'PictureUploadPolicy' gewählt.

Dann greifen die Picture mode parameters:


z.B. unter anderem highQualityPreview, pictureTransmitMetadata, maxPicHeight, maxPicWidth

Wenn man diese Parameter im Backend der Joomgallery zugänglich machte, dann könnte jeder beim Java-Upload der Bilder quasi die Maximalgröße seiner Bilder, die letztlich in den 'OriginalBildOrdnern' landen, selber bestimmen. Es wäre also nicht mehr nötig die Originalbilder aus heutigen Digitalkameras in Megabytegröße vor dem Upload erst zu verkleinern, um den stets knappen Platz Platz auf dem Server nicht zu verschwenden. Jeder Laie könnte also die soeben geschossenen Fotos direkt, also ohne weitere 'Zwischenbehandlung', auf den Server hochladen. (OK, von Upload-Zeitbedarf und Server-Konfiguration jetzt mal abgesehen. Aber dies dürfte bei Laien, wenn man es gut erklärt, doch keine Rolle spielen.)

Diese 'Vorabverkleinerung' der Bilder, bevor sie auf dem Server als 'Originale' abgelegt werden, würde dann eben das Java-Upload-Applet nebenher erledigen. Außerdem könnte man wohl per 'Metadata-Backend-Schalter' selbst bestimmen, ob die Metadaten, wie EXIF und IPTC, mit übertragen oder eliminiert werden sollen.


Außerdem könnte man durch Umstellen der uploadPolicy auf Default oder FileByFile vermutlich die momentane Bildkonvertierung beim Java-Upload in der Joomgallery abschalten, da ja die Bilder dann vermutlich als normale Files behandelt werden. D.h. die Bilder würden dann, wie derzeit beim normalen Upload oder beim Batch-Upload, tatsächlich original, d.h. ohne 'Zwangskonvertierung' auf dem Server abgelegt. (Habe ich allerdings nicht getestet, ist nur eine Vermutung.)


Im übrigen existiert bei den 'Upload-Policies' sogar eine 'Coppermine-Upload-Policy'. Möglicherweise sind im Backend der neuesten Coppermine ja genau solche Funktionen realisiert.

Da ich in der nächsten Zeit eh eine Coppermine-Galerie für einen bestimmten Zweck 'standalone' aufsetzen wollte, werde ich mir dort das Java-Upload-Applet dann nochmal genauer anschauen.

Wenn du mir mitteilst wo im PHP-Code die Applet-Parameter gesetzt werden, brauchte ich sie nicht lange zu suchen und könnte damit mal ein bißchen experimentieren. Außerdem könnte ich sie dann evtl. mal mit denen der Coppermine vergleichen. Allerdings kann dies noch ein paar Wochen dauern.

Gruß
Klaus
« Letzte Änderung: 18-06-2009 14:06:01 von broennie » Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #6 am: 18-06-2009 19:55:54 »

Hallo Klaus,
entschuldige bitte, dass ich lange nicht geantwortet habe.
Bevor ich später mehr in das Detail gehe:

Du findest die Parameter für das Applet in der Datei:
/administrator/components/com_joomgallery/includes/html/admin.uploads.html.php
in der Funktion Joom_ShowJUpload_HTML ab der Zeile 740

Gruß
Andreas
Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #7 am: 18-06-2009 22:00:57 »

Antwort auf diesen Beitrag

Vernachlässigen wir bitte diese Parametrierung von Image Magick. Wenn diese Für Dich zu guten Ergebnissen führt, ist es in Ordnung.
Natürlich kann man sie zukünftig über das Backend anbieten. Ein anderes Thema....
Einen Irrtum in meiner 'Rot' Interpretation schließe ich natürlich nicht aus.

Zu dem Debug 100:
Klicke rechts mit gedrückter STRG-Taste in das Applet und wähle 'Debug enabed'
ebenso mit 'Show log window'

Im Anhang ein Debug nach Aufruf des JAVA Upload und Einschalten der beiden Optionen.

Zitat
Wenn du die Parameter für die Größenänderung des Java-Uploads im Joomgallery-Backend verfügbar machst, dann könnte man diese augenblickliche 'Fehlfunktion' des Java-Uploads ja sogar sehr gut nutzen. Im Augenblick verkleinern wir die tatsächlichen Originalbilder zunächst einmal, z.B. mit IrfanView, auf eine maximale Kantenlänge von 1200 Pixel. Diese Bilder schieben wir jetzt als 'neue Originalbilder' auf den Server um dort entsprechend Platz zu sparen, da sonst der Server zu schnell voll wäre. (Mit diesen 1200er Bildern kann man ja auch noch gute Abzüge mit 10x15cm machen lassen.)
Diese 'Vorabverkleinerung' vom 1. zum '2.Originalbild' könnte, entsprechende Kongiguration des Apache mal vorausgesetzt, ja in Zukunft dann der Java-Upload übernehmen. Und die User könnten in Zukunft ihre tatsächlichen Originalbilder hochladen, die dann auf das im Joomgallery-Backend eingestellte 'Originalmaß' automatisch vom Java-Upload verkleinert würden. Oder mache ich hier einen Denkfehler ? Vielleicht ist es ja vom Java-Upload-Applet genau so angedacht ?

Moment, wir haben dieses Applet nicht entwickelt, sondern nur über die entsprechenden Parameter eingebunden. Wir werden auch keine Nebenversion des Applets anbieten. Dies macht auch nicht die Coppermine, sie löst es über eine eigene Policy.

Unser Ausgangspunkt ist immer noch die Parametrierung der JoomGallery. Die Größenänderung selbst übernimmt nicht das Applet, sondern der Server aufgrund der Einstellungen der Galerie.
Ausnahme: Wenn die Originalbilder nicht übernommen werden sollen, erfolgt die Größenänderung lokal im Applet. Es wird dann also nur das Detailbild übertragen. Wahrscheinlich meinst Du das?

Mit einer Kantenlänge von 1200px erhält man sogar akzeptable Abzüge in DIN A4 oder mehr. Ich erinnere mich da noch an Diskussionen in der FC... Lang ist es her.
Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #8 am: 18-06-2009 22:19:04 »

Antwort auf diesen Beitrag

Stimmt, wir nutzen die 'PictureUploadPolicy'.

Zitat
z.B. unter anderem highQualityPreview, pictureTransmitMetadata, maxPicHeight, maxPicWidth
Ich bin ein wenig verwirrt, wo steht das?

Schau bitte auch hier unter 'Functionalities' und 'Parameters'
Damit wird eher die Anzeige der GUI Elemente gesteuert, grob gesagt...

Die Coppermine Policy als Subklasse davon unterstützt zusätzlich den Upload in bestimmte Alben (Quelle)
« Letzte Änderung: 18-06-2009 22:21:32 von aHa » Gespeichert
broennie
Newbie
*
Offline Offline

Beiträge: 9


« Antworten #9 am: 19-06-2009 17:38:49 »

Die Zusatzparameter der PictureUploadPolicy findest du hier:

http://jupload.sourceforge.net/advanced_js_demo.html

ein weiterer wohl interessanter Link zu dem Entwickler des Coppermine-Plugins, welches auch das Java-Upload-Applet für Coppermine nutzt findest du hier:

http://forum.coppermine-gallery.net/index.php/topic,43432.html

leider bin ich gerade auf dem Sprung, daher später mehr zu deinen Antworten.

Gruß
Klaus
Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #10 am: 20-06-2009 16:26:03 »

Da bin ich mal gespannt....
Vielleicht könntest Du mir noch sagen, welche Zusatzparameter tatsächlich spezifisch für die Coppermine Policy sind

nebenbei: Danke für diese konstruktive Diskussion
Gespeichert
Seiten: [1]
Drucken
Gehe zu:  

HOSTED BY SCHWARZKÜNSTLER ®

PROTECTED BY  ZB BLOCK  AND Project Honey Pot
Theme orange-lt created by panic

Bad Behavior has blocked 1664 access attempts in the last 7 days.

mouth