Friday, 26 June 2009

Michael Jackson is dead!

This morning I was doing some work on my photo website, testing different images to see what ICC Profile Description they had. While an image can have any ICC Profile (you can create your own profiles), since there's only a few different profiles that my images will have, I wanted to get a list of these. Then when updating the database, I can just SELECT the relevant profile from the colorSpace table, rather than having to first INSERT the value into the colorSpace table in case the color Profile value doesn't already exist.

I found that my Canon files, both processed through ACR and DPP had an ICC_Profile:Description of "Adobe RGB (1998)"
Nikon files processed through Capture NX (I didn't bother trying them with ACR) had a ICC_Profile:Description of "Nikon Adobe RGB 4.0.0.3000"
Images converted to sRGB in Photoshop had an ICC_Profile:Description of "sRGB IEC61966-2.1"
Files converted to sRGB by my website had an ICC_Profile:Description of "sRGB IEC61966-2-1 black scaled"

Looking in Photoshop under Edit>Convert to profile, there is a long list of different profiles, however, I think the 4 above will probably cover all my images. If I start using other color profiles, I can always just add the ones I need to the database manually.



Next, I wanted to deal with images that might have an EXIF:ColorSpace tag of "Adobe RGB", but no embedded color Profile. I thought that probably these files (I'm not sure if I actually have any files like this, but better safe than sorry), wouldn't convert to sRGB properly if they didn't have an embedded color profile.

You can see on the PHP Manual page for Imagick::profileImage that to get an image to convert properly, you should give it its correct Color Profile (if it doesn't have one) before converting to the new color Profile.

So to do this, I needed to get a copy of the Adobe RGB (1998) profile. Googling took me to a page on Adobe's website. On the download page it has 3 options, one each for Windows, Mac and Linux. After following through the Linux link, when it eventually got to the actual download page, it wasn't found and just went to the main Adobe download page.

So I went back and tried the page for Windows, since I don't think there could be any differences between the actual profile files for Windows, Mac or Linux. Thankfully following through the pages here did get me through to the actual download page.

When trying out a conversion on the AdobeRGB tagged image of the Maple leaves from Jeffrey Friedl's article on color spaces (the differences between sRGB and aRGB on that image are quite obvious, and so good for testing with), I found that the image still wasn't being converted to sRGB correctly. Looking at the exif with exiftool, I found that it wasn't using EXIF:ColorSpace to hold the color space value, but rather EXIF:InteropIndex

So now I've changed my code to check first ICC_Profile:Description, then if that isn't set, EXIF:InteropIndex, then finally if that isn't set, check EXIF:ColorSpace.

After lunch I went on Animal Crossing, checked my spleenmail, then did some more website stuff. I found that in IE6 part of my site wasn't working properly. When I clicked a link to change the size of image that is displayed, I got sent back to the home page. It should go back to the page I clicked the link on, except with the image size changed.

Doing some debugging, I found it was because I was using $_SERVER['HTTP_REFERER'] (apparently Referrer is mis-spelt in the HTTP specification!), and in IE6 this was blank for some cheesun. Weirdly, when trying my test page in IE6, $_SERVER['HTTP_REFERER'] was being filled in. Anyway, reading some stuff it seems that $_SERVER['HTTP_REFERER'] is sent by the Browser, and so the Browser may not send that header, or it may be stripped say by a firewall before reaching the Server, and so it's best not to use/rely on $_SERVER['HTTP_REFERER'].

I knew before that $_SERVER['HTTP_REFERER'] wasn't reliable from a security point of view since it can be spoofed, but I didn't realise that it might not get sent at all. Actually now I'm typing this, I seem to remember typing something like this before. Probably I did know it before, but forgot. Checking the HTTP headers in Fiddler confirmed that IE6 wasn't sending the Referer header for the page in question for some cheesun.

Anyway, to fix it, I just set a $_SESSION variable like $_SESSION['prevURL'] = $_SERVER['REQUEST_URI'];, then on the next page I can refer to $_SESSION['prevURL'] instead of $_SERVER['HTTP_REFERER'].

After dinner I was trying to work out how to get images to display centered vertically and horizontally. I had a load of anchor elements, and inside each anchor element was an image. I applied a fixed height and width to the anchors, and needed to get the images centered inside the anchors, but I didn't know the dimensions of the images as it varied for each image.

Eventually I worked it out, thanks partly to this article: Centering (horizontally and vertically) an image in a box.

That article, and also CSS: Centering things suggest using display: table-cell. However, there is a problem with this (at least in my case) that your 'table cells' are treated as being in a 'table row', and all items in that 'table row' are stuck on one line, rather than being wrapped and pushed down onto the line below when the viewport is small.

So if you have a large amount of images (or whatever) you'd end up with one long single row of images and a scrollbar. I can't find the page I read it from now, but the reason for this is that when you assign the CSS property 'display: table-cell' without assigning 'display: table-row' to its parent, and 'display: table' to the row's parent, the table row and table are created automatically.

So in my case, I would be assigning the CSS property 'display: table-cell' to a load of anchor elements, which are contained in a div. Because they are all contained in the same element, this means that the table and table row that automatically created by the browser, contain all of them. So I get the problem of them all being on one long row that doesn't wrap if the row is wider than the viewport or page width.

One solution, and the one used in the article Centering (horizontally and vertically) an image in a box is to wrap each anchor (or whatever element you're using to contain the centered image) with its own parent element. If you try making your viewport narrow while viewing that article, you'll see that the examples they've posted do wrap on to the next line when the viewport is too small.

If you view source on that article, you'll see why - they've wrapped each item they apply the CSS property 'display: table-cell' to in an <li> element. So the table and table row containing their 'table cell' div, is contained within the <li>:
<ul class="example uno">
<li><div class="wraptocenter"><span></span><img src="g101.gif" alt="" width="101" height="101"></div></li>
<li><div class="wraptocenter"><span></span><img src="g161.gif" alt="" width="161" height="161"></div></li>
</ul>


However, doing some experimenting, I found that setting the line-height works for all browsers apart from IE6 and IE7, and then the span set to display: inline-block fixes IE6 and IE7. So while you do have to add a useless span to your code to get it working, at least you don't have to add another element wrapping each of your elements that contain the centered element(s).

Here's my HTML
<div id="thumbsContainer">
<a href="/photos/1-."><span></span><img src="http://static2.photosite.com/Img/thumbs/1-..JPG" alt="" /></a>
<a href="/photos/2-"><span></span><img src="http://static2.photosite.com/Img/thumbs/2-.jpg" alt="" /></a>
<a href="/photos/3-"><span></span><img src="http://static2.photosite.com/Img/thumbs/3-.jpg" alt="" /></a>
<a href="/photos/4-"><span></span><img src="http://static2.photosite.com/Img/thumbs/4-.jpg" alt="" /></a>
<a href="/photos/5-"><span></span><img src="http://static2.photosite.com/Img/thumbs/5-.jpg" alt="" /></a>
<a href="/photos/6-"><span></span><img src="http://static2.photosite.com/Img/thumbs/6-.jpg" alt="" /></a>
</div>


and CSS:
#thumbsContainer a{
width: 180px;
height: 170px;
display: inline-block;
text-align: center;
background: #333;
line-height: 170px;
margin: 5px;
}

#thumbsContainer a span{ /*To make image center vertically in IE6 & 7*/
#display: inline-block; /*# targets IE6 & 7, best to put in IE only stylesheet served by conditional comments in real use*/
}
#thumbsContainer a img{
vertical-align: middle;
}


After that I had problems trying to get a div to wrap width-wise to its contents. Googling I found various solutions: display: table;, float: left;, display: inline-block;, and display: table-cell;, but none of them worked! I also found a post by someone else with the same problem as me (shrink div to fit contents), but no answers. I'll post a question at the web squeeze and hopefully get an answer there.

Hmm... Firefox is using nearly half a gig of RAM, so I better log off now and might as well go to bed.

The weather today was rainy and slightly foggy early in the morning, then overcast the rest of day. In the afternoon it rained a bit more, and there was even a bit of thunder. Then it was overcast the rest of the day.

Food
Breakfast: Strawberry jam toast sandwich; cup o' tea.
Lunch: 2x cheese on toasts; crunchy salad; apple; satsuma; caramel Rocky; cup o' tea.
Dinner: Chicken & vegetable pie; potatoes; spaghetti hoops; fried sliced mushrooms. Pudding was Lemon pud with custard. Coffee.

No comments: