Pattern Paint is missing it's bottom 4 1/2 LEDs
In the Windows 7 version of Pattern Paint, the bottom 4 and a half pixels for the BlinkyTape aren't represented (the program's window is locked in place and can't be extended to see the last few pixels). I can make changes to them by using the larger paint brush tools, but that's certainly not optimal. After restarting then un/reinstalling, with a restart in between I'm fairly certain that it's the program and not my machine. 
I've taken this still: http://imgur.com/eDcm3Bm to show what I mean. The painting tool was set to a 5x5 footprint and I set each splotch next to one another. In the photo you can see that the first 55 pixels are easily modified and work fine with the BlinkyTape, then at 56 only half of the pixel is visible, and the following 4 are completely obscured. Thanks for any help!
I've taken this still: http://imgur.com/eDcm3Bm to show what I mean. The painting tool was set to a 5x5 footprint and I set each splotch next to one another. In the photo you can see that the first 55 pixels are easily modified and work fine with the BlinkyTape, then at 56 only half of the pixel is visible, and the following 4 are completely obscured. Thanks for any help!
Comments
Maybe Pattern Paint says it supports jpg, and I don't see it. But I'm willing to bet it doesn't.
To my understanding, png and bmp contain pixel maps which are very easy to process. JPG does not.
A jpg uses quite a bit of lossy compression to generate an image on your screen, so you can't really open up a JPG file and determine "pixel at (x,y) is RGB(0,0,255)" without processing the entire image file and understanding the compression algorithm. The image is an emergent property of the compression information. I would expect a png or bmp to work easily for the Pattern Paint because those file types contain pixel and color information directly. You can open the BMP file and see what pixel information the file contains at a certain location without knowledge of every other pixel in the image.
You're correct that the different types of files encode images and colors differently, and the BlinkyTape very likely couldn't handle reading a JPG image (to start with, the microcontroller doesn't have enough ram to store a whole image). The way we get around this, though, is to use PatternPaint to decode the JPG into a format that the tape can understand (and similar for PNG, too, it is also a compressed format).
The PatternPaint program actually does all the conversion on your computer, using the library qImage: http://qt-project.org/doc/qt-5.0/qtgui/qimage.html. The library should be able to open .BMP, .GIF, .JPG, .PNG, and a couple of more obscure formats. Once the file is opened and turned into a qImage, it's basically a big array of RGB values, and we can translate it into a format that the BlinkyTape can understand. Similarly, it uses the same library to save images back to the hard disk, and knows how to convert them back into the correct format for saving. We're fortunate that we didn't need to write a library to do this, because they are large and complicated and getting them to work reliably is a full-time project by itself.
Incidentally, we do have a mini-format for animations on the BlinkyTape- it stores the color values as RGB565 (compressing 24 bit color data into 16 bits), and uses run length encoding (RLE) to compress the data even further.
JPG works for me on my MacBook, and I assumed it would be fine on Windows and forgot to check. It's hopefully an easily correctable issue.
Thanks Fromar and Matt!
https://github.com/Blinkinlabs/PatternPaint/releases/tag/0.2.0