I think it looks crummy for two reasons: first, aesthetically: I just prefer the look with no text cluttering up the images. Yet, that means the text doesn't get presented anywhere at all for most people.
Second: technically. The text is often hard to read, because it has no dropshadow, and the background colors vary. I tried putting the text on with my ppmcaption program, but it looked like crap. This version is using ImageMagick to do it, but I don't see how to put a dropshadow on. Also, it's insanely slow: it appears to be firing up GhostScript to render the text!
I'm generating them like this: is there a better way?
- convert large.jpg \
-geometry W2xH2 \ # twice the target size
-fill '#00DDFF' \
-font HelveticaBold \
-pointsize 16 \
-gravity southeast \
-draw "text 5 5 'DATE\\nTITLE'" \
-geometry WxH \ # actual target size (to antialias the font)
thumb.jpg
Update: I guess it's a little better if I fake a dropshadow by drawing the text five times:
- convert large.jpg \
-geometry W2xH2
-gravity southeast \
-font HelveticaBold \
-pointsize 16 \
-fill '#000000' \
-annotate "text +4+4 'DATE\\nTITLE'" \
-annotate "text +4+6 'DATE\\nTITLE'" \
-annotate "text +6+4 'DATE\\nTITLE'" \
-annotate "text +6+6 'DATE\\nTITLE'" \
-fill '#00DDFF' \
-annotate "text +5+5 'DATE\\nTITLE'" \
-geometry WxH \
thumb.jpg
Why do you need any of it? If people care to find out they just click twice. When you had the female wrestling pictures I wanted more information, so I clicked. I clicked a lot. A lot a lot. I clicked too much. I admit that I clicked too much.
i agree, more people are likely to click through to the other pictures out of curiousity as to what it is a picture from than they are if you tell them right away. Looks better without any captions on the pic, in tool tips, or anywhere..., but thats just my humble opinion...
I think your right, it's too hard to read. Have you considered embedding the text in the border of the pictures? Keeps the clutter you don't like down but gives you a consistent background to work on.
If I put the text under the pictures, then the horizontal and vertical gutters are different sizes, and that looks crummy. If I put the text inside the images but make the images taller to accomidate a black bar, then looks very similarly crummy.
What about putting a black bar all around the picture?
FWIW, I actually kind of like the look of your "burned in" captions; even at the reduced size on the DNA lounge front page it is readable. But there's another downside -- the caption is no longer robotically (eg, Google) discoverable, which is probably a net-loss.
I do something similar with my photos, but primarily to "watermark" them with some identification that they're mine. I'm using a perl script which uses Image::Magick (ie, the perl API to ImageMagick). It definitely needs an X server to talk to, which I think it's using to render the font, but I can't say I'd noticed it firing up Ghostscript. I do explicitly specify an X font though (and deliberately chose a relatively simple font that is pretty readable at a smaller size).
Googling turns up various ImageMagick drop shadow utilities, but most of the ones I looked at either sucked (eg, running mogrify multiple times, which involves reencoding the JPEG multiple times -- yuck) or weren't doing what you wanted.
From what I can see the "best" way to do it would be with one of the ImageMagick APIs, eg PerlMagick:
http://www.imagemagick.org/script/perl-magick.php
and drawing in mulitple steps.
I've also done similar throughs through batch scripting GIMP, but that too definitely needs an X server to talk to, and is fairly slow to start up. (You can process multiple images in a run though if you feed in the right batch commands to load/modify/save.) The default scripting language for GIMP is Image-Fu (a Scheme varient IIRC), but there are others including Perl and Python interfaces.
Ewen
I fear I know the answer to this already, but do you also hate the use of javascript to modify some other visible component of the page?
I basically don't trust JavaScript to reliably work right for anything that didn't work in Netscape in 1997. I don't have the patience or interest to fuck around with the compatibility testing you need to do to do anything even remotely complicated.
I appreciate that this is not going to change your mind, but the following works on your page in Firefox & Mozilla on debian and winxp, as well as ie6 & opera on xp and ie5.5 & ie6 on nt4. I haven't tested safari as I don't have vnc on the macs at work, nor have I tried netscape 4.
This is what you want... pure css mouseover image captioning...
http://www.matthewwest.co.uk/computing/captioned_images
Maybe it's just a problem on my end, but that page seemed really laggy.
Well, it's not just you. Scrolling was like watching a slideshow on my end. I not sufficiently motivated to poke around and figure out why it's slow, but my guess is Internet gremlins and CSS nitwittery.
so what does the MEAT gallery do on your browser?
http://www.meatsf.com/index.php?sect=e&evt=2005-08-25&item=i
on my browser, I get tool-tips if I hover, and info on the status bar at the bottom.
I hate tooltips for this because I don't want the image to be obscured just because my mouse happened to land near the thing I'm looking at.
that's too bad...i really liked the mouse-overs. but what do i know?
At the bottom of the pages in http://www.jwz.org/, you used to have a compass that would spin only if you pointed at it. I don't know how that worked, but you do, and it sure was cool.
Assuming that it was done with an animated image of some kind, couldn't use the same technique to make versions of your pictures that would have the text appear only if you pointed at them? And since it was an animated image, you could animate the text -- have it fade in, scroll in, dance in, whatever.
Image-replacement JS. And yes, every bit as cool as digital watches.
Doing it the same way would mean doubling the amount of image data that had to be downloaded for every page (in the simple, no-additional-CSS-or-tables-required version at least).
Having the text flying in from the side would be GIFtastic though.
- Chris
Couldn't you do a little CSS rollover, that shows that information above/below the picture when your rollover it with the mouse? Are you 100% dead set on the information being in the status bar?
That would even be very simple to achieve, and since the pictures are within links anyway, it would even work across all browsers, including IE. Assuming the links have
CLASS="snapshot"and the captions were insideSPANtags inside the links, it would be something likeIf you stick a
position: relativesomewhere near that in the markup, you get a frame you can use for positioning the caption absolutely.It’s a whole heap more fuss to explain it than do to it, so I instead spent five minutes and threw together an appropriately modified DNA Lounge homepage. The only thing that threw me for a few moments was that putting the
position: relativeon the table doesn’t work, so I had to stick an extraDIVin there.I have to say, that is very attractive. I really haven't commented in the thread, since I actually like the tooltip style popups, but your solution is really nice looking.
I think this is the least bad suggestion. It puts the text close to the images, so Mr. Google can read it (maybe - supposedly search engines try to eliminate "hidden" content. A fool's errand, but I digress), it uses real fonts, it doesn't break the layout, ad since it's "doing the right thing," it should work okay now and later. (For example, it does Something Reasonable in lynx...)
I stared at the page for 5 minutes wondering what was different, before I finally noticed the changing text below the images. It does seem like the neatest suggestion so far, but I'm sure many others wouldn't notice it was there at all.
The doubling size and then halving causes the font to become antialiased, but at that resolution it gets very blurry. I think it'd be a lot more pleasant if you either used a bitmap-based font (maybe this one is small enough) or rendered the fonts with hinting turned on for better-quality antialiasing. For this last suggestion, I don't know a command line directly, but I know that libGD can do it and that it has Perl bindings.
(I guess implicit in this comment was that I like the text on the images if you can make it look ok.)
If I don't fuzz out the font after rendering it, then it looks really crummy in comparison to the other fonts on the page -- I suppose this wouldn't be the case if you were using a system that didn't have built-in font smoothing, but in Safari, the fonts look like they're from two different universes if one of them is aliased.
Hit reload -- two of these are not like the others. On my screen, those are the one that look like ass.
Yeah, those are definitely sucky. I played around a bit and I think you're aiming at too low of a resolution for nice fonts to antialias well at.I guess
but I saw you don't like margins.
Have you tried the ImageMagick techniques discussed here?
Scroll toward the bottom; they tell you how to do fuzzy outlines and drop shadows and stuff.
I guess it looks a little better if I render the fonts multiple times to make a dropshadow, but not much. The -stroke stuff in their examples (to outline the fonts) aren't working for me.
I seem to remember there being some stuff that only works with newer versions of ImageMagick. If yours is a couple years out of date that might be why. I ran into stuff not working on Redhat 8-9 until I grabbed a newer version.
It was only a matter of time before somebody suggested you upgrade some chunk of software you've never had to worry about before.
How about overlib, does it work in Safari?
http://www.bosrup.com/web/overlib/
Overlib is extremely customizable.
Oh, please.
I suppose it does not work in Safari, then.
No - it works quite well in Safari.
It successfully takes everything that is wrong with tooltips and magnifies it a millionfold.
I guess it depends upon how one implements it...
I think it gets usability brownie points for being as physically close as possible to the image, and they are visible for all images at once. The status bar thing only gives results off in some distant land, and then only if I interact with the page. This incarnation is unreadable.
I have nothing to add on the technical side, except that it should be simple enough to write in Java or Cocoa, but I don't have any concise explanation of how.
The saddest part is that customizable drop shadows were a part of the CSS2 spec back in 1998, but no one bothered to implement them. Frustrating.
You could do it by overlaying a transparent PNG, but IE doesn’t implement that either.
There's an awesome little hack using IE's conditional statements that renders alpha PNGs in IE.
Put the following in the <head> element:
<!--[if lt IE 7]><script type="text/javascript" src="/img/png.js"></script><![endif]-->
And then in the /img/ dir you have png.js and transparent.gif. IE sees it, runs it, and all your PNGs are alpha blended. A friend of mine pointed it out in use on his site, then I slapped it into mine. I take absolutely no credit for this, but it is really cool to actually be able to use a feature of IE to make it suck less. And this is a lot easier than manually running the DX blender on ever fracking image.
I know the trick. Makes you wonder if that works and has for so long, why they never used it to make normal alpha PNGs work properly.
The Nina Hagen one looks good to me, the others less so.
The galleries are captionless, so not having them on the pictures won't really hurt anything. Caption-free galleries are also fundamentally boring, but that's another discussion.
Do either this CSS hack or this one potentially serve as a workaround for a non-intrusive status-bar caption replacement? (Tested on Firefox, Opera, and Safari, they do nothing on I.E.)
That looks great.
Pixel fonts (itsy bitsy bitmap fonts) might work better than the ones you're using. The Nina Hagen one - which <lj user=usufructer> likes the best - is already edging into that realm.
I agree, the embedded text isn't working. You're going to have to do some sort of matting to make the text reasonably legible over photographic material and no matter how you cut that, it's going to look like ass. Putting a drop shadow on the text will only marginally improve the readability, and drop shadows are the blink tag of the graphic design world. Cheap, ugly, stupid.
If you're going to have the captions visible (which I endorse; having to tour the visible surface with the mouse to know what everything is is grating) then you're going to need to some to terms with losing the symmetrical gutter. If you maintain a solid visual grid you should come up with something reasonably reasonable.
There's an excellent face for this that renders very well without aliasing. I'll dig up the name, but in the meantime sneak a peek at Usama Hajj's portfolio which uses it for captioning purposes.
Silkscreen. http://www.kottke.org/plus/type/silkscreen/
Actually, I was thinking of Kare Five Dots, but Silkscreen looks pretty well balanced, too.
what about using divs with different z-indexes? you could use css to style the drop shadows (kinda) and javascript to change the z-index of a particular div when you mouseover a particular image/area/element?
This happens to be exactly what Overlib does (minus the CSS bit).
my bad, i saw the link above but didn't check it out.
here's a way to do it with 100% CSS:
http://dailey.info/pictest
worked for me in safari, firefox winderz and mac, and IE6.
Drawbacks:
Looks reasonably good though, and with good markup on the text you could make it look a lot better. You could also add a hover effect so the caption disappears when you hover over it, kind of the opposite of a tooltip.
i updated the html and added the caption-disappearing-on-hover. I don't think IE 5.5 supports child elements which that requires, so they probably wouldn't get the effect but it would otherwise work.
Re: <lj user="kosai">'s comment about size on high res screens, you could size the caption with em's rather than pixels, but every browser has a wildly different idea of what em's look like, and on high res screens the caption would look huge relative to the image. So, probably not gonna work.
Also, in my experience Linux browsers generally have terrible looking small size fonts, so going below about a 10px size for the font probably won't look good.
Anyway, fun side project, I'm done here. :)
Actually, all browsers have an identical view of what an
emis. It is the underlying GUI that has the wildly different understanding. All modern browsers get their DPI from the graphics subsystem, and most have a manual override soemvalues can be tweaked for broken systems.X (XFree86 and Xorg) set the DPI correctly by using the EDID information returned by the monitor (even change it properly when changing resolutions using RANDR). Mac OS X seems to fix the DPI at 75, which at least keeps text large and legible. (Only tested iBooks and small iMacs.) Windows sets it to a different value for every version and system, and it never has any bearing on reality whatsoever. It allows the user to pick from two randomly-chosen values, or if one works hard can set it to the true value (with a ruler, no use of EDID/DDC at all). However, setting the DPI to a realistic value will break the entire interface, causing critical components such as the login screen to have tiny blurred unreadable text, and Windows is nice enough to provide zero ways to change those fonts. So even when setting the DPI properly, Windows does not properly use it.
It’s not the browser, it’s mostly just Windows.
You are confusing "em" and "point".
There are 72.3 points per inch.
"Em" is relative to the font in question. In the typesetting world, it's the width of the widest normal character in the font, typically a capital letter "M". (And "en" is the width of an "average" character, typically "N".)
But CSS stupidly defines "em" as being synonymous with "ascent", that is, the height of M instead of the width. That means that in CSS, an "em" is about twice the distance that it is in the real world.
You need to know the monitor's DPI to convert from pixels to points, but "em" is always the same for a font regardless of display DPI.
Heh heh. The “M” at which I’m looking right now is perfectly square.
I can’t find where in the CSS spec it states that
emis the ascent. But even with that definition, what does it matter provided the units are used to scale fonts? (The discrepancy will only show up when setting border or margin widths usingemunits.) As long as it is applied consistently on the fonts it is no different from using a percentage scaling. My point may have been factually erroneous but it still holds as a response to the preceeding point about browsers interpretingems differently. The reason is that each browser has a different default font size, and it can be fixed by specifying fonts but never, ever using pixel-based font sizes. Making the page look good on a 96 DPI display will make it look terrible on a 67 DPI display, and completely illegible on a 130 DPI display. (I use all of the above on a daily basis.) Alternately, simply not setting any fonts in anything but percentages oremunits so the viewer has complete control over the base (default) font size and the page will scale smoothly around it.Someday I will find a large-traffic website that scales smoothly around the user’s screen size/resolution and configured font size. Someday. I’ve made demos so I know it can be done.
"Relative units are: em: the 'font-size' of the relevant font" and "'em' and 'ex' length values refer to the computed font size of the current element". So in a 12 point font, 1em = 12pt.
Well, you'd use "width: 10em" if you wanted a column to be about 15 characters wide, in whatever the prevailing font happened to be. If you said "width: 1000%", I think that would mean something entirely different (I think the percentage would apply to the block element width/height instead of the font size).
I don't believe that browsers interpret 'em' differently: I think they all treat it as a relative measure based on the current font. That they all have different default fonts doesn't affect that; in fact, that's exactly what makes 'em' most useful.
All the stuff you said about reading DPI settings from the monitor explains why using points as a measurement tends to be a complete disaster. That's absolutely true.
Yes, I agree. We clearly do not yet live in the future. It's not like this crap is rocket science, but the status quo is such a mess that it will be a long, long time before it's fixed. (For a laugh, read what the spec has to say about 'px' on "devices whose pixel density is very different from that of a typical computer display".)
That's what I've always done: measure things using 'em' and avoid 'pt' and 'px' unless talking about things that really are pixels, like boxes that go around non-auto-scaling images.
There's something wrong here. This is also making my mouse cursor go stu-stu-stutter like the CSS solution offered above by darkfrog.
I'm not on the fastest machine in the world, but it is a 1ghz P-III using Firefox. I serve DB-backed Web sites with less grunty hardware. I'd think it would run a bit better than that.
Thus far, I like edge_walker's solution the best.
weird. could just be a firefox issue. I changed it from using the z-index to using visibility: hidden. See if this one works better:
http://dailey.info/pictest/indexnew.html
I'm actually wasn't expecting the technique works at all across most browsers, especially the evil IE 5.2 for the mac, so it's not too surprising to see some issues.
The CSS stuff is interesting, if your point was to prove that using CSS to do anything more complicated than set font sizes is flaky and unreliable and should be avoided at all costs. But I knew that already.
Heh, I didn't think you would like it. :)
But, I was surprised that it seems to work in all the browsers I tossed at it. It's not a bad trick, and better than a javascript alternative, maybe.
That’s really strange, I’m looking at it on my Pentium-MMX 166 laptop with 48 MB of RAM, and it’s working smoothly and quickly for me. No mouse problems, no rendering problems. I think you should examine your machine for problems, not the webpage.
I'm running at 1920x1200, and the text's way too small to read without getting very close to the screen; I have the default firefox font size turned up a few pts, but I can't do that with your images.
So, a vote for something I can tune the size of myself, for what it's worth.
- C.
With the exception of the Nina Hagen one, they're all pretty much unreadable to me, even the GWAR one.
Problems:
The http://dailey.info/pictest thing in <lj user="twid" />'s comment seems like a good idea, just use a less crappy font and a darker (but possibly partially-transparent? can you do that in CSS?) background with better placement.
You're fighting the good fight, by the way: Mouse-over status-text sucks.
[j]
So what't wrong with <img title="Stuff" src="..." >
Somehow you managed to miss the half dozen times I've already said how and why I hate tooltips.
I hate the text on the pictures. Very hard to read, and I find it really makes the pictures less appealing.
I like edge_walker's modified page.
Surfing out of order gave me the pleasure of reading this post immediately after digging through links about the Clock of the Long Now. Reading through the first few replies, my mind was still trying to put everything in the context of associating text with images such that it would look good on all browsers in the foreseeable future. And for providing that wonderful moment of confusion, I thank you.
If it's possible to 'xor' the text onto the picture, that may fix your background color woes (it may look wierd however). It won't fix the problems with screen-resolutions though.
XOR in color doesn't work on cluttered backgrounds.
I remember reading somewhere that a large dark dropshadow below a smaller grey dropshadow is better than a large dark dropshadow alone.
An old post from Raymond Chen's blog has a nice illustration of what <lj user="strspn"> already mentioned about xor.
I guess I missed where you say what you dislike about putting text captions underneath the actual images.
Caption 1
Caption 2
etc
You could put the caption somewhere else in the section, sort of like how you wanted to do with updating the status bar. A floating status bar somewhere? Perhaps some sort of bar at the bottom or top of an image section that shows a description or title on an image mouse over?
Given, idea this has a chance of ending up being horribly tacky and requires additional javascript.
You might be interested in how I do something similar at http://bwbohh.net/... I only use it for a navigational aid, not for my images, but the concept is the same.
(it is a "drop box" underneath which appears on mouse-over.. sort of like the "drop box" in firefox when it blocks a popup)
Ahh, I didn’t remember that
ptunits were vertical.The most frustrating thing for me is that this is 2005, and Windows still doesn’t set a reasonable DPI. (Or implement a proper CSS box model, or generated text, or—) These things have been easily done on other platforms for a decade now, can Microsoft please catch up with the state of the art?
(If I ever write a web browser, I plan to implement their guidelines on pixels on high-DPI machines. It was a reasonable band-aid that is consistently ignored.)