[CauseISaidSo]

Yeah, it’s something I can work with. It’s a little work but not too bad. Just a matter of finding the time now…

[CauseISaidSo]

Been to Yellowstone twice, but it’s been 30 years so I can’t really offer any specific photo advice. What I can offer is my profound jealousy of you both. 😉

I’m looking into taking my boys skiing at Jackson Hole this winter and doing a 2-day snowmobile trip through Yellowstone while there, but it’s still in the very early tentative planning stages, so we’ll see.

[CauseISaidSo]

FYI, I’ll be off grid/incommunicado for the entire duration of this contest. Haven’t had any problems recently with the scraper and don’t anticipate any this time, but if so, I won’t be able to address it until just before the next contest.

Really hoping to be able to get back into the contests in a couple of weeks. I’ll have missed 8 in a row by then, my longest time out ever. 🙁

[CauseISaidSo]

That’s terrible news, rav. I’ve heard nothing but that those bones are quite nasty to break (not that any breaks are a joy, but those in particular are said to be exceptionally troublesome). Best wishes for a speedy, full, uncomplicated, and as painless-as-possible recovery!

[CauseISaidSo]

Does anyone else have a hard time voting for these particular contests? These types of contests seem to be more about what cool/odd/different types of sign you can find and less about photography skill.

Yeah, there are some themes that fall right into that description, for sure. I try to separate quality from content when voting, but I don’t think most voters do.

[CauseISaidSo]

Yugoboy, I can OBO for you on those dates unless you want to hold out for a TF offer. With any luck, I may be able to get back into entering myself by then, too.

[CauseISaidSo]

My deepest condolences, Yugoboy, to you and your wife.

[CauseISaidSo]

I can rescan old contests, but we don’t want to convert those links to the cached version because the cache URLs change periodically (I think I read somewhere that it was every 15 minutes) specifically to prevent hotlinking. That’s why clicking on a thumbnail on Bibliostats from contests #418 forward (except for the active contest) takes you to a Fark 403/forbidden page – the URL for that image that was scanned at contest close has changed and is no longer valid.

So, if I replace the existing URLs in old contests with the cached versions, all pop-to-original will stop working, even for older contests where it mostly works now (except where the original has been deleted).

But that did spur a thought on the suggestion of using hashes. Elsinore, can you ask Mike if images are re-saved to jpg when being cached or if they’re copied as is? In other words, when Fark caches in image, does it cache the exact image from its source or does it use an imaging library to reconvert the uncompressed image to jpg?

If it re-converts to jpg or otherwise does anything to alter the image file, then the hash for the cached version wouldn’t match the hash for a repost of the original image and thus no scarlet R checking. That’s the nature of hashes – they’re designed to produce significantly different outputs in response to tiny changes in input.

[CauseISaidSo]

Pop-to-original works while the contest is live (as long as the original image is pre-scaled to Fark size), but once the contest ends and the links are changed to cache URLs (basically the last pass that the scanner makes), it becomes broken. Click on the thumb for any image from contest #418 forward (except for the current live contest) and you’ll get directed to a Fark 403 page.

[CauseISaidSo]

Yeah, that’s a possibility. It would mean rescanning all prior contests to calculate the hashes, and of course any entry that has since dropped off wouldn’t get calculated. Then again, if the entry has dropped off, it’s not going to be reposted under that same URL anyway, so that’s not really an issue.

I’ll look into it, but it’ll be a couple of months at least before I can do anything about it as I’ve got a lot on my plate right now (hence the lack of recent participation :().

Edited to add: It also doesn’t solve the pop-to-original-from-thumbnail breakage that occurs with the cached URLs.

[CauseISaidSo]

Just FYI, Bibliostats picked up several Scarlet R’s this week, so is that feature working after all despite the Fark cache thingy?

Yes and no, but you’re mostly correct on your speculation.

Since most images are posted pre-scaled to Fark sizes, they’re shown on Fark with their original URLs instead of the cache URL. So, they can be checked against other contests that used the same URL.

But, once the contest closes, all original URLs are converted to cache URLs which are worthless for checking reposts. So any contest scanned after caching was implemented cannot be used to detect reposts.

Basically, reposts will be detected if:

• The image is already pre-scaled to Fark sizes; AND
• The original post occurred in a contest prior to caching implementation.

Caching implementation started with contest #418, so reposts can only be detected in contests 417 and earlier.

[CauseISaidSo]

Something odd is going on then… The URL that I uploaded into a posting didn’t work in a browser, but the Fark entry was still showing the image.

Yep, that’s why I modified my theory. Once Fark detected that your image went missing (the URL that didn’t work because you deleted the image), it replaced the bad (original) URL with the one that points to the cache, which means that Fark has to cache everything immediately after it’s posted.

But, to explain what I see, Fark doesn’t use the cached image unless or until:

1. The original image exceeds the Fark size limits
2. The image goes missing (like yours)
3. The contest ends (after which all images are replaced with the cached version)

[CauseISaidSo]

Sorry to disagree with ya, Choc-Ful-A, but I’ve got the image sources right in front of me and they’re all from the original hosts. For example, here are yours:

• http://cnamejj.smugmug.com/Photography/Places/Mendocino-2012/i-dd272pM/0/X2/dsc_0105-cr-ad-X2.jpg
• http://cnamejj.smugmug.com/Photography/Farktography-2013/Waterscapes-2013/i-hQKLsR8/0/X2/dsc_0276-cr-ad-X2.jpg
• http://cnamejj.smugmug.com/Photography/Farktography-2013/Waterscapes-2013/i-F5dkMvD/0/O/dsc_0030-ad-W850.jpg

Based on what you saw, though, I’d probably revise my theory to guess that they’re cached immediately but that the caching URL isn’t used unless the image goes missing or until the contest ends.

[CauseISaidSo]

Fixxor’d. GoDaddy moved me to a new “and improved” server a couple of days ago and evidently something changed. Fortunately, it was a quick fix.

[CauseISaidSo]

Well, from my observations over the last few weeks, I think this is how it works:

• Before and during the contest: When an image is first posted, if it’s already scaled to Fark sizes, it’s posted with its original image link; otherwise, if the image has to be resized, it goes straight to img.fark.net.
• After the contest closes: All images are cached and links converted to img.fark.net links.

You can see this behavior by looking at bibliostats now. All of the thumbs for this contest should pop to their original source, which means everyone’s posts must’ve already been Fark-sized. Once the contest closes, those will all change to img.fark.net links and those links change periodically which means the bibliostats links shortly go to the Fark 403 page.

I could modify the scraper to keep the original link from when the contest is live and ignore the changeover to the image cache, but that’s a little bit of work and it still wouldn’t address non-Fark-sized images that go directly to the cache.

I think the ideal solution would be to get Mike to put the full original link in either the alt or title attribute of the img link. Right now, those are set to just the domain of the image host and they’re also changed to “img.fark.net” when cached.

[Author]

Posts