mouth
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 08:56:30
JOOM::GALLERY::FORUMArchivJoomGallery 1.5 MVCJoomGallery MVC ALPHA/BETAjava upload
Seiten: [1]
Drucken
Autor Thema: java upload  (Gelesen 7728 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
daydreamer
Full Member
***
Offline Offline

Beiträge: 284


« am: 07-09-2009 01:30:56 »

hey, ich bins mal wieder

wenn ich bilder mit java uploade
verschwinden die Exif Daten aus den Bildern


Desweiteren ist mir Aufgefallen die Bilder werden irgendwie größer
(Die Originaldateien hatten ca. 1,5 mb und nach dem Upload im Verzeichniss img_originals ca. 2 Mb)
(Vertikale+Horizontale Auflösung von 72dpi vergrößert sich auf 96dpi)

gruß
thomas
Gespeichert
Chraneco
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 4.066



« Antworten #1 am: 07-09-2009 17:04:31 »

Hi,

diese Probleme scheinen auch in der JoomGallery 1.5.0 schon vorhanden zu sein (siehe hier).

Gruß
Chraneco
Gespeichert

Der Sprecher
Erftralle
Sr. Member
****
Offline Offline

Beiträge: 803


« Antworten #2 am: 20-10-2009 19:01:30 »

Hallo,

das Problem mit den fehlenden Exif Daten und den vergrößerten Originalbildern kann ich ebenfalls bestätigen.
Für die JoomGallery MVC Build 20091017 kann ich auch eine Lösung anbieten.

In der Datei administrator/components/com_joomgallery/views/jupload/tmpl/default.php (ab Zeile 173)
Code
<?php else:?>
         <param name="pictureCompressionQuality" value="1">
<?php endif; ?>
ersetzen durch
Code
<?php else:?>
         <param name="pictureCompressionQuality" value="1">
         <param name="pictureTransmitMetadata" value="true">
<?php endif; ?>

Der zusätzliche Applet Parameter sorgt dafür, dass die Exif Daten in der Originaldatei erhalten bleiben und offensichtlich auch kein Resize mehr vom Applet durchgeführt wird.

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

Beiträge: 2.367


WWW
« Antworten #3 am: 23-10-2009 18:53:53 »

Hallo Erftralle,
soweit ich weiss funktioniert dieser Parameter nicht bei allen Kameramodellen (Link)

Gruß
Andreas
Gespeichert
Erftralle
Sr. Member
****
Offline Offline

Beiträge: 803


« Antworten #4 am: 24-10-2009 11:36:31 »

Hallo Andreas,

auf deinen Hinweis hin hab ich noch ein paar Testuploads gemacht. Dieser Effekt mit den Farben scheint auch noch bei anderen Kameramodellen aufzutauchen (Sony Cybershot z.B.).

Die Parameterkombination aus "pictureCompressionQuality = 1" und "pictureTransmitMetadata = true" scheint aber, für den Fall das die Originalbilder nicht gelöscht werden sollen, die einzige Möglichkeit zu sein, dass das Applet (in der Version 4.4.0) das Bild nicht "anrührt" und es so hochlädt, wie es ist. Für den Fall wäre ja dann auch das Kameramodell egal. Drehen darf man das Bild vorher natürlich nicht mehr.

Lasse ich den Parameter "pictureTransmitMetadata" weg, dann ist er per Default false. Das Applet scheint dann das Bild umzurechnen. Dabei benötigt das umgerechnete Bild in meinem Tests anschließend doppelt so viel Speicherplatz wie vorher. Dies ist auch nicht im Sinne de Erfinders und ist sicherlich wieder Ursache von Fehlern, die mit zu geringem Speicher zu tun haben.

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

Beiträge: 2.367


WWW
« Antworten #5 am: 26-10-2009 23:54:15 »

Hallo erftralle,

Zitat
Die Parameterkombination aus "pictureCompressionQuality = 1" und "pictureTransmitMetadata = true" scheint aber, für den Fall das die Originalbilder nicht gelöscht werden sollen, die einzige Möglichkeit zu sein, dass das Applet (in der Version 4.4.0) das Bild nicht "anrührt" und es so hochlädt, wie es ist. Für den Fall wäre ja dann auch das Kameramodell egal. Drehen darf man das Bild vorher natürlich nicht mehr.

Nur nebenbei:
Für den JAVA Upload ist die Option 'Originalbilder nach Upload löschen' anders im Vergleich z.B zu dem Einzelupload zu bewerten. Tatsächlich rechnet das Applet das Bild lokal in die Dimensionen für das Detailbild um und lädt dieses auf den Server. Dort erfolgt also nur noch die Umwandlung in das Thumbnail. Es wird kein Originalbild hochgeladen, dass in Detail/Thumb umgerechnet wird, um dann auf dem Server wieder gelöscht zu werden.

Ich stimme Dir zu, ein nicht angegebener Parameter "pictureTransmitMetadata" würde per Default auf 'false' (berechtigt, siehe Link) eingestellt sein. Die Datei würde verändert werden. Ebenso bei den anderen von Dir geschilderten Modifikationen (Drehen/Kompression). Ich denke aber auch, dass wir uns um solche Parameter für einen 'puren' Upload der Originaldatei nicht mehr kümmern sollten....

Mein Ansatz wäre hier:
Code:
<param name="uploadPolicy" value="PictureUploadPolicy">

Die 'PictureUploadPolicy' mag einige Defaulteinstellungen hinsichtlich lokaler Konvertierung beinhalten, die sinnvoll sein mögen, aber für einen Upload einer unveränderten Datei unproduktiv sind. Warum also das Applet nicht als reinen Fileuploader herunterstufen, indem der Parameter weggelassen wird (=DefaultUploadPolicy)? Nur eine Idee und nicht getestet...

Zitat
Dabei benötigt das umgerechnete Bild in meinem Tests anschließend doppelt so viel Speicherplatz wie vorher. Dies ist auch nicht im Sinne de Erfinders und ist sicherlich wieder Ursache von Fehlern, die mit zu geringem Speicher zu tun haben.

Ich denke, dass Speicherprobleme (=Memory) hier nicht auftreten, die Dimensionen und die Bittiefe ändern sich ja nicht...
Es ist mir aber immer noch ein Rätsel, warum ein Weglassen von Informationen (Meta) diese Vergrößerung bewirkt. Bei der Kompression schon eher, besonders wenn versucht wird, ein schon stark komprimiertes Bild (=geringe Qualität) auf die höchte Qualitätsstufe zu pushen.

Gruß
Andreas
Gespeichert
daydreamer
Full Member
***
Offline Offline

Beiträge: 284


« Antworten #6 am: 12-11-2009 23:27:58 »

hey,

sorry das ich auf die anderen Posts nicht geantwortet hab, Ich kenne mich da leider zu wenig aus.

Ich Habs grad getestet mit dem Build 20091108

leider sind noch alle Fehler vorhanden.

mfg
daydreamer
Gespeichert
Erftralle
Sr. Member
****
Offline Offline

Beiträge: 803


« Antworten #7 am: 18-11-2009 17:01:23 »

Hi

@daydreamer:
Hast du auch die oben aufgeführten Änderungen gemacht?
Hast du im Backend Originale löschen auf Nein gestellt?
Hast du diesen Bug behoben (der war in dem von dir angegebenen Build noch nicht gefixt)?

Gruß
Erftralle
Gespeichert
daydreamer
Full Member
***
Offline Offline

Beiträge: 284


« Antworten #8 am: 18-11-2009 17:40:59 »

Hey,
Ich hab exif Informationen :
Die Änderungen an dem Build
2010-11-14

diesen Bug behoben 

und
Code:
<?php else:?>
          <param name="pictureCompressionQuality" value="1">
          <param name="pictureTransmitMetadata" value="true">
<?php endif; ?>

geändert.

Folgendes war schon geändert in der Build 2010-11-14 (hab ich zumindest in Zeile 167 gefunden
Code:
<param name="uploadPolicy" value="PictureUploadPolicy">


mfg
daydreamer
Gespeichert
Erftralle
Sr. Member
****
Offline Offline

Beiträge: 803


« Antworten #9 am: 18-11-2009 17:59:51 »

Hallo aHa,

wenn auch verspätet, vielen Dank für deine ausführlichen Erklärungen. Das Thema hat mir keine Ruhe gelassen und ich hab den Sourcecode vom Applet ein wenig studiert.

Zitat
Es ist mir aber immer noch ein Rätsel, warum ein Weglassen von Informationen (Meta) diese Vergrößerung bewirkt. Bei der Kompression schon eher, besonders wenn versucht wird, ein schon stark komprimiertes Bild (=geringe Qualität) auf die höchte Qualitätsstufe zu pushen.

Du hast natürlich Recht. Das Weglassen von Informationen (Meta) bewirkt natürlich nicht die Vergrößerung. Es ist die Kompression. Dazu hab ich mal ein paar Testuploads mit immer demselben Bild gemacht und dabei den Parameter pictureCompressionQuality variiert. Der Parameter pictureTransmitMetadata stand dabei (standardmäßig) auf false.

Die Bilddatei (jpg) hat im Original 582 KB.

Nach dem Upload hat die Bilddatei im Pfad für die Originale folgende Werte:

CompressionQuality = 1.00  -> 952 KB
CompressionQuality = 0.95  -> 595 KB
CompressionQuality = 0.90  -> 469 KB
CompressionQuality = 0.85  -> 389 KB
CompressionQuality = 0.80  -> 316 KB

Dabei ist es ja mitnichten so, dass eine Verwendung von CompressionQuality = 1.0 eine Qualitätsverbessung des Bildes nach sich zieht, denn bereits wegkomprimierte Informationen kann man ja nicht mehr wiederherstellen. Auch rein optisch zeigt der Vergleich der beiden hochgeladenen Bilder bei den Qualitäten 1.0 und 0.8 keine signifikanten Unterschiede.

Diese enorme Vergrößerung kann ja eigentlich nur an den bei höheren Qualitäten nach der Diskreten Cosinustransformation zur Verwendung kommenden feineren Quantisierungsstufen liegen ?

Gruß
Erftralle
Gespeichert
daydreamer
Full Member
***
Offline Offline

Beiträge: 284


« Antworten #10 am: 22-11-2009 02:08:12 »

Hey

Build     2009/11/21

Bildgröße und Exif immer noch Fehlerhaft.

mfg

Daydreamer
Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #11 am: 24-11-2009 20:26:03 »

Hallo Erftralle,
eigentlich könnten wir bei der Betrachtung der Bildgrößen die META-Information komplett ignorieren.
Diese sind nicht Bestandteil der verlustbehafteten Kompression und vielmehr auf ein bestimmtes Bild fix anzusehen, auch wenn diese
beliebig groß werden können. Auf jeden Fall würden sie nicht die Vergrößerung der Dateien bei höheren Qualitätsstufen (als nötig) erklären.

Zitat
Dabei ist es ja mitnichten so, dass eine Verwendung von CompressionQuality = 1.0 eine Qualitätsverbessung des Bildes nach sich zieht, denn bereits wegkomprimierte Informationen kann man ja nicht mehr wiederherstellen. Auch rein optisch zeigt der Vergleich der beiden hochgeladenen Bilder bei den Qualitäten 1.0 und 0.8 keine signifikanten Unterschiede.

Genau, die Qualitätsvorgabe von 1.0 versucht aber, vermutlich per Interpolation, Informationen einzufügen, die schlichtweg unnötig sind. Ich nenne es gern schlicht 'Datenmüll'.
Der besser passendere Begriff 'digitales Rauschen' ist leider schon belegt.

Du wirst sicherlich schon bemerkt haben, dass eine JPEG-Datei eines einfarbigen Motives (weißes Blatt Papier) bedeutend kleiner ist als die eines komplexeren Motives. Natürlich bei sonst gleichen Einstellungen wie z.B. ISO. Klar, die JPEG Kompression kann bei dem ersten Motiv sehr viel effektiver 'unnötige' Informationen wegkomprimieren, idealerweise auf die Information eines einzigen Bildpunktes.

Zitat
Diese enorme Vergrößerung kann ja eigentlich nur an den bei höheren Qualitäten nach der Diskreten Cosinustransformation zur Verwendung kommenden feineren Quantisierungsstufen liegen ?
Die Quantisierung funktioniert anders gesagt nur bei der Kompression eines Bildes von einer höheren Qualität zu einer niedrigen. Natürlich nur bis zu einem akzeptablem artefaktarmen Ergebnis. Der umgekehrte Weg führt dagegen zu unnötigen Bildinformationen. Die diskrete Cosinusinformation bewirkt eigentlich 'nur' einen Verlust aufgrund von Rundungsfehlern. Hier scheint die Quantisierung einen größeren Anteil zu haben. Nur eine Vermutung.

Ich denke, dass man bei JPEG keinen Weg findet, der vermeidet, dass bereits verlustbehaftete komprimierte Bilder (JPEG) unnötig hochgerechnet werden und damit größere Dateigrößen erzeugen. Zumindest kenne ich keinen Algorithmus, der aus dem Bild erkennt, dass eine höhere Qualitätsstufe als die bereits vorhandene sinnvoll wäre und es dann auch konvertiert. Das JPEG speichert leider keine Historie über seinen Werdegang ab.....

Interessanter wäre es TIFF Dateien (mit verlustfreier LZH-Kompression) oder DNG in JPEG umzuwandeln. Das scheitert aber leider an bekannten Restriktionen (Dateigrößen usw.).
Zumindest würde es sich hier tatsächlich um unveränderte 'Originale' vom Sensor handeln.

Gruß
Andreas
Gespeichert
daydreamer
Full Member
***
Offline Offline

Beiträge: 284


« Antworten #12 am: 23-12-2009 21:05:38 »

Hey,

ich wollt mal nachfragen ob es hier was neues gibt ?

oder ob man den hier evtl. auch beenden sollte.

mfg daydreamer
Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #13 am: 23-12-2009 21:17:26 »

Hey,
der Thread sollte geöffnet bleiben.
Ich denke, dass hier noch viele Fragen nicht beantwortet sind

Gruß
Andreas
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 1678 access attempts in the last 7 days.

mouth