I’m trying a new concept this week, in which I highlight theoretical, prototypical, or early stage beta ideas that we’re thinking about behind the scenes. While I can’t always talk about the latest projects we haven’t released, I do many thought experiments each day, some of which yield interesting ideas. I’ve been jokingly calling this “QS Labs”, since it’s where we try to develop some next- level tools for Magic players, traders, and those in the industry. I’m hoping to open up dialogue on how to use technology to improve our lives as lovers of this game, and these pieces will be largely theoretical. We may very well have advanced prototypes working behind the scenes which we cannot speak of in public, but for all intents and purposes, treat these ideas as one big “wouldn’t it be nice if...”

The problem I wanted to tackle with today’s thought experiment stemmed from the mind-numbing task of sorting and inventorying cards. MTG Online solves this problem, but for those of us who own physical paper cards and don’t intend to make the total conversion to digital, it’s a problem that will always exist and grow with our collection. Now, you could practice reducing your collection by 80% every so often, employing the Pareto Principle, and in fact I suggest doing this very thing in a piece I wrote for ManaNation that’ll go live on Thursday. Short-term, this is an awesome way to keep your sorting needs low. But I wanted more, so I dug deep into my brain and asked how I could remove the need for sorting altogether. I wasn’t going to allow myself to outsource it for this experiment, though most people could easily do so. That would’ve been pulling the parachute too early. No, I wanted to completely obsolete the need to sort cards.

The first thing that sprung to mind was, “wouldn’t it be nice if my computer just knew what I had at all times?” I agreed with myself out loud, “Yes! That would be amazing! Too bad a computer has no idea how to do that.” My mind reeled with the potential. If we assume that we can teach a computer to recognize cards (without worrying about how), a new world of possibility opens up to us. After all, computers can recognize far more complex structures than a 2.5x3.5 inch rectangle with predictable angles and patterns. I had to assume this was doable. It’s out of my skillset to implement, but it’s doable. The question became, then what?

Once a computer can recognize a Magic card, a new world opens up. Right now, we sort Magic cards in a way that’s meaningful to humans, similar to how we organize our paperwork into files in a cabinet. The physical storage medium (paper) defines the shape of the container, the accessibility, and implies a need to group similar items together. When you need to see last month’s profit and loss statement, you go to the 2011 cabinet, the March folder, and the P&L sub-folder. You pull the report, and you have it.

The problem is that, unlike chronologically generated reports, you can easily acquire a large quantity of Magic cards that are, theoretically, totally random, at any given time. I sort Magic cards faster than damn near anyone I know, which is a really lame superlative, and it still takes me about an hour per thousand cards to get them sorted as I like. The truth is, I waste so much time sorting that I’m about ready to forswear paper cards altogether. Managing physical inventory sucks eggs. Then you have the problem of display-based sorting (think about trade binders), correlating human accessibility with the sorting mechanism and perhaps even in accord with how your eCommerce site organizes the cards. It may make more sense to you to organize by rarity first, but your eCommerce inventory page might sort by Alphabetical first. It’s madness.

Once a computer can spot a Magic card on sight, all this trouble disappears instantly. We are assuming that we have technology that can, at a glance, snapshot a card, compare it against a database of known cards, and output the results. Here’s why I’m so excited. Assuming it takes me an hour to sort a thousand cards, and I process 100,000 cards a month, I’m looking at 2 very painful weeks of just sorting and processing cards. To hell with that. We’ve all got better things to do than neatly arrange piles of cardboard and work on our Carpal Tunnel syndrome. I’d rather sit in the park and read a book. We don’t have to build a perfect system here, we just have to build a system that lets us process 1000 cards faster than a human being without much intervention.

I For One Welcome Our New Robot Overlords

How can we kill that hour sorting time per 1k cards? Easy. Just don’t sort them. Problem solved. Thanks for reading!

Naw, just playin’. Solving one problem by creating another is often a great way to come to a solution. It’s also a great way to piss off parents and teachers as a schoolkid, but the practice has served me well in my adult life up until now. If we challenge the assumption that cards must be sorted to be accessible, we find a nice little glitch in the matrix. Humans need logical hierarchies to access data, much like the file cabinet example above. Computers don’t. In fact, it’s often less efficient for a computer to store it in a means that is accessible and structured to suit human access. I have never once organized my Google Documents, where I’ve been storing articles, concept designs, notes, and almost anything else relevant, for two years. Not once have I organized it. I can still find everything, since it’s indexed. I type in “QS” and it shows me everything related to QS. I don’t care where they store it. I don’t care what folder it’s in. I care that it’s about this here website, and as soon as I ask for it, I get it. I want to do that with physical cards. When your computer stores something to RAM (Random Access Memory), its location is irrelevant, just as long as the computer knows how to tell the assorted programs accessing RAM where to look for what they need. In our case, it is a human that needs to know the “address” of a card rather than another piece of software.

When you can give your computer a pair of “eyes” in the form of cheap webcam camera circuit boards and teach it to spot Magic cards, you can get the data you need. I have a few hardware designs in my head that will work in tandem with this hypothetical software to process stacks of Magic cards quickly. I’m not quite ready to build prototypes, but the hardware is rudimentary and can be made from spare parts at an electronics store. A hardware device controlled by the software will flip through the cards, scanning each in front of the camera and placing the card into a stack after scanning. This output stack will be identical to the input stack. The computer will then be able to record each card’s position in the stack and identify the card itself. Once the card is identified, all the remaining information about it is preloaded. If the computer knows “ CARDNAME = “Avalanche Riders”, then the computer also knows everything about the card that is on the Internet (as long as we tell it who to ask and where to look).

Here’s where we bring it all together. You take your thousand-count box full of random cards and feed it through the machine. You can then get a report of the contents. From there, you can do all kinds of fancy data processing, the least of which starts with inventory and card valuation. Perhaps you could even teach a high quality camera to approximate card grading! To me, the most valuable piece of information here is the card’s location in a box. It’s pretty easy to look at a stack of boxes, sorted by set and alphabet, and find a given card. It’s pretty hard to find a given card in a bunch of totally random boxes. There’s so much labor in setting up the former, but accessibility is a breeze afterward. The latter is horribly inefficient for human access on a per-event basis. Once you have the contents of the box stored in a database, you can give the boxes names or numbers and, in doing so, give the computer yet another way to specify the location of a card. Effectively, you’ve developed a coordinate system for your cards!

Let’s assume you have 10 boxes of 1000 cards, all of which are totally random and have been indexed by our software. They’re labelled BOX1 up to BOX10. In each box, there are about 1000 slots. These slots can be delineated by colored separators after every x cards, by dividers in the box, or however else suits your fancy. I like the idea of colored markers every 20, with a different color every 100. 20 cards can be gone through in little more than a glance.

Once you have a coordinate system, you can use it to find cards. Let’s say you’re looking for a Tezzeret in your recently-acquired collection, which is largely unsorted. After automatically indexing it with image recognition software (while you go and do something productive and profitable) and querying the database, you find out that there are two Tezzeret, Agent of Bolas somewhere in the boxes and you need one right now. You have a few options:

A) Sort all 10,000 cards. This will guarantee you find a Tezzeret, and it will set up further queries to execute MUCH faster, since all subsequent queries will require almost no sorting. Unfortunately this is not terribly efficient, and we really want to avoid sorting cards at all. This is the frontloading of effort we want to avoid.

B) Dig until you find a Tezzeret. The statistics aren’t on your side here. You’re looking at long odds, and even though you could potentially go through 9,998 cards before finding your query result, you’ll still be no closer to solving your next query and you’ll have wasted a lot of time. This is where the drawback of human access on an as-needed basis kills us.

C) Ask the computer where the hell it put the card. Wait, what? Well, if you ran the cards through the indexing software, it would know the exact location of every card it’s seen. Thus, if you scan 10 boxes of new cards upon receipt, it can spit out a coordinate pair (or two, since there are two in the collection) and tell you precisely where to look. It might look something like this.

Tezzeret, Agent of Bolas | 2 In Stock | Loc: B4-473, B7-135

Remember, all we care about is that we need a copy of this card right now. We don’t care about building infrastructure, sorting cards, or anything like that. Our only need is this card, as quickly as possible. Well, it should be fairly academic given those coordinates. We can go to Box 4, look for the separator that marks the start of position 500, and just grab the chunk preceding it. In those ~30 cards will be our Tezzeret. Time expenditure from “problem” to “solution”? Maybe five seconds, at most. Run the query, pull the box, flip to the number, and you’re done. What if your buddy accidentally took Box 4 to a tournament this weekend. Wel, If Box 7 happens to be more handy than Box 4, just grab it instead , and get the Tezzeret instanced at B7-135. Why is Tezzeret in B7-135? It doesn’t matter. That’s where it is, and you will always know exactly where it is, regardless of how little sense its position makes to the human eye. You just get the card you want without concerning yourself with infrastructure or sorting whatsoever.

The best part is that inventory accuracy is enforced. As soon as you query a card, you can easily indicate that you have removed it from its position in its box. Removing Tezzeret B4-473 will cause all cards from B4-474 and higher to shift down a position automatically. No remembering what goes where. As far as the computer is concerned, the card which was occupying B4-474 is now occupying B4-473, no matter if it’s another Tezzeret or a Beast Hunt (which should have been filtered out by your bulk filtering algorithm, you lazy bones!) You don’t care, because you only access the coordinates when they become relevant to you rather than assigning them manually by a traditional sorting process. As cards are removed from a box, all the numbers adjust accordingly as long as the user marks the card as removed. If you screw up badly enough, just run the whole box through the scanner again. Then you’re guaranteed accurate information. Heck, if the scanner is fast enough, you can just run a few boxes here and there during your work day and always be assured your inventory is accessible and up to date.

As this system scales, the entire nature of the beast changes. Finding one card is a breeze since you have exact coordinates, but when you need to pick multiple orders, it becomes a pain. The best part about a sorted box of cards is that you can just as easily grab all of a card as a single card. The need to do so usually only arises when you’re moving around an entire sorted box, such as moving all of Zendikar to a larger container. There are a few ways to tackle this problem. First, let’s say we have 100 copies of Pyromancer Ascension, spread over those 10 original boxes and we need a playset of them. That should be pretty easy, since there will probably be 10 per box. Just run the query, and tell it you need four copies. It can automatically show you the 4 closest-together instances of the card. If there are 3 copies in B3, it will show you all 3, then it’ll show you the copy in B4. Rudimentary AI can handle this task, and by doing so, you optimize the “random” access that a human being must perform. What if we need all of the copies? That’s the only time in which this becomes truly inefficient, but considering that the majority of queries are not for all copies of a card, the tradeoff is worth it. Remember, the alternative is perfect sorting which takes ages.

Even when it would be faster to pull the 100 copies from a sorted box, having a specific instruction set that reads, “Go here, grab these, then go here, repeat” is a dream for any entrepreneur. You can hand those instructions to someone who knows nothing of Magic and they can execute them flawlessly. They can read the card name, or better yet, match an image of the card which has been cleverly printed on the coordinate sheet!

When you have multiple different cards to pull, it gets really fun. You can apply the same logic of “nearest neighbor” across cardnames. If I need the whole Pyro deck, my system can show me where the Pyromancer Ascensions are, and where the closest Preordains and Halimar Depths are relative to each other. It can optimize the order in which I go through the boxes and guide me to specific locations in each box where the needed cards live. Once one gets the rhythm of scanning these boxes by coordinate, it can go far quicker. If there are 4 Preordains and 4 Halimar Depths in a box, the software will guide me to that box since it has a great depth of query results within. If another box also has the same 8 cards, the software can easily see which is less “fragmented”. If we have a box in which all 8 cards are dispersed randomly throughout the box, but another box (the remains of someone’s collection) has each playset intact, the software’s AI will of course guide you to the better “organized” box. Accidental organization, as I will discuss shortly, is hard to control but it’s a random factor that appears often enough that it’s worth accounting for.

The entire system is built on maximizing efficiency of repetitive tasks while accepting that a small subsegment of tasks will remain inefficient or will actually get harder. Considering the time saved on the common tasks, I believe this will be an effective compromise.

There’s no reason the system can’t scale, either. If you have 1,000,000 cards in 1k boxes, you’ll have 10,000 boxes. That’s enough to take up a large room easily. You can keep adding hierarchical layers to your sorting tree once you’ve hit a number of boxes that cannot be easily addressed. Once you have defined a box as an encapsulated unit, you can then start building units that contain multiple boxes, like shelves. Multiple shelves fit on a bookcase style rack, multiple racks fit in a row, multiple rows fit in a room, and many rooms can fit in a warehouse. From there, you can simply replicate warehouses and scale to infinity. It’s conceivable that your coordinates will read WH3-RM4-ROW1-RK3-SH5-B2-423. Yep, that’s hell to try to memorize, but if you’re dealing with so many cards that you have three warehouses of the things, a string of digits like that will probably be a welcome simplification to whatever sorting system you have now. Let’s stick to the single-room realm for now to keep things simple and realistic. That’s still millions of cards, which is daunting to a human doing inventory.

What happens at that scale, though, when cards can theoretically exist very far apart? It seems bad to need to walk from one end of a room to another to get the second copy of a card since you’re working off of random access. It works for computers because the hard disk platters spin many thousands of times a second and the drive head passes over each area quite fast. Hard drives are also considerably smaller than warehouse rooms. It doesn’t quite work in the same way as this system scales up, so we need to introduce scalable ways to combat scaling! The answer lies in binary sorting, which can be done by a machine (as opposed to perfect sorting which would be difficult to build into hardware).

Binary sorting is the act of splitting a set of data into two groups based on a single yes/no query. I usually begin my perfect sorting process by doing a few binary sorts to reduce the space in which I’m working. Look for a characteristic of a card that can be measured in “yes” and “no”, and one in which the two answers are as evenly distributed as possible. I find that sorting New/Old border style works amazingly for this, since it should cut a randomly distributed set of cards almost directly in half. Granted, older cards are tougher to find so it will be well skewed towards newer cards, but it is still the most useful and easy binary sort to perform.

Each binary sort should, in theory, cut the working problem space in half while introducing a new unit of divisibility. Thus, if the size of your inventory doubles, you can perform a binary sort using automated hardware to keep your maximum “fragmentation” the same. Let’s say we have 2 boxes, but we want to double the chance that we can find multiple copies of the same card in a single box. Sort it binary, and you’ve cut the potential locations of that card in half. Apply this to 10,000 boxes and you’ve eliminated 5,000. Apply another layer of binary sorting and you’ll cut it in half again, albeit with the upfront work of doing 2 fairly quick sorts. Again, this is yet another compromise that will work better than blindly sorting every card that walks in the door. It’s the most minimalist version of sorting around, and considering how well it scales against large quantities, it’s about the best we have when it comes to balancing sorting against random access.

The device I’m currently building in concept can easily put cards into two piles, but more piles would require much more advanced work and logic. This device will work with two motors from an old RC car or somesuch. Thus, teaching it to binary sort and actually perform the physical separation will not be difficult once the hardware is able to manipulate the cards accurately. The piles can be recorded as the binary sort is happening, preventing the need for a second pass before the camera lens.

By mixing a bit of sorting with a bit of technology, we can find a happy medium in which our access methods and storage methods grow and scale with our inventory size. The coordinate system removes the need for pre-sorting, but it still allows semi-sorted cards to remain relevant. While the system must be designed to perform strongly under true randomness, almost no collection acquired is truly random. People often group cards by set, name, color, and other relevant factors and this sorting, however rudimentary or advanced and however complete or incomplete, makes finding cards easier. By leaving these pockets of organization intact, you reap the benefits of someone else’s labor without ever needing to sort the cards yourself. You won’t even notice that this accidental sorting exists until you query a card and you see four of them in adjacent slots. Tim Ferriss and his “low information diet” would swoon. With so much information available, delivering relevant and timely information is more crucial than ever. There’s no need to show the end user data that’s not actionable or relevant until it becomes actionable or relevant. The only time you care about Tezzeret is when you’re actively working on a problem that requires a Tezzeret, such as filling a customer order or building a deck.

The most exciting part of this is yet to come. The implications of digital recognition are clear from this essay, but we are working under the assumption that such technology is possible. I told a cheeky lie earlier when I said it was an assumption, because I actually have a working prototype of it. I can say with total authenticity that I have in my possession a device that can successfully identify a Magic card based on a photograph of an unknown card. It’s here. It’s real.

The catch, of course, is that it’s a second-stage proof of concept, and its buggy, slow, and extremely limited. I have a feeling that our beta release of the technology will be much crisper, but I can’t say more right now. I can tell you that the first stage proof of concept was a webcam, a stand fabricated out of a soda bottle and a cardboard box, and a piece of paper taped to the bottom with the outline of a card on it. The software was an open-source image comparison engine, a webcam software suite, and a photoshop rotate/crop/resize macro. Necessity is the mother of invention.

The second stage concept, which currently lives on my desk in my office, is a thousand-count box with a side cut out. Inside the box lives a small plastic deck box, in which is affixed a web cam circuitboard. It connects to a PC via USB. This solved the issue of needing to concern myself with rotation or distance - the card was always a fixed distance away and was always flush with the corner of the box. New software improvements have removed the need for all of these things.

The software is slow. Comparing an image against a database of tens of thousands takes a lot of time and CPU power. We’re working on ways to optimize every aspect of the comparison, but for now, I’m content to say that I have successfully taught a computer to recognize and name a specific Magic card based only on a photograph. As this software improves alongside a growth in computing power, I forsee us bringing this concept to the mainstream and offering a hardware and software solution. There is no date for release planned, as this project is still in the “Labs”, so to speak, so it may never even see the light of day. If you want to get involved in this, or any of our future-forward tech projects, shoot an email to quietspeculation@gmail.com and we’ll get you connected to the right project manager. If you have an idea for a project that’d go well in the Labs, email us as well.

The world of image recognition is still young, and combined with some of our data-centric projects, will reinvent the way Magic players transact and store cards forever. I’ll discuss what I want to do with data at a later date, but I’ll close by simply reminding people that data exists, or can easily exist, for just about anything on the planet you care to measure. It’s just a matter of finding or building the right tools, looking at the right numbers, and putting the right rows and columns next to each other. Think of data mining like a giant word jumble, where you just need to match up the right numbers to the right ideas to prove or disprove theories. Once the bottleneck of the human memory and processing ability is opened up with image recognition and data processing, our entire way of handling Magic cards will be fundamentally changed.

Got a sweet idea for a Futuretech concept? Been working on a passion project and want some publicity? Send us your info and what you’re doing! Please remember that the ideas and concepts in these Futuretech articles are just that - ideas - and that they are in no way a promise of features to come. Heck, some of the basic concepts might be wrong. If you spot an error or have a better suggestion for how to do something, leave us a comment and we’ll integrate your feedback. Better yet, if you’re an expert on something we’re working with, get in touch. We’d love your expertise. Enjoy the weird science, and if you’d like to support our efforts to bring cutting edge technology to our favorite card game, consider signing up for an Insider membership. Insider lets us pay our writers so they don’t need to live on Ramen Noodles, and it also keeps our servers pushing out data every day. Whatever you do, enjoy!