Support Portal

Hello,

I am actually working on testing your SwiftDecoder Trial Version with pictures issued by a 1.92MPixel sensor. We wanted to know if your SwiftDecoder has documented qualifications (by this I mean what are the minimum/maximum ranges, density per inch, pixel size per module, image quality, time response, etc for 1D, 2D and OCR codes) that we could us to evaluate the SwiftDecoder’s capabilities with more precision other than the little that is given in the download section.

Thank you in advance, Dorian

Hello Dorian.

 

We have documentation listed on the website which discusses the Density requirements for 1D, 2D and OCR.  For SwiftDecoder, in the Evaluate section of the page, click on the "Tech Specs" and "Decode Speed" tabs for the information you require.  For SwiftOCR, the characters need to be contiguous, and between 10 pixels and 50 pixels tall. 

For image quality and time response, it really varies as there are too many factors involved, and there isn't a finite quality metric that is useful for a given image.  So we provide samples of images of varying quality along with how long it would take to decode these on a given platform.  Link is provided below. 

http://www.omniplanar.com/swiftdecoder.php 

 

Thank you for the information (I had already been through most of it by the download section, but I've noticed information that I hadn't picked up).

Would there be an organogram of how the SwiftDecoder functions when it processes an image (as in the steps it takes to analyse and decode) ?

My question has the following concern in mind : we are actually seeing how the SwiftDecoder could be ported on onboard applications. Our company works with a Spartan 3E (an FPGA) and we were curious to see what sections of the software should be put into the process of the FPGA for calculations on the image and what sections of the software should be put in the control unit.

This question comes to mind because speed is an issue concerning our application, so we are looking to see if the SwiftDecoder would be a suitable application

Side note : I don't know why my "enter" key is not being taken into account by the forum, sorry for the sadly condensed presentation of the post.*(edited since that comment under IE)

Dear Dorian.

We do not supply information on how we process the images.  I understand your question, and why you are asking, but this information is a Trade Secret, and frankly, the reason why our decoder is far superior to anything else on the market.

When our licensees use our software in their product/application, we request that they do not preprocess or touch any part of the image. Simply put the image in memory, and call our decoder so that we can do find and decode the bar codes.  We have written many routines that are faster and far superior than what are written and included as generic image processing techniques in most processors/devices.

Our decoder is the fastest on the market - bar none.  It truly is, and any testing you  do versus the competition will clearly show this.

What is your application? Is there anything that you can share?

Sorry about the 'enter' key - not sure why that is!

.garrett.

Hello Garrett,

Your answer was to be expected and of course is understood.  I am not really at liberty to talk about our application yet (might be able to early September), but we are interested in decoding barcodes and OCR codes "simultaneously".  We are working on an on-board prototype. Our benching is done with HHP, recently bought by Honeywell (like you were), who as you probably know sells an on-board application.

Dorian

Nota : the enter does not work under Opera but does under IE   

Hello again,

Our preliminary testing being quite satisfying, we would wish to know if you had more specific documentation (with possible examples) on what is required for a successful porting to an onboard application other than what is said in the Technical Datasheet provided by this site.     

Also, is it necessary to combine a 32-bit processor with a platform/OS or can the SwiftDecoder compiled-object code be functional on just a 32-bit processor? If so, would a Xilinx MicroBlaze (32-bit RISC microprocessor) suffice? Has there been any precedent in that case?

Best Regards,

Dorian

Technical Datasheet SwiftDecoder:

 

600 KB of memory is required for code. Reduced code sizeis possible for custom applications with reduced feature sets.

Typical memory (RAM) usage: All 1D codes 225 KB, All 2D codes 320 KB, All Postal codes 400 KB, Full Package 500 KB

[…]

Processors (32-bit or greater required):  • x86 • ARM, StrongARM • MIPS • DragonBall • PowerPC • XScale • Blackfin • Hitachi SH Family

Platforms/Operating Systems:  • Windows • WinCE • Linux • .NET

 

Hello Dorian.

For future expansion purposes, you may want to secure about 1MB for Code space and 500KB of RAM for stack usage by the decoder.

For porting, we need you to provide us with a Development Board/Kit for the processor you choose, a copy/license for the compiler and a simple "Hello World" Program that has been written and tested on the Dev Board using the tools supplied.  This equipment and licenses are owned by your company. We will do all of the porting and testing with this equipment. 

We have not ported to Xilinx MicroBlaze, but if its 32-bit RISC, we should be OK.

 

Garrett

Hello Mr. Russell,

You said previously that you only needed the image to be in memory so that your decoder could call upon it.  Further question : what kind of image format is needed (JPEG, YUV (YCbCr) 4:2:2, YUV (YCbCr) 4:0:0, RGB 565, RGB 444, Bayer 10-bit or Bayer 8-bit) ?  

 Best regards,

Dorian

SwiftDecoder expects an 8-bpp bitmap that follows these guidelines: 

• The image is stored as a sequence (i.e. array) of bytes
• There is one byte per pixel
• Consecutive pixels on a line are stored in consecutive pixels in memory
• Consecutive lines are stored consecutively in memory (with an optional fixed length gap).
• Lower numeric values (i.e. values near 0) represent darker, (i.e. lower reflectance) pixels, and higher numeric values (i.e. values near 255) represent lighter (i.e. higher reflectance) pixels

Hello Mr. Hejl,

JPEG, YUV (YCbCr) 4:2:2, RGB 565, RGB 444, and Bayer 10-bit are all 2 bytes per pixel formats, so your answer excludes them.  However YUV (YCbCr) 4:0:0 or Bayer 8-bit are 1 byte per pixel formats.  Are you able to read either of them ? The YCbCr format works on illuminance, degree of blue and degree of red whereas Bayer 8-bit is a truncated version of what the transistors of a digital camera are able to acquire to compose an image (i.e. truncated raw image).  Both send values between 0 and 255 (of course, since it's an 8 bit per pixel). 

Best regards,

Dorian

Dear Dorian.

Our engine requires all images to be in 8 bit per pixel, grey-scale format.  Our SDDemo software converts these automatically when you open an image.  So the various formats you listed above, would need to be converted and placed in memory, prior to calling the decoder. 

Garrett