Number of Userpics

[iponeddd]

Title
Number of Userpics

Short, concise description of the idea
I feel that the number of userpics a person has should not be limited as they are with those of us who have basic and plus accounts.

Full description of the ideaI have many userpics that I would like to add to my account, but I only have a limit of 15. There should be an unlimited amount

Comments

[ursamajor]

There should be an unlimited amount of userpics per person no matter what the account type that person has.

GreatestJournal thought this was an excellent idea! Then they discovered just how expensive large numbers of userpics were to serve (read: the cost of bandwidth and transfer made their promise of 2000 userpics utterly unfeasible to maintain for the price they were charging for *paid* accounts, let alone what money they weren't making on *free* accounts).

Basically, this will never, ever happen, but eventually, someone will come along with numerical data that reinforces what everyone is saying: "Unlimited userpics: sure, they'd be nice to have for our LJs, but not at the expense of HAVING our LJs."

[snakeling]

Wait, GreatestJournal had paid accounts? I'm almost certain that they only had ads, and fairly small ones at that, that you could even turn off.

[ursamajor]

Huh, you know, that sounds more correct/familiar now that you mention it. Which just makes GJ's userpics proposal that much more audacious and unsustainable.

[rizzo]

yeah, there were never paid accounts.

[leora]

Well, I wouldn't say never. Computer technology improves so fast. Maybe in fifty years LJ will offer unlimited userpics, but people will be complaining about their free accounts only having 15 holovids or whatever. But yeah, as unpleasant as it can be, there have to be limits, because somebody has to pay for it somewhere along the line.

[mskala]

How does more userpics per account increase the bandwidth cost? The bandwidth is paid every time someone looks at a userpic. Whether it's one pic shown a thousand times or a thousand pics shown once each, it's the same amount of bandwidth.

About the only way I can see more userpics translating to a higher bandwidth cost would be if userpics were cached by browsers a large fraction of the time and if usage patterns meant that that caching was much less effective when there were more pics per user. Was that found to happen, and was it found to happen enough to make a real difference? I suppose that's possible, but it sounds far-fetched.

More userpics means more storage cost, but until I see solid evidence otherwise, I call bullshit on "it would increase bandwidth cost."

[gerg]

Caching is surprisingly more effective than you'd think. The main issue with multiple userpic slots is that the more userpics a person has, the more likely it is that they can pick a different one every time they post.

This will result in it being less likely that that particular userpic is cached, so yeah, that does raise bandwidth cost when you're operating on the scale that LJ operates on. If you can imagine someone browsing through ohnotheydidnt threads where everyone within had 1000 userpics, instead of seeing "NO U" "NO URS" "NO UR FACE" with the same userpic back and forth, imagine instead having to display a different userpic every single time in the exchange, none of which were cached, and all of which needed to be requested

[pbristow]

"Also, images don't compress very well."

Techie nitpick/clarification: Most images actually compress *very* well, but they are already about as compressed as they can get before they're uploaded and stored on LJ (good ol' JPEG). The problem is more that if "a picture paints a thousand words", then it necessarily takes at least a thousand words' worth of storage. =:o} (Although admittedly, the average icon only paints about a hundred words... the most common words being "Look at this hot chick from my favourite fandom! (HUBBA x91)!!! ". =:o} )

Typical comment = 100 words = approx 5kB, LZ compressible to 1 or 2 kB.
Typical icon = 100x100 pixels at 3 bytes per pixel = 30kB; JPEG compressed to 6kB.