WordPress (the company which hosts this site) collects some interesting statistical data on the people who visit the blog. To me, the most interesting data is a list of the search words which direct people to this site. Since I started including the JPEG and ARM keywords in my posts, I’ve seen a steady stream of people searching for basically the same thing: Free optimized source code for decoding JPEG/MPEG images on ARM devices. I’ve done such searches myself and have come to the conclusion that it’s not available. For anyone who has done research and invested tons of time and energy into writing optimized code, it is unlikely that they will be willing to give it away for free. There are plenty of open-source and free projects on the internet that are valuable and professionally done, but there usually comes a point in a project’s lifetime when the author commercializes it to get compensated for the time invested.
I try to share my knowledge and experience with the developer community; I understand the frustration of wasting precious time locating resources or coming up with workarounds for problems outside of (or within) my code. I also make a living writing software, and so I must write code which is worth compensation from my customers and maintain innovative solutions which compare well with my competition. The geek in me would love to have an open discussion about the fastest way to decode Huffman encoded data or minimize the calculations in the IDCT, but as a consultant, that would be self-defeating.
The “trade secrets” are visible in the source code, but hidden in the object code, so licensing object code will incur less risk to me and therefore cost considerably less. I’ve licensed my code to various companies for values ranging from several hundred dollars to tens of thousands. The price varies according to the risk and time required. Companies needing help with ARM optimization issues are encouraged to contact me. The amount I charge for my time or code is usually far more economical than having other programmers spend time trying to invent what I’ve already got working.
July 31, 2007
Posted by
bitbank |
arm, arm9, asm, assembly language, jpeg, omap, optimization, pocket pc, smartphone, xscale |
|
5 Comments
The two changes in 0.27 are the release of the Desktop PC version of SmartGear and the addition of the “PAUSE” button to the MasterSystem emulator (mapped as “Select”).
The product page for SmartGear is up –>SmartGear Web Site
You can now download friendly installers for Pocket PC and SmartPhone. The installers also install a Desktop PC version of SmartGear (never released before). A paypal button is at the bottom of the page to allow you to register.
July 20, 2007
Posted by
bitbank |
emulation, pocket pc, smartphone |
|
1 Comment
I thought it would be useful to re-run the tests with the C version of my JPEG code. From the results it appears that memory bandwidth is the real limiting factor to the speed and the pixel colorspace conversion gets the most benefit from my optimized ARM assembly language. Also it appears that the OMAP gains more from optimized ASM than the XScale does. Here are the numbers:
C-Code:
PPC: thumbnail: 10.7 milliseconds, DC only: 968 milliseconds, full res: 3734 milliseconds.
SP: thumbnail: 25.1 milliseconds
Mixed C and ASM
PPC: thumbnail: 8.8 milliseconds, DC only: 830 milliseconds, full res: 2700 milliseconds.
SP: thumbnail: 15.1 milliseconds
The load times for the “DC only” and “full res” tests include the time taken to read 4.3MB of data from RAM through the WinCE file system.
These results make sense in that the real benefit of optimization comes from fixing the algorithms and reducing memory usage. The optimized ARM assembly code is certainly helpful in speeding things up, but won’t offer an order of magnitude improvement over what the compiler generates.
July 11, 2007
Posted by
bitbank |
arm, arm9, asm, assembly language, benchmark, jpeg, omap, optimization, performance, pocket pc, smartphone, wince, xscale |
|
No Comments
The great thing about the ARM architecture is that the more I look at a piece of code, the more ways I find to optimize it. The conditional execution, barrel shifter and optional setting of the processor flags create many opportunities for optimization. I’ve spent some more time optimizing my ARM asm JPEG code and now have some hard numbers to publish. I used a HP iPAQ h2210 Pocket PC (400Mhz PXA255) and a HTC Hurricane SmartPhone (195Mhz OMAP 850) to do the testing. I was able to load the file from RAM on the Pocket PC (to reduce file I/O delays), but not on the SmartPhone. The SmartPhone file system does not use RAM for file storage. The slow speed of reading from the miniSD card overtakes the amount of processing time in the tests, so the only test that was run on the SmartPhone was decompressing a 160×120 thumbnail image in RAM. All tests were to decompress the image to a RGB565 bitmap. The thumbnail test decompresses the 160×120 EXIF thumbnail image. The “DC only” test creates a single pixel from each MCU (the 3072 x 2304 image is loaded as 384×288). The “Full res” test decompresses every pixel of the image.
PPC: thumbnail: 8.8 milliseconds, DC only: 830 milliseconds, full res: 2700 milliseconds.
SP: thumbnail: 15.1 milliseconds
The speed difference between the two devices is to be expected considering the different processor and memory bus speeds. The “DC only” test is useful because it shows the relative speed of Huffman decoding. The file size is 4.3MB, so in 830 milliseconds the code was able to decode all of the MCUs and produce a single pixel from each one.
I’ve uploaded the sample image to my web server here: CIMG2209.JPG
The image was taken with a Casio EX-Z750 and depicts a relatively complex scene with many fine details. Like most cameras, the Elixim series saves JPEG images with 2:1 horizontal color subsampling (when set to maximum quality). It’s not unreasonable for a point-and-shoot camera like the Z750 to save images at a less than optimal compression because the image coming off the CCD isn’t that great to begin with. What irks me is that cameras like the Canon 20D do the same thing. With a good SLR lens and imager, the Canon should allow you to save full res color JPEG images.
Comments?
July 7, 2007
Posted by
bitbank |
arm, arm9, asm, assembly language, benchmark, jpeg, omap, optimization, performance, photo, pocket pc, smartphone, viewer, wince, xscale |
|
4 Comments
A while ago AOL decided to charge separately for their dial-up service and allow free email accounts. This news doesn’t seem to have reached all AOL customers because I’m still finding people that are paying for AOL dial-up access thinking that it’s necessary to keep their email address. I understand their need to keep an AOL email address because they have business cards or advertisements printed with that address and can’t easily change it. The other night I asked a neighbor of mine if he was still paying AOL to keep his email address. He’s the third person I asked and the third person who is paying without the need. Our neighborhood has a contract with the cable company to get discounted cable TV, so most of us also have high speed cable internet service. If you’re paying AOL $15-$22 per month and paying for DSL or Cable internet, you can probably save yourself some money. Here’s AOL’s description of their free email accounts:
AOL Free email help page
If you’re feeling grateful that I just saved you $180 per year, feel free to send some of it to me
July 5, 2007
Posted by
bitbank |
aol, email, tech |
|
1 Comment