Bugs are prettier in photos than in code.
I spent a few hours last night (and cleanup this morning) hammering some overdue fixes to pechaflickr, my random flickr + pechaflickr mashup
If you have not played before, you enter a flickr tag, and the site generates a slideshow of 20 random flickr images in pecha kucha style- changing them every 20 seconds; with the advanced screen, you can specify a different number of slides and a different interval between them. This was partly driven by upcoming demos likely at Faculty Academy and definitely June at Northern Voice.
Most of my code fixes are cleaning up my own mistakes, some of which happened last night. What should be taken care of includes:
- The Mystery Images Turning to a White Rectangle should be gone. This was my bad. This actually happened because the code would run out of images. And this happened because of my own faulty logic; I had something in there to try and skip images that were too small The code uses the default “z” sized image (640px wide) and scales the image to 970, and I was trying to use the original image width to make sure we had something bigger than 400pixels. But in debugging I saw that many images from the API lack this original image width value, so often if you asked for 10 images you would get 7, and the rest would be ghosts.
I am fairly sure this is taken care of. I still have to redo a check to skip small images.
- Improved Randomness! Previously, you might see a lot of images from the same person’s batch appearing in the so called random mix. I had one fault in the approach I was taking to sort, I fixed that, and created another issue, and after all, the shuffle() command was doing what I needed on the array of found photos. I am grabbing data on 400 photos at a time,. so there should be plenty to choose from.
Until now, the photo search i was using would like at the most recently uploaded photos; the new element of randomness is that it chooses randomly from one of six sorting options when it grabs photos- by posting date, by date photo taken, by interestingness, and then each of those 3 can either be ascending or descending.
But wait, there is more. I am now tracking the owner of the images, so there will only be one image per flickr user in the mix, avoiding the times when one person uploads 100 images with the same tag (though in hindsight, this might not work if you want to do pechaflickr on your own custom tag, hmmm, might need an extra option…)
- Checking for insufficient number of images The code now checks that there are enough images to start with; the minimum to make a good random pool is 4 times the number requested, so 80 photos to start filtering is needed for a general run. From there, we start skipping photos with portrait orientation (they do not display as nicely) and the dupes by the same author.
This does mean you will want to use tags that are going to have a pretty good number of total photos and contributors. I may have to re-think the dupe owner check.
Other items on the table are adding something to generate a credits screen. I could add a limit to do only creative commons photos, but that will limit it more, and this is for display purposes only. The big thing to add is some way for people to save the sets they get, so they could challenge other people to do the same set of slides. My secret plan is to figure out how to turn pechaflickr into a wordpress theme, and use the WP engine to save the results of one round as a custom-post entry.
Please give it a go, as I will never guarantee a lack of (code) bugs. The image ones? There are over 300,000
