[PHP] Image compressing (database)

[Verwijderd]

Hoi allemaal,

Ik ben van plan afbeeldingen op te gaan slaan in een database (niet moeilijk doen met locatie en verwijderen, en handig te groeperen en doorzoekbaar maken etc.), en omdat ik met webspace aan een limiet zit, wil ik deze data zo veel mogenlijk comprimeren...

Het gaat in de meeste gevallen om jpeg plaatjes, maar dit kunnen theoretisch ook andere soorten plaatjes zijn.

Nu heb ik wat gezocht op php.net, en daar kwam ik base64_encode en gzencode tegen. De beschijving van base64 leek me wel handig, tot 33% minder ruimte! Ik gelijk uitproberen, maar de data bleek alleen groter te worden?? Daarna gzencode geprobeert, maar dan bleef de grootte gelijk (bestand van 400kb). Vervolgens heb ik gzencode op een psd van 10mb losgelaten, en hier kwam deze wel goed uit de bus: 50% eraf!

Maar het komt natuurlijk niet vaak voor dat mensen afbeeldingen van 10 mb gaan uploaden, dus ik zoek eigenlijk een compressie die ook relatief kleine (tot 500kb) bestanden goed kan comprimeren.

PHP versie: 4.x (nog onbekend)
Geen toegang tot server, alleen webspace.
Afbeeldingen worden gelezen via fopen & fread.

[sjroorda]

De beste methode is en blijft het opslaan van een locatie in de db en de afbeelding zelf op de hd zetten: scheelt een hoop in snelheid en grootte van de db.

Als je dit dat toch per se wil doen: sla het gewoon op zoals je het binnenkrijgt: veel compressie is er bij JPG-files toch niet meer te halen (wel eens geprobeerd een JPG te zippen? scheelt niet veel!).

En dat base-64 niet werkt is logisch: deze codering (geen compressie) zorgt ervoor dat binaire data 'niet binair' wordt doorgestuurd, zodat het door elk systeem kan worden gelezen (vnl. mailprogs).

edit:
Zie http://nl.php.net/manual/en/function.base64-encode.php - en dan vooral de opmerking direct boven het voorbeeld

[ Voor 32% gewijzigd door sjroorda op 15-08-2004 14:45 ]

[Verwijderd]

Denk even na over compressie. Als je jpeg of gif afbeeldingen zou kunnen comprimeren met een lossless compressiemethode, dan zou dat allang gebeuren. Je kunt altijd lossy compressie methoden gebruiken, alleen lever je dan in op kwaliteit.

Ik kan je al vertellen dat dit met webformaten geen enkele zin heeft. Wat wel zinvol kan zijn is compressie toepassen op .psd, .eps en .tiff bestanden, alhoewel .eps en .tiff bestanden al gecomprimeerde data kunnen bevatten.

Uiteraard levert base64 encoding totaal geen winst op, en zelfs verlies, omdat er meer bytes nodig zijn om gegevens op te slaan, omdat bepaalde delen uit de tekensets niet worden gebruikt.

[NMe]

Ik vraag me af hoe TS erbij komt dat compressie gelijk staat aan encoding.

Bovendien is het file system nog steeds een fijnere plaats om files op te slaan. Daar heet het filesystem voor!

[Verwijderd]

Hmm ok, maar ik kan ze dus ook gz-compressed opslaan in het filesysteem, want gz werkt bij bestanden boven de 500kb wel redelijk.

En het was inderdaad dom om te denken dat encoding hetzelfde resultaat zou hebben als compressing .

[gorgi_19]

NMe84 schreef op 15 augustus 2004 @ 14:49:
Bovendien is het file system nog steeds een fijnere plaats om files op te slaan. Daar heet het filesystem voor!

Hoewel aanverwandt, is dit al genoeg reden voor een eigen discussie. Zie bijvoorbeeld [rml]crisp in "[ PHP / GD Library] Image uit DB resizen?"[/rml] voor deze discussie. Mocht je hier verder op in willen gaan, dan graag daar; dan kan die discussie afgesplitst worden
Deze discussie kan dan 'zuiver' blijven over de compressie

[NMe]

Verwijderd schreef op 15 augustus 2004 @ 14:53:
Hmm ok, maar ik kan ze dus ook gz-compressed opslaan in het filesysteem, want gz werkt bij bestanden boven de 500kb wel redelijk.

Compression heeft, zoals Cheetah al zei, weinig tot geen nut voor jpeg plaatjes. Het lijkt me de moeite van het schrijven van het script niet waard. Als je een jpeg plaatje zipt, dan blijft ie meestal nog 99% van de grootte die het voor compressie had.

[Verwijderd]

NMe84 schreef op 15 augustus 2004 @ 14:59:
[...]

Compression heeft, zoals Cheetah al zei, weinig tot geen nut voor jpeg plaatjes. Het lijkt me de moeite van het schrijven van het script niet waard. Als je een jpeg plaatje zipt, dan blijft ie meestal nog 99% van de grootte die het voor compressie had.

Maar het scheelt wel enkele 10-tallen kB's, en zo'n scriptje kan binnen 1 kB, dus het scheelt bij veel plaatjes toch wel wat...en met een limit aan ruimte is elke kB meegenomen, toch ?

[Zoijar]

Eigenlijk is het wel vreemd dat als je een jpeg zipped het bijna altijd zo'n 10k kleiner wordt. Vaak ga je wel van 50k naar 40k ofzo, dat is een extra compressie van 20% !! Misschien kan je ook je plaatjes converteren naar jpeg2000, die zou het wel beter moeten doen... Wat is jpeg eigenlijk een troep dan

[Verwijderd]

Je wint ruimte, maar je wint helemaal niets met dataverkeer, en je verspilt processor-kracht. Mijn ervaring is dat bij jpeg files op een webserver, de ruimte nooit echt een probleem is. Tenzij je een of ander slecht afgewogen hostingpakket hebt natuurlijk.

Zoijar schreef op 15 augustus 2004 @ 15:13:
Eigenlijk is het wel vreemd dat als je een jpeg zipped het bijna altijd zo'n 10k kleiner wordt. Vaak ga je wel van 50k naar 40k ofzo, dat is een extra compressie van 20% !! Misschien kan je ook je plaatjes converteren naar jpeg2000, die zou het wel beter moeten doen... Wat is jpeg eigenlijk een troep dan

Het zou dan weer beter moeten werken als je de troep gezipt of op andere wijze in gecomprimeerde vorm kunt aanbieden, waardoor de server het alleen hoef door te geven, en niet eerst te decomprimeren. Maar denk even aan hoe een user agent dan moet weten wat de grootte is van een afbeelding zodat die user agent vlot ruimte kan reserveren. En denk even aan progressive scan en dergelijke technieken.

[ Voor 64% gewijzigd door Verwijderd op 15-08-2004 15:19 ]

[CyBeR]

Verwijderd schreef op 15 augustus 2004 @ 14:38:

Nu heb ik wat gezocht op php.net, en daar kwam ik base64_encode en gzencode tegen. De beschijving van base64 leek me wel handig, tot 33% minder ruimte!

Waarschijnlijk heb je verkeerd gelezen: BASE64 zorgt voor ongeveer 30% meer data Dit omdat 't geen compressie is maar een manier om binaire data te coderen als ASCII.

[Zoijar]

Verwijderd schreef op 15 augustus 2004 @ 15:15:
Het zou dan weer beter moeten werken als je de troep gezipt of op andere wijze in gecomprimeerde vorm kunt aanbieden, waardoor de server het alleen hoef door te geven, en niet eerst te decomprimeren. Maar denk even aan hoe een user agent dan moet weten wat de grootte is van een afbeelding zodat die user agent vlot ruimte kan reserveren. En denk even aan progressive scan en dergelijke technieken.

Je zou een eigen formaat kunnen ontwikkelen gebasseerd op zipped wavelet levels, dan kan je progressief je plaatjes ophalen, en de gebruiker kan op elk plaatje aanklikken "more detail". Vaak hoef je een plaatje toch niet op vol detail te zien. Zo'n formaat zou gigantisch band breedte besparen over de hele wereld. Maar dan moet het wel standaard door je browser worden ondersteunt. Of een dcom object oid.

Maar ik ben het met je eens dat het niet de moeite is om te zippen hoor Kost veel processor kracht idd, en disk ruimte is zo goedkoop...Stel dat je van 100GB naar 80GB gaat...big deal.

Voor TS: base64 encoding betekent alleen maar dat er ipv van base256 (bytes hebben 256 mogelijke waardes) er maar 64 waardes gebruikt gaan worden, en wel de 64 "safe" characters die door elke server normaal/goed door gestuurd kunnen worden. Natuurlijk kost dat wat extra ruimte, want voor sommige bytes heb je nu ineens meerdere bytes nodig.

[ Voor 15% gewijzigd door Zoijar op 15-08-2004 15:27 ]

[Verwijderd]

Zoijar schreef op 15 augustus 2004 @ 15:23:

Je zou een eigen formaat kunnen ontwikkelen gebasseerd op zipped wavelet levels, dan kan je progressief je plaatjes ophalen, en de gebruiker kan op elk plaatje aanklikken "more detail". Vaak hoef je een plaatje toch niet op vol detail te zien. Zo'n formaat zou gigantisch band breedte besparen over de hele wereld. Maar dan moet het wel standaard door je browser worden ondersteunt. Of een dcom object oid.

En daar heb je de kern van het 'probleem'. JPEG en GIF89a zijn standaarden, PNG is een nog niet compleet ondersteunde standaard. Waarom zou een nieuwe standaard wel beter worden ondersteund, in een tijd dat de beschikbare bandbreedte op het internet explosief groeit, de opslagcapaciteit van harddisks enorm toeneemt, en processors ook maar sneller en sneller worden. Dan kun je tijd en moeite gaan investeren in een nieuwe standaard, alleen je haalt je dan enorm veel op de hals. Je zit met patenten waar je alles over moet gaan uitzoeken, en dat maakt de zaak alweer relatief 'gevaarlijk'. Waarom moeite doen in een tijd van overvloed, zeker als het gaat om iets als het serveren van een paar plaatjes.

[Zoijar]

Ik geef je ook helemaal gelijk dat het niet nodig is Het was zo maar een idee. Omzetten naar jpeg2000 zou wel een idee zijn, dat wordt waarschijnlijk ook kleiner, en is al een standaard.

[Verwijderd]

Als mensen afbeeldingen uploaden in gecomprimeerd formaat moet je er helemaal niets meer aan doen, want als je gaat converteren naar een ander lossy formaat, raak je altijd kwaliteit kwijt.
Als je echter zelf volledige controle hebt over de afbeeldingen die op de server komen, en beschikt over HQ bestanden, dan kun je het best zelf goed comprimeren naar een acceptabel formaat/kwaliteit.

[Verwijderd]

Bedankt allemaal, ik denk dat ik afstap van het compressie gebeuren, en de lokatie van de afbeeldingen met een beschrijving in de database ga zetten, lijkt me wel de beste oplossing .