Some Thoughts on the Canon Pixma Pro 100

I had the opportunity to spend a bit of time helping a friend setup and test his new Canon Pixma Pro 100. I’ve been printing my own A3+ (13×19 inch) prints for almost 4 years on a Pixma Pro 9000 mark II, so I was interested to see if the Pro 100 was a worth while upgrade to my Pro 9000 mark II; especially given that there’s currently (until Jan 31, 2015) a $250 or more dollar rebate on the current Pixma Pro printers (1, 10, and 100).

pixma-pro-100-press-kit-photo

The Canon Pixma Pro 100 – Canon USA

While my primary purpose was to help my friend get settled in with his first pro level photo inkjet, I had my own questions. My big question was whether the Pixma Pro 100 would be enough of an upgrade from my Pro 9000 mark II that I should consider getting one while the rebates are running. Beyond that I really wanted to know how the two grays would preform when printing black and whites compared to the single black in my printer.

Read the rest of the story »

Cameras and Flashes; Why not use the same batteries?

Cameras and their batteries have long been a point of annoyance for me. I’ve complained about the lack of compatibility options for Canon’s pro batteries and battery grips. However, that’s a complaint to rehash another time, I want to talk today about the other battery we have to deal with, AAs for flashes.

It didn’t take long to discover that NiMH batteries are the way to go for flashes. Their chemistry proves more current which lowers recycle times, and they generally seem to get more pops than alkaline batteries do. Moreover, since they can be recharged 100s times, they’re considerably cheaper than alkalines, not to mention the environmental benefits of reduced waste.

With some of my ’loops coming up on 5 years old, it’s starting be time to think about replacing them as their capacities start to diminish due to age and use. While doing some research on the current state of the art in low self-dischage NiMHs, I cam across the discussion thread that was the catalyst for this idea. It seems, that Sanyo, the makers of Eneloops, was bought by Panasonic and the current ’loops are ’loops in name but not necessarily performance[1].

That got me thinking about the fundamental premise of powering flashes.

Why do we still use AAs in our flashes?

Why instead, haven’t the flashes switched over to Li-Ion packs? Perhaps even the same ones that are used to power our high end DSLRs.

From a technical perspective, the idea at least passes the sniff test. Four NiMH AAs typically will provide between 9.6 and 13Wh of energy. Comparatively Canon’s LP-E6s or Nikon’s En-EL15s also provide 13Wh of energy plus or minus a bit. At least at first glance, you should get as many pops from the camera batteries as you do from the NiMHs and probably more.

Recycle time is harder to speculate about without a lot more information I don’t have; both on the batteries and the flashes. There are Li-Ion and Li-Polymer packs that can sustain current draws far in excess of anything NiMH batteries can do, but it’s doubtful that Canon or Nikon’s camera batteries are designed for that. On the other hand, if the flash is already limiting the current to what’s reasonable for NiMHs, then there very well could be no different or an improvement in recycle ties with a Li-Ion based solution.

As far as size goes, a LP-E6 pack is longer than an AA cell, but not so much that it’s wider than a Canon 600Ex-RT already is. Likewise, the overall volume and height of a LP-E6 pack is smaller than the quartet of AAs used currently.

Technical points aside, the point that I like the most is the simple elegance of having fewer batteries and type of batteries to worry about. Well at least for users with high end DSLRs.

Okay, I admit this part is entirely personally motivated by my own aesthetic sense of how systems like this should be design. I have a very strong attraction to interoperability for the sake of redundancy and eliminating the necessary extras that come with having to support more parts.

I picked the LP-E6 and EN-EL15 largely because they’re what’s used by the cameras I suspect would be owned by the majority of people interested in a higher end flash. For Canon that includes the 60D, 70D, 7D (mark I and II), and 5D (mark II and III); for Nikon it’s the V1, D7000, D7100, D600, D610, D750, D800, and D810. The really high end users, those with 1Des and D4es, wouldn’t see the reduction in battery types, but they also wouldn’t be any worse off than they are now in that respect either.

All that said, I can see some sticking points. The big one is cost, AA are dirt cheap, even the good rechargeable ones. A single LP-E6 costs more than a 16 pack of good NiMHs. There’s also the fact that you can’t really scrounge the Li-Ion batts like you can AAs. People aren’t going to be keen on lending you a $60–70 battery they might not get back, where they might not care about $5 in AAs. Plus you can’t walk into any number of convenience stores anywhere in the civilized world, and buy a LP-E6; you can do that with AAs.

On the other hand, I’m not sure the disadvantages outweigh the ability to shed AAs and their chargers, or the potential for increased redundancy in spare battery capacity and compatibility that comes from having everything run from one type of battery.

I think this is a good idea, but I’d love to here what you think. If you see some flaw that I missed or think it’s a neat idea too, leave a comment below.


  1. As I understand it, when Panasonic bought Sanyo, due to anti-trust concerns, they got the brand name, but not the manufacturing facilities where the eneloops were made. Instead Panasonic appears to be transitioning the Eneloop brand to their production facilities in China. According to at least one user test these batteries don’t preform like the eneloops of just last year.  ↩

Angry Sky

A building thunderstorm in the late afternoon light.

A building thunderstorm in the late afternoon light.

September Lighting

Three images of lighting, the best from last night’s storm, and on some level some of the best I think I’ve ever shot.

September Lighting 1

September Lighting 2

September Lighting 3

Gear Bits

I’m currently neck deep in writing a review for Canon’s 5D mark III–yes I know, I’m a bit late to the party, especially since I’ve had one for more than 2 years now–but in the meantime there were a couple of nifty bits of gear I wanted to talk about and get the word out on.

The first up is Peak Design’s Anchor Links. Camera straps are a pretty big frustration for me. I vacillate between needing a strap and not wanting one, and I do this often enough that quick release systems are the name of my game. The problem with most quick release straps is that the tend to leave big bulky ends on fairly long tails attached to the camera.

For the past 2 years or so, I’ve been using Optech’s Mini QD Loops, which I reviewed. It’s nice, it’s small, the only problem I have with it is that it feels incredibly flimsy, even though it has a 50-pound break strength (and I’ve tested mine to close to that).

Last fall I was involved with a discussion on line that led me to Peak Design’s camera straps, but more importantly their QR strap system. It was everything I wanted in a strap QR system. It’s small; but more importantly, the reinforced cables are rated for at least 200 pounds.

I had contacted them at the time to see if they were offering just the quick release bits instead of having to buy their whole strap. Sadly last year they weren’t. Now, that’s changing. Currently they are offering the strap anchors through a Kickstarter campaign (ends August 15th), then they’ll be going on sale through their website in general.

I’ve preordered 2 sets, which according to Peak Design’s Kickstarter page, I should get sometime in late October. I really hope these are all that I imagine them to be, as they really do look like the solution to my camera strap frustrations.

The second item I want to note is 3D Printed Idea’s updated bayonet adapter for Lee filter holders. I reviewed the first version they did, which I generally approved of, but it turns out after I had published my results, they discovered some issues with the all 3D printed construction, and subsequently pulled them from production.

In the meantime, they designed an all-new adapter, this time for Lee’s holder design, which I consider to be much better than Cokin’s anyway. The new design utilizes an aluminum outer bit with a 3D printed mount adapter.

I’ll be writing up a more detailed review and test of the 3DP Idea’s adapter in near future, but suffice to say I’m even more impressed with this design than I was with the previous one. So much so, in fact, that I’m shelving the 3D printed holder slots I was working on since this adapter provides the same capabilities (3 slots on a 16mm full frame lens, without vignetting or having to remove a protective/UV or thin polarizer filter) for about the same cost in a significantly more robust way.

3D Printed Idea’s Bayonet Adapter for Lee Holders

Peak Design’s Strap Anchors

An Argument Against Future Proofing RAW Files

I see this question come up with some frequency on various discussion forums. What format should I use to future proof my digital images. The answers of course vary from JPEG, to DNG, to TIFF or PNG. Very rarely do I see someone who responds with don’t do anything, which is exactly what I recommend.

This may sound shocking, but let me explain. There are two broad aspects as to why I don’t recommend messing with your digital negatives now for future proofing reasons. On one hand, there’s the technological and technical side of digital storage and computers; on the other, there simply the time aspect.

Let me start with the time aspect. Doing anything that involves converting RAWs now is a waste of time for two reasons.

First, is that it’s simply not a foregone conclusion that the manufacturer RAW files will become unreadable. A lot of DNG proponents like to play up the fact that DNG is an open standard and the proprietary RAW formats aren’t. They argue that because of that a DNG can be expected to be readable at some arbitrary point in the future. While that’s true, it ignores the reality that by far the vast majority of manufacturer RAW processing implementations were written by reverse engineering the RAW files themselves and not by using some manufacturer provided library. So long as people still understand graphics processing and statistics, there will be people who can understand converting a Bayer pattern blob into a usable bitmap image.

Moreover, even if it does become necessary to convert to another RAW format at some point in the future, the realities of the progression of technology suggest that doing so at that time will be faster than doing so now.

The second aspect is relates to the realities of digital storage media and the progression of technology. It seems to me that many of the people talking about future proofing their RAWs, are really looking for the digital equivalent to being able to stick slides in an archival container in an archival vault and not think about them for 50 years.

The simple realities of digital storage are that the media degrades and the devices to read it become obsolete and disappear. Long-term digital storage is more about moving data to new media in a controlled way than leaving it alone in a vault somewhere to degrade into uselessness.

Also, it’s important not to forget the management of the physical media involved. Newer media has higher storage densities, meaning you need fewer disks or tapes to store the same amount of data. The counter point is that with more data in fewer containers the loss of a single container means losing more data. That said, if you can consolidate 4 disks or tapes of data into 1, you could keep 2 duplicate copies and still have fewer disks or tapes to keep track of while having more redundancy in the system.

Given the realities of progress, it’s not hard to envision a scenario where the files on an archived disk are still readable in current software, but the disk itself can no longer be read.

The final point I want to make is that simply future proofing the RAW files doesn’t future proof the rendering of the image. What I mean by this is that the conversion from RAW data to a usable image that we can see as intended is as much a product of the software used to convert the image, as it is the data in the file.

We’ve already seen such changes in rendering in software like Lightroom. The 2010 process introduced a much more advanced rendering engine, producing better fine detail with better noise reduction, and different controls. Files updated from the 2003 process to the 2010 process not only looked different, but in some cases, couldn’t even be made to reflect the output of the 2003 process.

If there is a concern that the image might change, then it’s not enough to simply be able to read a RAW file in the future, but as much concern has to be given to it being processed under the same engine in the same way as it was in the past.

Instead of worrying about future proofing RAW files, I find it’s much more important to worry about insuring that you have the files to work with in the future at all. This means worrying about backups and data integrity. Both of which are topics that warrant a post or more discussing.

Offline Tools

Mobile Tools

I started writing my JavaScript tools to provide me with solutions to problems I had. My depth of field calculator started out as a quick way to get 1/8-depth of field values that I needed for building an autofocus target. It grew from there in to a way to compare lenses across platforms with an eye towards maintaining a fixed composition, i.e. the same angle of view and depth of field. One thing that’s always slightly annoyed me with these tools is that they only live online.

The trouble is, developing applications for mobile devices (phones and tablets) is quite a mess. The 3 major platform all use different environments, APIs, and programming languages; Microsoft uses .NET, Apple uses objective-c, Android uses “Java”. Of the three options I have the most experience with .NET, but as a user I have Apple’s iOS based devices. Even then there are associated costs with bring an app to market on any of the respective platforms. Never mind which one do I target? Apple’s iOS because it’s what I use, or Android because it’s the most popular? Or do I try and find a cross platform toolkit of some kind?

Thanks, but no thanks.

There is another option, HTML 5. All the mobile phones support HTML 5 at this point, at least in the browser, if not though some mechanism that frames the “app” as something more “native”. And HTML5 supports an offline caching mode that can store all the relevant files on the device so the app works when there’s no internet connection. Okay sure, the experience isn’t quite as good as a native app, but right now that’s a compromise I’m willing to make for the sake of getting things done. Moreover, since my tools are already entirely based on JavaScript and HTML 5, it’s relatively painless for me to port the existing tools and roll out new ones as I find things I need.

Which brings me to why I’m posting this. I’ve rolled out the first early release of my offline capable HTML5 tools. The first tool is a direct port of my depth of field and equivalent lens calculator. It uses the same underlying code as the existing tool, it’s just packaged up so you can book mark it (or if you’re an iOS user, add it to your home screen), and use it anywhere any time you need it.

I still consider this to be a beta class product, as I’m still rolling out the documentation and refining the functionality. It’s currently been tested in iOS 7.1 and should support running as a full screen app. Simply visiting the site should download and cache the content required to run the application offline. Help and other documentation is still missing but is on the to do list.

Click the button below to go to the mobile tools landing page.

Mobile Tools

Waxing Gibbous Moon, March 2014

March 2014, Waxing Gibbous Moon - Working on some test images with the EOS M and 100-400 in preparation for the April 15, 2014 Lunar Eclipse.

March 2014, Waxing Gibbous Moon – Working on some test images with the EOS M and 100-400 in preparation for the April 15, 2014 Lunar Eclipse.

Script to find and Delete JPEGs form RAW+JPEG Pairs

Documentation

The other day, a friend of mine trying to free up some space on their computer asked me if I knew how to delete the JPEGs from a RAW+JPEG pair in Lightroom. After scratching my head on that for a while, I threw together a Powershell script to do the job, and so I’m sharing it here in the event it might be helpful for someone else.

WARNING: Advanced computer stuff ahead.

This script is for Windows and requires Microsoft’s Powershell environment to execute. I’ve tested it in Powershell version 3 on Windows 7. If you don’t have Powershell installed, the latest version can be downloaded from Microsoft.

To run the script, place it in the top-level directory of the directory tree where you want it to scan; right-click on it and choose “Run in Powershell.” The script will prompt you before running whether you want to just build a list of files to remove or delete them. I recommend not deleting files on the first pass, just to be safe as the deletions done by this script aren’t reversible.

The script considers a JPEG to be part of a RAW+JPEG pair when the files have the same name but a different extension (.nef, .cr2, or .dng for raw, and .jpg for JPEGs), and exist in the same directory. The script recursively scans through every child directory starting from the directory the script is executed from looking for RAW+JPEG pairs.

Results are always logged to raw&jpeg.log in the same directory as the script itself.

Due to the nature of the process, the script can take some time to run, and doesn’t display progress unless it finds matches.

I recommend running the script and verifying that the files it’s selected to delete are in fact RAW+JPEG pairs, before deleting them.

This tool is provided without warranty or support.

Download: Clean RAW+JPEG JPEG.zip