[img] height= en width =

[BasieP]

naar aanleiding van dit topic:
Alienware lanceert Predator Case.

wilde ik het even hebben over de leuke functie om plaatjes te resizen op GoT

dit gaat door

code:

[img height=20 width=20]http://www.bla.com/bla.jpg[/img]

te gebruiken.

erg handig MAAR!

nou kom ik met 56kb/s een topic binnengekropen, en zie dat er plaatjes staan. ik ben erg nieuwsgierig, en dus wil ik ze zien.

niet de 2000x1000 pixel versie, maar toch even een klein plaatje om te zien waar het topic over gaat.

nou denk je: goh die resize is een mooi idee van got/parse, dat scheeld weer in dataverkeer.
kan de modemer ook plaatjes kijken...

nou niet dus..

in plaats van dat er nou dmv php een functie gebakken wordt die het plaatje inleest, resized, en dan in klein formaat in het topic plaatst moet je alsnog de hele 2000x1000 pixels gaan downloaden om een plaatje van 100x50 te bekijken...

kan hier niet iets aan gedaan worden?
of kan users niet dmv de allmighty [FAQ]FAQ[/FAQ] duidelijk gemaakt worden dat men _{_KLEINE!_} fototjes moet plaatsen in een topic, en alleen naar GROTE plaatjes mag linken?

[Erkens]

mja in de grote topics waar veel images worden gepost staat het er altijd wel bij

[Azrael]

Ja het is sowieso irri dat mensen plaatjes van 1200x1600 plaatsen en dan resizen maar die oplossing van jou werkt ook niet want dan moeten al die plaatjes op een t.net server opgeslagen worden.

[DaRuLe]

PHP kan prima on demand thumbnails creëren, maar ik ben bang dat de serverload dan een beetje hoog gaat worden met zoveel gebruikers.

Commentaar van een echte parse devver is natuurlijk gewenscht alhier

[ Voor 27% gewijzigd door DaRuLe op 20-01-2003 20:50 ]

[Harm]

Azrael schreef op 20 January 2003 @ 20:47:
Ja het is sowieso irri dat mensen plaatjes van 1200x1600 plaatsen en dan resizen maar die oplossing van jou werkt ook niet want dan moeten al die plaatjes op een t.net server opgeslagen worden.

Dat niet, maar ze moeten wel via de Tweakers.net servers omdat die nog even het plaatje moeten verkleinen en dan dus weer weg moeten sturen. Dit veroorzaakt 1. veel extra dataverkeer en 2. een hogere serverload. In beide zaken zullen de serveradmins geen zin hebben lijkt me.

[Wouter Tinus]

Wat je voorstelt is theoretisch wel mogelijk maar praktisch niet haalbaar. Ik zie het nut er ook niet van in om voor iedere ergernis die veroorzaakt wordt door lakse mensen een softwarefeature te bouwen. Je kunt toch nooit software krijgen die van een lui persoon een modelposter maakt. Laatst ook al iemand die een limiet wilde van het aantal smilies dat in een post mag staan. Soms moet je gewoon oorzaken in plaats van gevolgen aanpakken.

[DarkX]

Mja, kunnen mensen idd goed zelf oplossen. Ik gebruik die resize functie (die trouwens veel korter kan met [img=100,100] dachtik) alleen als plaatjes te groot zijn om in de layout te plakken, maar niet TE groot. Wanneer ik echt hires shit post maak ik gewoon ff een thumbnailtje die wat kleiner is.

[NitroX infinity]

BasieP, mag ik aannemen dat je Internet Explorer gebruikt?
Extra -> Internet Opties -> tabblad Geavanceerd.
Daar staat een leuke optie waarbij je kunt wijzigen of plaatjes worden gedownload/weergegeven.

En als je ziet dat er plaatjes in een topic staan en je weet dat je een 56k modem hebt en je ziet dat de plaatjes langzaam laden, ga dan niet zeuren dat 't te lang duurt. Ga dan ff naar de plee ofzo.
Je hebt een 56k en je weet dat 't langzaam is. Je kunt niet verwachten dat het internet aangepast word aan jouw situatie.

[Cubix]

Zou een mooie functie zijn voor een browser; geen zaken automatisch downloaden die groter zijn dan aangegeven door de gebruiker. En dan een soort knop ipv het plaatje als je die toch wilt zien.

[BasieP]

NitroX_infinity schreef op 20 January 2003 @ 21:31:
BasieP, mag ik aannemen dat je Internet Explorer gebruikt?
Extra -> Internet Opties -> tabblad Geavanceerd.
Daar staat een leuke optie waarbij je kunt wijzigen of plaatjes worden gedownload/weergegeven.

En als je ziet dat er plaatjes in een topic staan en je weet dat je een 56k modem hebt en je ziet dat de plaatjes langzaam laden, ga dan niet zeuren dat 't te lang duurt. Ga dan ff naar de plee ofzo.
Je hebt een 56k en je weet dat 't langzaam is. Je kunt niet verwachten dat het internet aangepast word aan jouw situatie.

*zucht*
ik geloof dat jij het verhaal niet heb begrepen..
ga het niet nog een keer uitleggen ook. deze in mijn ogen nogal aanvallende houding is nergens voornodig.
ik deed een simpele request, en wilde daar serieus over praten.


verder vind ik idd dat de problemen goed verholpen kunnen worden als users zich gewoon iets socialer opstellen.
(onder het motto: normen en waarden )

helaas vatten de meeste users het slecht op als ze commentaar krijgen mbt hun post.

't zou een stuk helpen wanneer er stukje van in de faq komt..
hoewel ik dan alsnog denk dat het niet veel zal helpen

[Erkens]

BasieP schreef op 20 januari 2003 @ 22:02:
[...]


*zucht*
ik geloof dat jij het verhaal niet heb begrepen..
ga het niet nog een keer uitleggen ook. deze in mijn ogen nogal aanvallende houding is nergens voornodig.
ik deed een simpele request, en wilde daar serieus over praten.
[knip]
helaas vatten de meeste users het slecht op als ze commentaar krijgen mbt hun post.

lol @ jouw post

't zou een stuk helpen wanneer er stukje van in de faq komt..
hoewel ik dan alsnog denk dat het niet veel zal helpen

stel dat dit in een faq komt wordt het toch niet gelezen.
want er staat namelijk ook in de faq dat je eerst moet zoeken voordat je een topic opent, en dat zie ik hier niet
Dit is namelijk ook al een paar keer langsgekomen

[DinX]

Erkens schreef op 21 januari 2003 @ 07:34:
[...]

lol @ jouw post


[...]

stel dat dit in een faq komt wordt het toch niet gelezen.
want er staat namelijk ook in de faq dat je eerst moet zoeken voordat je een topic opent, en dat zie ik hier niet
Dit is namelijk ook al een paar keer langsgekomen

Kunnen de modjes de foto's gewoon uit de post halen met een melden dat ze geresized moeten worden ofzo. Met dan een verwijzing naar de faq. Zoveel gebeurt het nu ook weer niet dat ze echt associaal zijn met de pics.

[Basszje]

Tja je kan idd die plaatjes wel parsen met PHP, maar dan wil ik de load idd niet weten

Schop de user in kwestie zou ik zeggen, jij bent degene die het het snelst merkt

[Pelle]

BasieP: Kom op zeg.. ik weet niet of je ooit wel eens iets GDlib achtig iets gebouwd hebt, maar je wilt niet weten wat een load dat trekt als je met grotere images aan de slag gaat. Daarnaast is het ook nog eens zo dat het extra veel traffic op zou leveren, aangezien de t.net webserver eerst die image van de remote host moet trekken, daarna aanpassen, en vervolgens weer terugsturen naar de client.
Denk dat dit hele proces langer gaat duren dan dat jij de volledig versie binnen moet trekken met je 56k.

[Verwijderd]

Je kan toch ook de verkleinde plaatjes cachen, die cache leeg je na een tijdje weer. De load blijft normaal (een (1) keertje resizen per plaatje (meestal)) en de harddisk blijft ook relatief leeg (want van oude --niet meer opgevraagde-- topics wordt het verkleinde plaatje verwijderd).

Geen goed idee?

[sewer]

Tja, ik ben het wel een beetje met Wouter eens dat de oplossing niet in de software gezocht moet worden. Maar van de andere kant worden mensen wel vaker geconfronteerd met layoutverneukende of onnodig grote (zowel in pixels maar ook in kB omdat iemand bijv. bmp's post) zonder dat je je dat voor het klikken op het topic kon weten.

Dat sizen zal wel veel te veel traffic veroorzaken, maar is het niet een optie om aan te kunnen geven dat layoutverneukende plaatjes of plaatjes boven een aantal KB's geweerd worden bij het ophalen van de pagina, en bijv. als links worden weergegeven ofzo?

[ Voor 4% gewijzigd door sewer op 21-01-2003 18:26 ]

[Harm]

sewer schreef op 21 januari 2003 @ 18:25:
Tja, ik ben het wel een beetje met Wouter eens dat de oplossing niet in de software gezocht moet worden. Maar van de andere kant worden mensen wel vaker geconfronteerd met layoutverneukende of onnodig grote (zowel in pixels maar ook in kB omdat iemand bijv. bmp's post) zonder dat je je dat voor het klikken op het topic kon weten.

Dat sizen zal wel veel te veel traffic veroorzaken, maar is het niet een optie om aan te kunnen geven dat layoutverneukende plaatjes of plaatjes boven een aantal KB's geweerd worden bij het ophalen van de pagina, en bijv. als links worden weergegeven ofzo?

Dat laatste is misschien wel een mogelijkheid, maar dat kost weer traffic omdat (in ieder geval een klein gedeelte van het plaatje opgehaald moet worden van de locatie) het plaatje gechecked moet worden; wat ook weer extra serverload kost.
Het eenvoudigste is om de gebruikers duidelijk te maken dat plaatjes niet te groot moeten zijn. (Volgens mij komt het ook niet heel vaak voor dat er bitmaps gepost worden trouwens.) Dat kan door een stukje in een FAQ, maar ook door een gebruiker even aan te schieten. Beide opties kosten minder geld en moeite dan serverside oplossingen en zijn dus stukken makkelijker te implementeren.

[Resistor]

Wat is eigenlijk de ideale maat hier?

De meeste plaatjes die ik heb zijn 640x480 (foto's, geen plaatjes die ik ergens anders vandaan haal)
Die steken net iets uit de layout, 600x400 niet, maar dat is niet echt een standaardmaat voor plaatjes.

Kan de layout niet aangepast worden aan 640x480 plaatjes? Ik zit nu momenteel achter een 800x600 monitor, en ik zie nog witte randjes naast het paarse, dus ik denk dat de 'tabel' (hoe heet dat in internettermen?) wel 40 pixels breder kan.

60 pixels voor de avater (+ een beetje meer voor de nick), 640 pixels voor het plaatje, en dan heb je nog 100 pixels over voor de randen en de ruimte tussen avater en plaatje/tekst.

[justmental]

Naast de technische complexiteit en performance nadelen is dit verantwoordelijkhedenswijs niet wenselijk.
Om te resizen moet het plaatje van extern ingelezen worden, daarmee doet een server van tnet een request op een url wat de gebruiker ingeeft, dat kan allerlei nare gevolgen hebben.

[Rataplan]

ramH schreef op 21 januari 2003 @ 19:09:
[...]

Dat laatste is misschien wel een mogelijkheid, maar dat kost weer traffic omdat (in ieder geval een klein gedeelte van het plaatje opgehaald moet worden van de locatie) het plaatje gechecked moet worden; wat ook weer extra serverload kost.

Denkfout Je moet de grootte van het plaatje niet controleren bij het laden van de pagina, maar bij het posten. GoT krijgt maximaal 50 tot 100 posts per minuut, daar kan best een plaatjesfilter - dat tenslotte alleen maar achter de bytesize van een bestand hoeft te komen - overheen (al weet ik niet hoeveel servers daadwerkelijk list-info enzo verstrekken). In hoeveelheden traffic maakt het dan weinig meer uit. Bovendien kan je - ok, dat kost dan wel weer *iets* extra serverload - aangeven vanaf welke size een plaatje als link moet worden weergegeven, waarmee GoT exact op je bandbreedteverbruikbehoefte kan worden afgesteld. Hup Femme, coden

Ben hier erg voor aangezien je toch nog wel eens zo'n .bmp rechtstreeks uit de digitale camera in een draadje tegenkomt. Mét height- en width-tags

[Verwijderd]

Verwijderd schreef op 21 januari 2003 @ 11:11:
Je kan toch ook de verkleinde plaatjes cachen, die cache leeg je na een tijdje weer. De load blijft normaal (een (1) keertje resizen per plaatje (meestal)) en de harddisk blijft ook relatief leeg (want van oude --niet meer opgevraagde-- topics wordt het verkleinde plaatje verwijderd).

Geen goed idee?

nee, moet ie het alsnog voor elke user resizen, wat je nu dus ook doet. Wat er nu gebeurt is dat het gewoon dmv html resized, client based dus. Jou idee (als ik het goed begrijp) zou server based zijn.

trouwens, [img=440,680]url-van-plaatje[/img] wordt gewoon helemaal vertaald naar html. Elke ander optie die gedaan zou worden (bvb [img=35%]) zou extra serverload veroorzaken.

[ Voor 15% gewijzigd door Verwijderd op 22-01-2003 09:27 ]

[Wouter Tinus]

Rataplan schreef op 22 januari 2003 @ 07:11:
Denkfout Je moet de grootte van het plaatje niet controleren bij het laden van de pagina, maar bij het posten. GoT krijgt maximaal 50 tot 100 posts per minuut, daar kan best een plaatjesfilter - dat tenslotte alleen maar achter de bytesize van een bestand hoeft te komen - overheen (al weet ik niet hoeveel servers daadwerkelijk list-info enzo verstrekken). In hoeveelheden traffic maakt het dan weinig meer uit. Bovendien kan je - ok, dat kost dan wel weer *iets* extra serverload - aangeven vanaf welke size een plaatje als link moet worden weergegeven, waarmee GoT exact op je bandbreedteverbruikbehoefte kan worden afgesteld. Hup Femme, coden

Ben hier erg voor aangezien je toch nog wel eens zo'n .bmp rechtstreeks uit de digitale camera in een draadje tegenkomt. Mét height- en width-tags

Denkfout . Het parsen van de posts gebeurt ook tijdens het posten, niet tijdens het samenstellen van de pagina. Het is dus onmogelijk om realtime - afhankelijk van iemands instellingen - de output te bepalen. Dat zou de servers compleet om zeep helpen. Verder zie ook het argument van justmental, en denk er ook eens aan hoeveel langer het posten van een bericht met plaatjes van een tragere server zou gaan duren. Of moet dat ook maar meteen "verboden" worden? Nogmaals, de mentaliteit van mensen kun je niet veranderen met software. Als iemand geen zin heeft om een nette, leesvriendelijke posts neer te zetten, dan kun je coden wat je wil, maar dan gebeurt dat ook niet .

[Azrael]

Resistor schreef op 21 January 2003 @ 22:01:
Wat is eigenlijk de ideale maat hier?

De meeste plaatjes die ik heb zijn 640x480 (foto's, geen plaatjes die ik ergens anders vandaan haal)
Die steken net iets uit de layout, 600x400 niet, maar dat is niet echt een standaardmaat voor plaatjes.

Kan de layout niet aangepast worden aan 640x480 plaatjes? Ik zit nu momenteel achter een 800x600 monitor, en ik zie nog witte randjes naast het paarse, dus ik denk dat de 'tabel' (hoe heet dat in internettermen?) wel 40 pixels breder kan.

60 pixels voor de avater (+ een beetje meer voor de nick), 640 pixels voor het plaatje, en dan heb je nog 100 pixels over voor de randen en de ruimte tussen avater en plaatje/tekst.

zie ook Is de layout smaller geworden :? , daar is dat uitgebreid in behandeld, wat de status nu is weet ik niet

[jelmervos]

Hebben ze op het FokForum niet zo'n soort functie, of vergis ik me daarin?

[DinX]

Verwijderd schreef op 22 January 2003 @ 09:22:
[...]

nee, moet ie het alsnog voor elke user resizen, wat je nu dus ook doet. Wat er nu gebeurt is dat het gewoon dmv html resized, client based dus. Jou idee (als ik het goed begrijp) zou server based zijn.

trouwens, [img=440,680]url-van-plaatje[/img] wordt gewoon helemaal vertaald naar html. Elke ander optie die gedaan zou worden (bvb [img=35%]) zou extra serverload veroorzaken.

Toch niet. Hij bedoelt dat de plaatjes bij het aanmaken van het topic gecheckt worden (of bij het posten van nieuwe plaatjes in een reply) en dan geresized worden opgeslagen. Dit mag best in hele slechte kwaliteit zijn, en dat er dan automatisch een hyperlink achter komt naar het originele plaatje.

De load valt dan nog best mee (alleen wat meer bandbreedte nodig). Alleen heb je extra opslag nodig voor die slechte kwaliteit geresizede pics.

Op deze manier moet de server het ook niet bij elke view van het topic doen, maar enkel 1 keer wanner het betreffende plaatje gepost wordt.

[Wouter Tinus]

Dat is gewoon clientside resizing om de layout te sparen, als iemand dan een BMP van 5MB post moet een modempje die nog steeds helemaal downloaden.

[chem]

Delphi schreef op 23 January 2003 @ 20:41:
Hebben ze op het FokForum niet zo'n soort functie, of vergis ik me daarin?

Nope, dat is een JS truukje (of css?) die de image scaled. De afbeelding blijft even groot en het werkt in veel browsers niet.

[jelmervos]

Oke, client-side oplossing. Ik heb er nooit echt naar gekeken. Weten we dat ook weer.

[MSalters]

Post-time check is wel haalbaar, ook met langzame picservers: Server doet een image get van max. 100K met timeout 10 seconden. Is de image daarna niet helemaal binnen dan komt er gewoon een kruisje in de post. Wat dat betekent snappen pic posters inmiddels wel, dan is er iets mis met je URL/pic ->fixen.

Impact: Max. 100K traffic per picture, inbound, (dat is de minst belaste richting) en 1 open TCP/IP connection gedurende 10 seconden.

[chem]

10 seconden? En als je 15 plaatjes in je post hebt en de host is down?
User vindt het traag en ramt 10x op submit. Woei, 10x15 connecties open...

Nee, dit gaat echt niet werken. Mensen zijn lui, en wmb doe je een topicreport als het echt brak is. Of surf zonder afbeeldingen aan

[jelmervos]

Mensen zijn idd lui, daarom automatiseren we toch? Gemak dient de mens.

[MSalters]

chem schreef op 23 January 2003 @ 21:40:
10 seconden? En als je 15 plaatjes in je post hebt en de host is down?
User vindt het traag en ramt 10x op submit. Woei, 10x15 connecties open...

Nee, dit gaat echt niet werken. Mensen zijn lui, en wmb doe je een topicreport als het echt brak is. Of surf zonder afbeeldingen aan

1) Meestal komen 15 pics van 1 host; je hebt aan 1 connectie genoeg om een host down te detecteren (met HTTP 1.1 kun je zelfs die 15 pics met 1 connectie checken).
2) De check komt natuurlijk na de dubbelpost detectie.
3) Je hebt geen open connecties als de host down is.

[kmf]

Ik ben altijd al een tegenstander geweest van dit oh zo handige "feature". Laatst was er iemand die in een digicamfototopic het in z'n bol haalde om meer dan 30 foto's ongecomprimeerd te posten. Dat betekende dat ik, volgens opera 50MB moest downloaden om die topic te kunnen aanpassen.

Als iedereen die height/weight code gebruikte ipv het daadwerkelijk croppen/resizen voordat ze posten, dan kan zo'n topic makkelijk 200MB per pagina aan dataverkeer genereren, elke keer als het wordt geopend.
Ik denk dat zelfs met een 100Mbit verbinding je daar niet op zit te wachten. Als al je werkgeheugen opeens volraakt ben je ook niet blij lijkt mij.

[ACM]

MSalters schreef op 24 January 2003 @ 11:52:
3) Je hebt geen open connecties als de host down is.

Het kost daarentegen wel een zekere tijd om te bepalen of een host alleen maar traag is of down...

Dat soort stukjes tijd zijn vaak langer (de zgn timeout) dan de tijd die bij een host die up is het plaatje te downloaden.

Magoed, de vele nadelen die er zijn doet ons tot nog toe elke keer besluiten dat we dit niet gaan besluiten.
Er is ook nog wel een potentieel rechten-probleempje. Wat als iemand playboy-copyrighted pics in een post zet en die ook nog eens door ons gedownload worden en herdistribueerd? En dan dus niet in een google-like thumbnail (waar een rechtzaak om was), maar in een goed zichtbare verkleinde versie...

athlonkmf schreef op 24 januari 2003 @ 12:04:
Ik ben altijd al een tegenstander geweest van dit oh zo handige "feature". Laatst was er iemand die in een digicamfototopic het in z'n bol haalde om meer dan 30 foto's ongecomprimeerd te posten. Dat betekende dat ik, volgens opera 50MB moest downloaden om die topic te kunnen aanpassen.

Dan pas je die post toch aan en haal je die uncompressed plaatjes van die idioot eruit?

Als iedereen die height/weight code gebruikte ipv het daadwerkelijk croppen/resizen voordat ze posten, dan kan zo'n topic makkelijk 200MB per pagina aan dataverkeer genereren, elke keer als het wordt geopend.
Ik denk dat zelfs met een 100Mbit verbinding je daar niet op zit te wachten. Als al je werkgeheugen opeens volraakt ben je ook niet blij lijkt mij.

Tweakers.net _heeft_ een 100Mbit verbinding...

Denk je dat wij op 200MB downloads/page zitten te wachten?

edit:

Euh, je was al een tegenstander

[ Voor 40% gewijzigd door ACM op 24-01-2003 12:18 ]

[kmf]

ACM schreef op 24 januari 2003 @ 12:10:
[nohtml]
[...]
[/nohtml]

Dan pas je die post toch aan en haal je die uncompressed plaatjes van die idioot eruit?
[/edit]

Had ik al gedaan, maar zoals ik al zei, ik moest eerst eventjes 30MB of zo binnentrekken voordat die page geladen was. Op gegeven moment werd ik het zat en had ik gewoon Imageloading uitgezet bij opera.

[Oxi]

athlonkmf schreef op 24 januari 2003 @ 12:04:
Ik ben altijd al een tegenstander geweest van dit oh zo handige "feature". Laatst was er iemand die in een digicamfototopic het in z'n bol haalde om meer dan 30 foto's ongecomprimeerd te posten. Dat betekende dat ik, volgens opera 50MB moest downloaden om die topic te kunnen aanpassen.

Als iedereen die height/weight code gebruikte ipv het daadwerkelijk croppen/resizen voordat ze posten, dan kan zo'n topic makkelijk 200MB per pagina aan dataverkeer genereren, elke keer als het wordt geopend.
Ik denk dat zelfs met een 100Mbit verbinding je daar niet op zit te wachten. Als al je werkgeheugen opeens volraakt ben je ook niet blij lijkt mij.

opera heeft zelfs een snelknop om die niet te laden

ik neem niet aan dat we het over grote topics met veel pics hebben (zoals 3d pics showen, mooi vrouwen topics en die zut).
maar bijvoorbeeld een casemod (veel meer pics dan in meeste andere topics). daar vind ik dat het een kwestie van fatsoen is om je pics te resizen...
hier eerder las ik al om de layout te verbreden voor pics die 640 in breedte hebben. nou hoeft dat van mij niet omdat 640 resizen naar 600 echt geen probleem is (in imagesize). plaatjes van digicams (groot dus) zijn wel een probleem. tsja als je het vernoemd in de FAQ kun je dan topics sluiten of de post aanpassen als mod.

[ Voor 5% gewijzigd door Oxi op 26-01-2003 02:42 ]

[ACM]

athlonkmf schreef op 24 januari 2003 @ 17:16:

Had ik al gedaan, maar zoals ik al zei, ik moest eerst eventjes 30MB of zo binnentrekken voordat die page geladen was. Op gegeven moment werd ik het zat en had ik gewoon Imageloading uitgezet bij opera.

Volgens mij snap ik je post niet

Want je bent een tegenstander van deze feature maar vindt hem blijkbaar toch handig

Anyway, ik heb denk ik wel voldoende gemotiveerd waarom het er niet van zal gaan komen en jouw voorbeeldje is trouwens ook een mooi tegenargument

[kmf]

ACM schreef op 26 januari 2003 @ 02:47:
[nohtml]
[...]
[/nohtml]
Volgens mij snap ik je post niet

Want je bent een tegenstander van deze feature maar vindt hem blijkbaar toch handig

Anyway, ik heb denk ik wel voldoende gemotiveerd waarom het er niet van zal gaan komen en jouw voorbeeldje is trouwens ook een mooi tegenargument

athlonkmf schreef op 24 januari 2003 @ 12:04:
Ik ben altijd al een tegenstander geweest van dit oh zo handige "feature". Laatst was er iemand die in een digicamfototopic het in z'n bol haalde om meer dan 30 foto's ongecomprimeerd te posten. Dat betekende dat ik, volgens opera 50MB moest downloaden om die topic te kunnen aanpassen.

Als iedereen die height/weight code gebruikte ipv het daadwerkelijk croppen/resizen voordat ze posten, dan kan zo'n topic makkelijk 200MB per pagina aan dataverkeer genereren, elke keer als het wordt geopend.
Ik denk dat zelfs met een 100Mbit verbinding je daar niet op zit te wachten. Als al je werkgeheugen opeens volraakt ben je ook niet blij lijkt mij.

[BrZ]

athlonkmf schreef op 26 januari 2003 @ 13:17:

[...]




[...]

Ik snap het ook nog steeds niet hoor
Je wilt geen hele grote plaatjes downloaden, dus daarom ben je tegenstander van een functie automatisch de plaatjes kleiner maakt

[Azrael]

BrZ schreef op 26 januari 2003 @ 14:26:
[...]

Ik snap het ook nog steeds niet hoor
Je wilt geen hele grote plaatjes downloaden, dus daarom ben je tegenstander van een functie automatisch de plaatjes kleiner maakt

Groot als in hoeveelheid kilobytes, niet als in plaatjes van 1600x1200

Hij is dus tegen die functie omdat mensen nu soms gewoon enorme plaatjes posten van meer dan een MB ofzo en dan resizen met die tag naar 640x480, iets wat vrij asociaal is.

[BrZ]

Azrael schreef op 26 januari 2003 @ 15:56:
[...]

Groot als in hoeveelheid kilobytes, niet als in plaatjes van 1600x1200

Hij is dus tegen die functie omdat mensen nu soms gewoon enorme plaatjes posten van meer dan een MB ofzo en dan resizen met die tag naar 640x480, iets wat vrij asociaal is.

ja, maar we hebben het hier juist over een functie die het aantal KB kleiner maakt

[Azrael]

Maar we waren er al over uit dat zo'n functie niet echt mogelijk is. Toch

athlonkmf heeft het over die gewone resize functie.

[BrZ]

Azrael schreef op 26 January 2003 @ 17:42:
Maar we waren er al over uit dat zo'n functie niet echt mogelijk is. Toch

athlonkmf heeft het over die gewone resize functie.

ehm, mja, ok, daarmee ben ik het dan wel eens met hem

[Erkens]

BrZ schreef op 26 januari 2003 @ 18:44:
[...]

ehm, mja, ok, daarmee ben ik het dan wel eens met hem

die rml-resize functie is juist handig om plaatjes te vergroten, zoals bijvoorbeeld de edit-button