Fro Knows Photo critiques

Much to my surprise, I’ve actually started following a few channels on YouTube. It started off with me looking for bass covers of my favourite songs, and then I began to discover a few photographers (sometimes via Instagram) and found myself idly watching their channels too. I soon stumbled upon the channel of Jared Polin, aka Fro Knows Photo, and found myself drawn into his fast-talking and highly opinionated videos.

My attention was mostly drawn by his Rapid Fire Critiques, short segments where viewers send in a small portfolio of ten photos for Jared to look over and give his on-the-spot reaction. His blunt responses elicit quite a few comments, a lot of them negative, mostly wondering why he’s being so harsh, or that his opinion is wrong, or that he’s an idiot (and so is the commenter above), etc etc. You know how it is with comments on the Internet.

In my view, his reactions come across as brutally honest but not malicious. He’s very quick to praise good photos, and offers (mostly) helpful suggestions for improving technique and getting the best from a given camera. (One area where we disagree is that he seems to prefer photos to appear online in their original aspect ratio: but that’s a topic for another post.)

But what the commenters seem to overlook is the fact that he’s not going out and finding random stuff to tear strips off; these are meant to be portfolios of the ten best photographs that each photographer has invited Jared to critique. Think about that: of all the photos that someone has taken, they’re invited to send in their ten very best.

I’ll just reiterate that point: their 10 BEST photos. And in my opinion (for what it’s worth), most of these photos are just plain awful, with poor (over)processing being the number one flaw (indifferent subject choice and composition come next). Camera equipment makes no difference, other than allowing an experienced photographer to capture things with more expensive gear that cheaper equipment might not be capable of. (And the likelihood is that experienced photographers don’t need a live, online critique of their work.) Indeed, a point Jared repeatedly stresses is that you don’t need expensive, top-of-the-line gear to get good photographs: almost any entry-level SLR and lens (or, more generally, ILC) is capable of producing excellent images, especially for online display.

Some might suggest that he picks and chooses which to criticize to make an entertaining video, but I don’t think he needs to do that. As I hinted above, I suspect there is a selection bias at work here too: “good” photographers aren’t interested in such a critique. They’ll have already learned what it takes to get a good photo (though good composition can still be ruined by over-the-top processing). I guess it’s photographers who are still learning, and have enough confidence to show their work, but mostly haven’t yet learned what a “good” photograph is or is not.

Now, I don’t claim to be an awesome photographer; I use entry-level gear and I try to make the most of the fact that I live in a beautiful part of the world. Most of the photos I take are what Jared (rightly) calls snapshots, and I know this. Very rarely have I looked at a scene, identified a composition, waited for the right light, and set about taking the best photograph I can. But I do think that 15+ years of taking snapshots has allowed me to identify what it takes to get a good snapshot 🙂

Mind you, I’m a real stickler for a level horizon…

Advertisements

Recovering MySQL after improper shutdown

As an amateur DBA I recently made a classic amateur DBA mistake: I restarted my computer without first shutting down MySQL. (The restart in this case was the result of updating macOS to 10.12.4.) After the reboot I couldn’t work out why XAMPP wasn’t launching MySQL again – apache started up fine – so it was time to dig into the log files.

A quick check of var/mysql/hostnameredacted.local.err in the XAMPP installation directory revealed a string of errors and a stacktrace. Reading it carefully I realized the key error message was this:

InnoDB: Operating system error number 2 in a file operation

The other clue was a few lines earlier in the logfile:

InnoDB: Database was not shutdown normally!

As ever, Google to the rescue which led me to a handy blog post which suggested adding the following line to the [mysqld] section of etc/my.cnf:

innodb_force_recovery = 1

I saved the file, and held my breath as I attempted to restart MySQL. Success!

I went back and removed that line again (actually just commented it out – there’s an outside chance I’ll repeat this error at some point in the future!) and re-restarted MySQL. Firing up SequelPro and I was relieved to be able to see all my tables as expected, and ran a few test queries to check it out. Everything looks OK. Phew!

Lesson learned: remember to shutdown MySQL properly before a reboot.