Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Three normalized size of images, by default
Right now, Textpattern handle two sizes of images: the regular one, and the thumbnail. The concept is to use the regular one in article and the like, and the thumbnail in a link to the article, in a list of articles, and the like.
However, since Textpattern was at a time suppose to help the web writer, I think it lack another size: the “big” or original size. So there would be three size :
- original: as big as wanted or as the server support it
- article display: to include in a common text article context
- thumbnail: to create list and such
Why ?
Because, in most web design, the image displayed in article has to be of limited size. Something around 400 pixel wide, give or take. But on the other hand, the size of rendering area (monitor and screen resolution and size, mostly) have increase at a tremendous speed, we could very well have a “standard” screen width over 1500 pixels in a few years. And it’s already the case for a lot of people.
Because, a regular image (not a CSS graphical item) is content, and today it’s impossible to zoom in. Even if a experienced user can zoom, it will lose a lot of details and resolution. So we pretty much lose content.
The feature I propose for comment, is to have the user upload the original size of its image. If it’s really too big, it can be resize by the server and compressed to the user define format. Then it’s dowsized to the “article size”, also define by the user; and downsized to the thumbnail format.
So in the end, the frontend web user would have a simple and usable web experience (it’s just an example on the basic layout/organisation use, it has also much more possibilities):
- He sees the thumbnail alongside the excerpt, in an article list context, and they link to the article.
- In the article context, he sees the article-sized image, that does well in the layout of the site, alongside the article’s body. The article-sized image is also a link to the original size.
- If he wants, he can click the image in the article, and have the original size image on it’s own, or maybe with a simple page around it with basic data (like name, category, alt text, caption).
Offline
#2 2007-06-05 12:06:05
- minusf
- Member
- Registered: 2005-02-15
- Posts: 104
Re: Three normalized size of images, by default
even if we will have 2400px wide screens, i don’t think
that means we’ll have 2400px wide webpages.
at least not with text.
even now, pages wider than 1024px are bad for the eyes.
especially if with textual content (blog, articles, etc — txp stuff)
wider than 820px (even in columns style) makes (at least my)
head ache…
of course, most people who publish know nothing about
publishing at all… but i guess that’s normal.
we is experts™
Offline
Re: Three normalized size of images, by default
That’s exactly what I’m saying. Having a intermediate size (the “article size image”) to put inside the layout ; and an “original size” image to be displayed on user demand, outside of the site layout and article context.
Offline
Offline
Re: Three normalized size of images, by default
A fair request. If I’d implement it, it would be a general solution: Allow an adjustable number of image representations (no hard coded limits, but set as a preference), and let the site builder name them (S, M L, XL, whatever).
My next main target will be nested sections (in crockery), not image handling, so if someone can provide a database layout for a flexible image storage area plus some basic library functions to base tags, updates from older Textpattern versions and user interface upon, it’ll be valued.
Be aware that such a major feature change has to target the crockery branch, not 4.0.
EDIT: The relevant thread is here, IMHO it’s already been discussed exhaustively.
Last edited by wet (2007-06-05 13:34:30)
Offline
Re: Three normalized size of images, by default
wet wrote:
A fair request. If I’d implement it, it would be a general solution: Allow an adjustable number of image representations (no hard coded limits, but set as a preference), and let the site builder name them (S, M L, XL, whatever).
Glad to hear this, and that you would go one step further :)
My next main target will be nested sections (in crockery), not image handling, so if someone can provide a database layout for a flexible image storage area plus some basic library functions to base tags, updates from older Textpattern versions and user interface upon, it’ll be valued.
I can provide anything but code. Database layout, English scenarios and step by step, and the like. If someone needs this, just mail.
Be aware that such a major feature change has to target the crockery branch, not 4.0.
Yup I was guessing that. Not an issue.
EDIT: The relevant thread is here, IMHO it’s already been discussed exhaustively.
That thread is a gargantuan one, with a lot of things in it. And as far as I can tell, no such endeavors got anywhere on the dev side (there’s also the content linking one, the admin redesign, the various plugin integration into core, etc.). That’s why I made this one a small one. One feature at a time :)
Offline
#7 2007-06-05 23:59:05
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Three normalized size of images, by default
Allowing for unlimited multiple images per “image” upfront makes better sense than “just adding a third”, since the latter does not naturally lend itself to growing into the former.
In reality, I don’t think it is likely to show up in the first 4.1 release, but perhaps a version after it. It is a significant undertaking and we’ve already got a couple of those slated for 4.1’s release, such as nested sections. It is better to work on things one at a time rather than rush it out the door, likely with bugs in it (like what happened with file downloads).
Offline
Re: Three normalized size of images, by default
I strongly agree this would be a useful feature. At the moment I am using humungous images as my “originals” and my thumbnails are 500px wide – “page sized” – so I’m sorely missing a “true” thumbnail for gallery display/search results.
MediaWiki uses ImageMagick to thumbnail images to sizes as requested. it generates half a dozen standard sized thumbnails on upload, and other-sized ones are created on request. Txp wouldn’t even need to go that far, I think.
[[image:foo.jpg]] – show image at original size
[[image.foo.jpg|thumb]] – show image at thumbnail size, whatever you have set in your user preferences (from a choice of the half dozen “standard” sizes)
[[image:foo.jpg|200px]] – show a 200px-wide thumbnail of the image.
etc.
30-page threads scare me. :)
cheers, Brianna
Offline
#9 2007-06-22 14:17:06
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: Three normalized size of images, by default
Another thing to consider : storing images in the database, instead of files.
This study seems to show it’s much more efficient for files under 1MB if they are rarely being overwritten, and for files under 256 KB in any circumstance, which images usually are. Perhaps only the original image should be kept as a file.
This way, all images could be made dynamic : www.site.com/images/4.jpg?XL, www.site.com/images/4.jpg?S, etc. without having both a database and a file query.
Also; besides image-size, filters should be consider. I like to add watermarks, or a magnifying glass on thumbnails. These filters could be installed as plugins.
I could start working on all of this during the summer holidays. I would find it slightly frustrating to develop for crockery though, unless someone would suggest that it will be released in a reasonable amount of time.
Offline
Re: Three normalized size of images, by default
Another thing to consider : storing images in the database, instead of files.
That might be a nice stress test for a webserver, but I can guarantee you that it’s certainly not more efficient than what TXP does at the moment.
The study you refer to only compares file based images to images stored in a database, but if you were to implement this in TXP, you have to factor in something else: serving images through a PHP script is nowhere near as fast as letting the webserver itself serve a static file.
To give you some indication of the speed difference, which I measured on a server I maintain: a static CSS file is approximately 200 times (!) faster than the same CSS file served through TXP (granted, I’m using PHP as CGI instead of a module, but still).
Last edited by ruud (2007-06-22 18:27:04)
Offline
Re: Three normalized size of images, by default
I agree with ruud (not that I understand the technicalities) but also I would like to add that the size of the database would bloat for image based sites which will result in problems when migrating or backing up.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Offline