Hallo zusammen,
dachte mit dem letzten Update geht die Funktion wieder (Lib gd)? Oder fehlt da doch noch was? IPS auf PI. 
Gruß & Danke,
dfhome
Sollte gehen!? (Der andere Fehler betrifft wohl Debian, 32Bit)
Was kommt denn für ein Fehler?
Sicher, dass du die aktuellste Version drauf hast?
paresy
Hallo Paresy,
das mit der Version war der Hinweis, Danke. Version wurde zurückgehalten, „dist-upgrade“ hat geholfen… 
Danke. 
Mit dem neuesten Update geht es wieder nicht; zuvor hat´s funktioniert. Muss ich wegen der libjpeg-Änderung irgendwas anpassen?
Gruß
dfhome
Kann ich bisher nicht nachstellen. Was passiert denn genau?
paresy
Sorry für die späte Antwort…
Ich krieg jetzt immer Fehlermeldungen:
Warning: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error: in /usr/share/symcon/scripts/57761.ips.php on line 8
Warning: imagecreatefromjpeg(): '/usr/share/symcon/webfront/user/Eingangsbereich/cam1.jpg' is not a valid JPEG file in /usr/share/symcon/scripts/57761.ips.php on line 8
Die Bilder lassen sich aber ohne Probleme anschauen.
Hallo zusammen,
bin hier immer noch am grübeln…
Funktioniert denn bei jemandem die Bildbearbeitung?
Hier mal mein Code:
$dir = IPS_GetKernelDir();
// Datum + Uhrzeit einblenden
$picture = '/usr/share/symcon/webfront/user/Eingangsbereich/cam1.jpg';
ini_set ('gd.jpeg_ignore_warning', 1);
$imAlt = ImageCreateFromJPEG ($picture);
if ($imAlt) {
$color = imagecolorallocate($imAlt, 0, 255, 0);
$datetime = date("d/m/Y H:i:s");
ImageTTFText ($imAlt, 20, 0, 315, 30, $color, $dir.'webfront/user/verdana.ttf', $datetime);
imagejpeg ($imAlt, $picture);
}
imagedestroy($imAlt);
Wie gesagt, vor der letzten Änderung der gd-Lib hats funktioniert; jetzt krieg ich immer nur die Fehler, dass die Datei scheinbar kein gültiges JPEG ist. Aber selbst ein JPEG von IrfanView wird als niO markiert…? 
Kann das mal eventuell jemand bei sich prüfen?
Gruß & Danke,
dfhome
Hi dfhome.
Ich kann das gerade bestätigen.
Bekomme auch diesen Fehler.
Werde mal budddeln nach einer Lösung…
Gruß
lueralba
So, nun mag ich nicht mehr buddeln…
Ich habe die Vermutung, das die Base64Codierung/Decodierung irgend etwas verändert oder wegläßt.
Die Datei wird decodiert und abgespeichert. Sie wird dann unter Windows korrekt angezeigt (z.B. Irfan View).
Nur das Kommando „imagecreatefromjpeg()“ kommt damit nicht klar…
Hier sind so einige (frühere) Probleme beschrieben…
http://www.php.net/base64_decode
Sind bestimmt alle nicht mehr aktuell, aber man sucht ja nach Ideen.
Mal sehen ob paresy Eine hat.
Gruß
lueralba
Danke Dir für die Mühe. Beruhigt mich, dass es hier vermutlich ein systematisches Problem ist.
paresy, wir zählen auf Dich.
Push Gibt´s hier schon was Neues, paresy?
Moin moin.
Es hat auch nichts mit der Base64Codierung/Decodierung zu tun, wie ich weiter oben vermutete.
Das habe ich im Script mal umgangen/ausgeschlossen.
Mit RGB oder CMYK hat es auch nichts zu tun !
Ich habe jetzt eben nochmal eine RGB- bzw. eine CMYK- Datei (JPG) auf den Pfad kopiert und dem imagecreatefromjpeg untergejubelt .
imagecreatefromjpeg(): '/usr/share/symcon/cams/19867.jpg' is not a valid JPEG file
scheint ein alleiniges GD JPEG Problem zu sein.
Gruß
lueralba
Schubs.
Hab es gerade auf einem anderen Pi probiert.
Gleicher Fehler…
HM,
ImageCreateFromJPEG ($imgname);
wäre das richtig ?
Bei mir sieht es so aus, aber nur für imagecreate
$Image = imagecreate( 650, 650 );:
Habe damit meine Heizungskurven als Bilddatei erzeugt und lasse die mir Webfront anzeigen:
Hallo
Das Problem mal zum Nachstellen (wer mal mag…)
oder vllt. mir auch meinen Fehler zeigen kann :eek:
Aber wie schon weiter oben beschrieben läuft es unter 3.4 unter WIN
![2016-01-23 20_12_58-IP-Symcon Management Console [3. Pi (B+, 1 wire)].jpg](https://community.symcon.de/uploads/default/original/2X/f/f675cb6f1f5a0631d5bff5ff8a767693a57172fd.jpeg){kind=small}
<?
$grabberdatei = IPS_GetKernelDir()."cams/12206.jpg" ;
@unlink($grabberdatei);
IG_UpdateImage(12206 /*[Image Grabber (WebCams)]*/);
$MediaID = 38871 /*[Image Grabber (WebCams)\Image]*/;
$Inhalt = base64_decode(IPS_GetMediaContent($MediaID));
file_put_contents($grabberdatei, $Inhalt);
$im = ImageCreateFromJPEG($grabberdatei);
?>
Warning: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error: in /usr/share/symcon/scripts/31999.ips.php on line 9
Warning: imagecreatefromjpeg(): ‚/usr/share/symcon/cams/12206.jpg‘ is not a valid JPEG file in /usr/share/symcon/scripts/31999.ips.php on line 9
Einen schönen Abend
lueralba
Das es unter 3.4 läuft wundert mich, du pfuscht IPS da ja in das Medien-Objekt des Grabbers 
Ich würde den Weg über die Datei sparen und gleich imagecreatefromstring($Inhalt) nutzen.
PHP: imagecreatefromstring - Manual
Ob es nun ein Fehler ist oder nicht, vielleicht kannst du ihn so umgehen.
Michael
Hallo Nall chan.
du pfuscht IPS da ja in das Medien-Objekt des Grabbers
Nee es geht ja nur um das ImageCreateFromJPEG() !
Unter 3.4 sieht das Script „normal“ aus. Ich hatte es nur in die V4.0 übrnommen und ausprobiert.
Und da trat der Fehler halt auf wie bei dfhome.
Aber das imagecreatefromstring() werde ich mal testen.
Danke für den Hinweis.
Nachtrag:
Naja …irgendwie ist der Wurm drin?
Warning: imagecreatefromstring(): gd-jpeg: JPEG library reports unrecoverable error: in /usr/share/symcon/scripts/28089.ips.php on line 9
Warning: imagecreatefromstring(): Passed data is not in ‚JPEG‘ format in /usr/share/symcon/scripts/28089.ips.php on line 9
Warning: imagecreatefromstring(): Couldn’t create GD Image Stream out of Data in /usr/share/symcon/scripts/28089.ips.php on line 9
Gruß
lueralba
Mir ist das Problem mit der JPEG-Lib nie aufgefallen, weil wenn das fehlschlägt, schreibe ich das Originalbild weg, außerdem tritt das Problem nicht unter Windows auf :o
In den Logs taucht dann auch das hier auf:
<b>Warning</b>: imagecreatefromstring(): gd-jpeg: JPEG library reports unrecoverable error
<b>Warning</b>: imagecreatefromstring(): Passed data is not in 'JPEG' format
<b>Warning</b>: imagecreatefromstring(): Couldn't create GD Image Stream out of Data
Das mit MediaBild ist bei dir dennoch komplett ‚falsch‘ gelöst.
Erst löscht du das alte Bild, was unter IPS3 ein ‚rotes‘ Media-Objekt erzeugen sollte.
Dann läßt du den ImageGrabber das Bild neu holen (bei IPS 3.4 wird es somit gleich in cams/12206.jpg geschrieben, unter 4.0 nur in den RAM, es wird also gar keine cams/12206.jpg geschrieben).
Dann holst du die Daten aus dem IPS-Objekt und schreibst sie wieder in die gleiche Datei… warum ?!
Für IPS 3 ist das also komplett unnötig.
Und unter IPS4 umgehst du somit das absichtliche caching, außerdem wird die Änderung der Datei nicht das Medien-Objekt aktualisieren, da Dieses ja nur im RAM liegt.
Davon abgesehen das hier wirklich unter Linux etwas kaputt ist, solltest du das Vorgehen hier ändern.
Eventuell einfach in ein zweites Medien-Objekt schreiben oder was auch immer du im Anschluß nach dem Bearbeiten mit den Bild machen willst.
Michael
Hallo Nall chan.
Danke für deine Informationen.
Das Script dass ich oben gepostet habe ist die „zusammengeschrumpfte“ Version aus meinem Test-Pi V4.0 um den Fehler wiederholbar vorführen zu konnen.
Das ich ein Bild vor dem Aufruf des Grabbers lösche ist wohl vom experimentieren stehen geblieben.
Läuft fehlerfrei, also habe ich mir keine weiteren Gedanken darüber gemacht.
Aber du hast Recht, das macht keinen Sinn. Kommt weg.
Aber da sich der Ablauf in der V4.0 gerade durch das „im RAM gehaltene Bild“ geändert hat, wollte ich hier halt NUR mal eben anpassen.
Mir wäre es wichtig, dass das eigendliche Ziel
- den ImageCreateFromXxxx Fehler zu lokalisieren -
nicht aus dem Focus gerät.
Auch wenn paresy im Moment sicher größere Sorgen (V4.0) hat.
Gruß
lueralba