Plaatjes in db, jpg-thumbmail maken met zelfde kwaliteit

[SvMp]

Bij een systeem dat ik bouw (FreeBSD/Apache/PHP/MySQL) is het mogelijk om plaatjes op te slaan bij bepaalde gegevens. Om bandbreedte te besparen wil ik dat in overzichtslijsten e.d. alleen een klein plaatje te zien is. De gebruikter moet klikken om een groot plaatje te zien.

Het grote plaatje is het opgeslagen origineel. Uploaden, opslaan en resizen is geen probleem, ik weet hoe dat met PHP. Als ik upload, maak ik dat mijn script zelf een klein plaatje maakt en bewaart. Echter ik loop er tegenaan dat het kleine plaatje een slechte kwaliteit heeft. Een JPG is al minder als er sterk gecomprimeerd is, maar als ik het plaatje verklein en een nieuwe JPG-wegschrijf wordt de kwaliteit nog beroerder. Het beste resultaat bereik ik als ik met dezelfde kwaliteitsfactor opsla als het origineel heeft. Maar hoe kan mijn script weten met welke kwaliteitsfector het origineel is opgeslagen?

Hoe los ik dit op? Hoe maak ik fatsoenlijke kleine plaatjes zonder dat ik genoodzaakt ben geen compressie te gebruiken?

[Verwijderd]

Wat voor functies gebruik je om de kleine images te maken?

Je krijgt in ieder geval beter resultaat als je imagecreatetruecolor() gebruikt maar dan moet je wel GD2.0 minimaal hebben.

[Verwijderd]

Voor zover ik weet wordt er nergens in de JPEG header bijgehouden wat de kwaliteit van de afbeelding is...

[Verwijderd]

ik snap niet echt wat je probleem is maar meschien loop je hier tegenaan.

int imagejpeg ( resource image [, string filename [, int quality]])

quality is optional, and ranges from 0 (worst quality, smaller file) to 100 (best quality, biggest file). The default is the default IJG quality value (about 75).

stel je krijgt een 800x600 jpeg die 20% ge comprimeert is.
en daarna ga jij er een thumb van maken zonder dat je quality mee geeft.
dan zal hij hem nog eens gaan comprimeren.

maar zelf heb ik er nog nooit rekening mee gehouden en ook nog nooit problemen mee gehad.

wat een andere mogelijkheid is dat je imagecreate gebruikt inplaats van imagecreatetruecolor.
wat je plaatjes iid enorm brak maakt

[SvMp]

Verwijderd schreef op 06 maart 2004 @ 17:39:
ik snap niet echt wat je probleem is maar meschien loop je hier tegenaan.


[...]


stel je krijgt een 800x600 jpeg die 20% ge comprimeert is.
en daarna ga jij er een thumb van maken zonder dat je quality mee geeft.
dan zal hij hem nog eens gaan comprimeren.

Je verwoordt mijn probleem al deels zelf..

Stel je hebt een jpeg 800x600 die 20% gecomprimeerd is.
Voordat je gaat resizen, laad je het plaatje en zet je deze ongecomprimeerd in het geheugen. Echter, omdat jpeg lossy compressie is, blijft het kwaliteitsverlies van die compressie (in dit voorbeeld 20%) aanwezig!

Als ik nou de image bewaar en de kwaliteit van de oorspronkelijke 800x600 20% compressie wil behouden, moet ik niet comprimeren, maar dan is het gebruik van thumbnails niet meer de moeitewaard (te groot en mijn reden was juist beparen bandbreedte).
Dus ik ga die verkleinde versie comprimeren, stel ook met 20%. Maar het plaatje met al een kwaliteitsverlies door compressie van origineel verliest opnieuw kwaliteit. Door namelijk twee keer een compressie heeft plaats gevonden: Bij degene die het origineel heeft gemaakt en mijn thumbnail functie. Dus 2x 20% verlaging kwaliteit. Hiervoor zoek ik een oplossing.

[Verwijderd]

de compressie van jpeg is er op gebaseerd dat het bestand zo aangepast word dat het kleiner is op te slaan in een jpeg formaat.

het is zover ik weet niet mogelijk om te zien hoe veel compressie is toe gepast op het orgineele plaatje.

wat je mogelijk wel zou kunnen doen, is controleren op grote.
ik heb even gekeken.
een plaatje met de dimensie van 250x250 met 0 compressie was ~50kb
zo'n zelvde plaatje met een 20% compressie was 9KB
een plaatje met 50% compressie was 4.9KB


daarna heb ik er tumbs van gemaakt met een dimensie van 100x100
(voor het gemakt even met convert van ImageMagick en niet via php+gdlib allen met een 20% compressie)

alledrie de plaatjes waren 1.9kb en hadden de zelvde kwaliteit (qua blote oog)
(gedaan via convert blaat.jpg -scale 100 th_blaat.jpg )
ik ga nu even snel een php scriptje in elkaar zetten om via gdlib de thumbs te maken.
dus zometeen even een edit van deze post.

-edit-

via phpgdlib er nu tumbs van gemaakt.
maar resultaat is toch echt nagenoeg hetzelvde.

ik vraag me dan ook af, over welke dimensies de TS het heeft.
(conversie van wat naar wat)
en wat voor code hij hiervoor gebruikt.

[ Voor 12% gewijzigd door Verwijderd op 06-03-2004 19:32 ]

[SvMp]

Er is nog geen code. Ik kwam dit probleem tegen bij brainstormen hoe ik dit moest hebben: Leveren thumbnails voldoende besparing van bandbreedte op om het gebruikt te rechtvaardigen t.o.v. helemaal geen voor-vertoningen?

Grafisch voorbeeld. Ik ga er vanuit dat mijn voor-vertoningen op de x-as 300 pixels zijn en op de y-as variabel afhankelijk van de verhoudingen in het plaatje. Als experiment heb ik een plaatje genomen, thumbnail gemaakt en gekeken hoe deze er uit ziet bij een kwaliteit van 100, 70 en 50. Programma: De Gimp.

Origineel:


Voor-vertoning, kwaliteit 100:

Deze is qua wat je ziet kwalitatief gelijk aan het origineel. Echter door geen compressie te gebruiken, is het plaatje maar liefst 59 kb, zelfs groter dan het origineel van 54 kb. Met deze kwaliteit is het gebruik van voor-vertoningen om bandbreedte te besparen onzinnig.

Voor-vertoning, kwaliteit 70:

Met 13 kb een stuk kleiner. Maar zelfs met deze relatief hoge kwaliteit zie je het plaatje al hard achteruitgaan (dakpannen). Terwijl het origineel waarschijnlijk een hogere compressie had..

Voor-vertoning, kwaliteit 50:

Qua grootte (10 kb) de moeite waard, kwalitatief stukken minder (structuur muren en dakpannen). Als ik nog verder naar beneden ga wordt het een ramp.


Vervolg-proef: Ik sta het originele plaatje opnieuw op (schrijf dus nieuwe jpeg!!) met een kwaliteit van 100. Het bestand is 2x zo groot als het origineel. Dit wijst er op dat het origineel een kwaliteit van 50 had.

Eigenlijk zou mijn voorvertoning met een kwaliteit van 50 voor het oog gelijkwaardig moeten zijn aan het origineel, maar nee, het ziet er stukken beroerd uit.
Is hier een oplossing voor? Ik ben bang van niet.

[ Voor 4% gewijzigd door SvMp op 07-03-2004 00:53 ]