For a third kid, Daniel’s doing ok in terms of the amount of photos he graces. Of course, he’s in the terribly cute early mobile stage, which means his poses are ever so photogenic – and ever so brief…
Here are the photos, at the usual place.
For a third kid, Daniel’s doing ok in terms of the amount of photos he graces. Of course, he’s in the terribly cute early mobile stage, which means his poses are ever so photogenic – and ever so brief…
Here are the photos, at the usual place.
They’re at the usual location, with the usual accreditation.
Hot on the heels of the videos we have more photos, too, in the usual spot.
I made these with the Adobe Photoshop Elements batch processing feature (to resize them) and the Beneton Movie GIF program. The files are huge and may take some time to load, but they’re fun. The photos were taken September 25.
Daniel’s fourth month is now up in the usual place, though Vivienne’s black eye sort of steals the show…
We’re up to three months of Daniel’s life now with the photo albums up at the usual place. I’m hoping to get his fourth month up shortly.
This time, we’re up to half Daniel’s age today. I hope having 160 photos in the album won’t slow down the viewing experience!
…finally. They’re from Daniel’s first month, which is three months ago. Oops.
They are in the usual spot, with the usual credentials. If you lack them, ask me.
I just tried what Marty recommends in his tutorial video, and it also mostly works in Photoshop Elements 11. The density adjustment doesn’t work as described, but I used it instead to bring out eyes and mouth; changing to white in the foreground allows some density reduction. Here’s what it looks like on a photo of mine:
There’s a new album up, accessible from the usual overview link. I’ve changed a few things about the overview, which will not affect those who just check out the latest album. The changes will, however, affect those who want to look up old albums for old times’ sake.
The technical reason for the changes is a server-side limitation on the number of requests per minute, a limitation which serves as a simple, but effective block against bots that try to hack a login or take the server down by requesting large amounts of data over and over. Showing over 50 album thumbnails on the overview seemed like an unnecessary number of requests, so I’ve split the overview into an archive containing albums 000 to 040, and the familiar overview with the more recent albums and a link to the archives at the bottom.
The overview of current photos works as one would intuit; it’s in the archives that things start to go a bit pear-shaped. The albums themselves have an absolute URL for the link “All Albums,” so if you’ve gone into the archives and picked an album, only to discover it’s not the one you wanted, “All Albums” will take you back to the current overview, not the archive overview. Because I didn’t want to redo all the albums, my workaround was to change the archive overview to open a new window or new tab (depending on your browser settings) for every album you select. That way, the overview stays in its own window/tab, and you can just close the tab to leave the album.
Now, I’d be surprised if that was the only oddity, and I know that the request rate limitation can run interference with larger albums such as that of our 2012 US vacation; when I tested it today, the thumbnails loaded in part, paused, and loaded in full after a few seconds. I’ll try to keep albums small, but that won’t always work. Please inform me of strange behavior and buggy stuff!