[PHP] Corrupted image resize

[Gersomvg]

Beste mede-tweakers,

Na flink wat onderzoek en testen heb ik geen oplossing kunnen vinden hoe ik afbeeldingen op corruptheid kan controleren voordat ik ze probeer te verkleinen (met PHP GD) met alle errors van dien.

In eerste instantie vond ik de volgende 2 oplossingen:

1) Kijk wat de functie getimagesize() voor output geeft.
Daar heb ik naar gekeken alleen retourneerd de functie zelfs bij een corrupte afbeelding nog alle waarden in de array.

Array ( [0] => 538968409 [1] => 538968323 [2] => 3 [3] => width="538968409" height="538968323" [bits] => 8 [mime] => image/png ) 

Misschien dat dit alleen het geval is wanneer de header-info niet te ernstig beschadigd is maar er zijn in ieder geval genoeg corrupte gevallen die dus niet te signaleren zijn a.d.h.v. deze functie.

2) Gebruik phpThumb
Die doet resizen on the fly, hetzij dan misschien wel met cache maar ik doe niet alleen resizen voor het dataverkeer en de laadsnelheid van een pagina maar ook omdat ik m'n webruimte-gebruik een beetje binnen de perken wil houden. Voor zover ik weet doet phpThumb niet resizen bij upload en dan de onge-resize-de verwijderen. En sowieso.. ik heb inmiddels mijn eigen resizescript aardig uitgebouwd zodat hij zelfs PNG met transparantie kan verkleinden e.d. en wil mijn eigen script dus heel graag blijven gebruiken.

Beide oplossingen gaan (voor mij) dus niet op.
Zijn er mensen die mij hier meer over kunnen vertellen en tips over kunnen geven?

[DexterDee]

Ik trap misschien een open deur in hoor, maar als je een width van 538968409 terug krijgt dan kun je er gevoegelijk vanuit gaan dat het betreffende bestand corrupt is. Het lijkt me nuttig om een redelijk maximum aan te houden.

Verder is het natuurlijk zo dat het altijd zo kan zijn dat de header intact lijkt maar verkeerde waarden toont. Dat zal geen enkele validator kunnen checken. Het is erg moeilijk voor een computer om te kijken of een plaatje corrupt is, omdat de computer het plaatje niet begrijpend kan bekijken. Er kan bijvoorbeeld een gezicht van een persoon opstaan die halverwege in ruis verandert omdat het bestand op die plaats corrupt is. Een mens ziet dat in 1 ogenblik, maar een machine heeft daar vreselijk veel moeite mee.

[Gersomvg]

Oke, maar phpThumb schijnt in staat te zijn om afbeeldingen die zo corrupt zijn dat ze niet geresized kunnen worden er van tevoren uit te pikken.. Heb al wat rondgekeken in die broncode maar geeft me een beetje het gevoel van zoeken naar een naald in een hooiberg
Als een afbeelding lelijk wordt is dat gewoon de pech van de uploader.. maar ik wil geen errors tijdens het resizen. Als er geen thumb wordt gemaakt heeft dat echt invloed op het functioneren van de website..

edit: Weet trouwens niet of die width en height bij corrupte afbeeldingen altijd zo absurd hoog is.. had gewoon ff een JPEG in kladblok geopend en wat tekens weggehaald

[ Voor 14% gewijzigd door Gersomvg op 21-07-2009 18:11 ]

[Bjornski]

Om hem te resizen zul je er eerst een GD image van moeten maken.
Op het moment dat ImageCreateFrom<iets> geen image resource teruggeeft is hij dus ook niet te resizen (logisch toch?). Dit is hoe vrijwel alle galleries etc... dit doen in PHP volgens mij.

ImageCreateFrom<iets> geeft geen foutmeldingen terug. Daarna iets doen met een lege image resource wel.

Hier staat een goed voorbeeld.

Daarnaast is controleren op een voorgedefinieerde minimum en maximum grootte een altijd goed actie natuurlijk.

[Gersomvg]

Bjornski schreef op dinsdag 21 juli 2009 @ 18:16:
Hier staat een goed voorbeeld.

Jep.. inderdaad

Example #1 Example to handle an error during loading of a JPEG

Bjornski schreef op dinsdag 21 juli 2009 @ 18:16:
Daarnaast is controleren op een voorgedefinieerde minimum en maximum grootte een altijd goed actie natuurlijk.

Je bedoelt maxbreedte en maxhoogte? Zeg maar zoiets van $maxwidth = 5000;?

[ Voor 81% gewijzigd door Gersomvg op 21-07-2009 18:31 ]

[Bjornski]

Bijvoorbeeld. Meer dan 5000 pixels zal het echt niet snel worden.

[Gersomvg]

oke.. maar denk dat die controle geeneens nodig is Zal hem er voor de zekerheid bijstoppen maar heb het nu met imagecreatefromjpeg al gefixt Zover ik weet heb ik nu een tamelijk waterdicht resize scriptje

* Gersomvg Is wederom verbaasd hoe simpel / voor de hand liggend sommige oplossingen zijn

[ Voor 19% gewijzigd door Gersomvg op 21-07-2009 19:06 ]

[Patriot]

Misschien snap ik het niet helemaal hoor, maar als die functies foutmeldingen geven dan kun je die toch gewoon opvangen? Dat vind ik een nettere oplossing dan alle afbeeldingen die breder/hoger dan 5k pixels als corrupt te beschouwen.

[Gomez12]

Patriot schreef op dinsdag 21 juli 2009 @ 23:40:
Misschien snap ik het niet helemaal hoor, maar als die functies foutmeldingen geven dan kun je die toch gewoon opvangen? Dat vind ik een nettere oplossing dan alle afbeeldingen die breder/hoger dan 5k pixels als corrupt te beschouwen.

Tja, hangt er maar net vanaf wat je als corrupte image beschouwd...
Een image met 500.000 pixels hoeft niet corrupt te zijn ( in theorie dan. NASA heeft er een paar dacht ik ) maar levert waarschijnlijk wel een foutmelding op met out of memory op het moment dat je gd eroverheen laat gaan...

Ergens moet je een grens leggen. Een corrupt plaatje hoeft geen foutmelding te veroorzaken ( 500.000 pixels breed, 1 pixel hoog zal waarschijnlijk geen foutmelding genereren ) maar is toch altijd ongewenst.

Bij plaatjes hanteer ik liever randvoorwaarden ( het moet kleiner dan 5k pixels hoog/breed zijn ) dan foutmeldingen, een zwart vlak van 10.000 bij 10.000 hoeft geen foutmelding te veroorzaken, toch is het raar / corrupt.

[Patriot]

Gomez12 schreef op woensdag 22 juli 2009 @ 01:15:
[...]

Tja, hangt er maar net vanaf wat je als corrupte image beschouwd...
Een image met 500.000 pixels hoeft niet corrupt te zijn ( in theorie dan. NASA heeft er een paar dacht ik ) maar levert waarschijnlijk wel een foutmelding op met out of memory op het moment dat je gd eroverheen laat gaan...

Ergens moet je een grens leggen. Een corrupt plaatje hoeft geen foutmelding te veroorzaken ( 500.000 pixels breed, 1 pixel hoog zal waarschijnlijk geen foutmelding genereren ) maar is toch altijd ongewenst.

Bij plaatjes hanteer ik liever randvoorwaarden ( het moet kleiner dan 5k pixels hoog/breed zijn ) dan foutmeldingen, een zwart vlak van 10.000 bij 10.000 hoeft geen foutmelding te veroorzaken, toch is het raar / corrupt.

Mijn punt is toch juist dat het kan zonder randvoorwaarden en zonder foutmeldingen. Die randvoorwaarden zijn gewoon nergens voor nodig, juist omdat GD een fout geeft bij die corrupte bestanden. Als dat gebeurt weet je dus dat het plaatje corrupt is en kun je gewoon hetzelfde doen wat jij doet op het moment dat die randvoorwaarden worden overschreden.

[Gomez12]

Patriot schreef op woensdag 22 juli 2009 @ 01:46:
[...]


Mijn punt is toch juist dat het kan zonder randvoorwaarden en zonder foutmeldingen. Die randvoorwaarden zijn gewoon nergens voor nodig, juist omdat GD een fout geeft bij die corrupte bestanden. Als dat gebeurt weet je dus dat het plaatje corrupt is en kun je gewoon hetzelfde doen wat jij doet op het moment dat die randvoorwaarden worden overschreden.

Nope, niet elke foutmelding is een corrupt plaatje ( zie out of memory ) en niet elk corrupt plaatje geeft een foutmelding ( ik verwacht icoontjes van 16x16, ik krijg een goed plaatje van 160x1.6)

Vaak genoeg gezien dat mensen een corrupt plaatje in programma x/y geopend en opgeslagen krijgen, deze schrijft de headers opnieuw waardoor het plaatje volgens de regelen der kunst weer goed is, het is niet corrupt meer, maar toch voldoet het niet meer aan de randvoorwaarden.

[Patriot]

Ten eerste vind ik je claim dat je een plaatje hebt gehad met een fractie van een pixel een beetje dubieus (of moesten die getallen geen pixels voorstellen?). Ten tweede is een foutmelding wel een garantie dat er iets mis is, dat is dus sowieso iets wat je wilt afvangen.

Verder kun je ook niet garanderen dat een corrupt plaatje altijd buiten de randvoorwaarden valt. Wat je met die randvoorwaarden dus effectief bereikt is dat je een deel van de corrupte bestanden buitensluit, maar nog belangrijker: ook een deel van de niet-corrupte bestanden.

De TS geeft aan dat hij GD gebruikt. Die geeft bij mij een foutmelding bij een corrupt bestand (of de headers nou goed zijn of niet). Van die foutmelding kun je gebruik maken, het is niet nodig om randvoorwaarden op te stellen om corrupte afbeeldingen eruit te pikken.

[Gersomvg]

Ik genk dat jullie Bjornski's punt even hebben gemist

ImageCreateFrom<iets> geeft geen foutmeldingen terug. Daarna iets doen met een lege image resource wel.

Die kun je dus als true/false returnende functie gebruiken.. Die haalt vast niet alle corrupte images eruit maar wel de images die een probleem vormen voor het resize-script.

Dat met die pixels is gewoon een extra manier

[ Voor 6% gewijzigd door Gersomvg op 22-07-2009 08:48 ]