5 Replies Latest reply on Jan 7, 2014 2:12 PM by Lawrence Ng

    Template overlay orientation is not correct for Portrait template

    Robert Galvin

      When I try to scan in a 'Portrait' type of label, the overlay that is displayed to align it on the device is Rotated 90 degrees. If I rotate the device to align the template overlay with the orientation of the document, then I am capturing the image in a 'landscape' mode making it much further away from the device in order for it to fit into the full screen.

       

      It was also not clear to me if orientation mattered, but from the template overlay the lines seemed to give me the perception that it was. I would suggest that in the template design that this is indicated and the overlay lines correspond accordingly.

        • Re: Template overlay orientation is not correct for Portrait template

          Hi Robert,

           

          I have taken a look at your template, and found a couple of peculiarities:

           

          1. Only one region is output (a barcode); however another three regions were created as regions used to identify the form, but are not read. If this is just for testing purposes, this is ok, but in practice, if you are reading only a barcode from a form, you would choose the "Barcode Only" option, which would allow for you to create a form with only barcode regions. A "Barcode Only" form can scan with greater speed than one with Mixed Content and does not need a form border, unlike the Mixed Content forms, which require a border.

           

          2. No barcode symbology is specified in the template for the barcode region. Since there are two barcodes on the form, either one could be chosen as this barcode. Again, if this is a test, this is ok, but in practice, one should qualify the barcode with some characteristics (symbology, character checking, length, or a combination of these) to distinguish one barcode from another.

           

          I could not recognize the form on my device, so I was not able to see the resulting rectangle wireframe. However, I will continue to investigate this, as the behavior that you described shouldn't happen, as the device software should have displayed the wireframe in the portrait orientation. For the record, the orientation of the form does not matter to our software, although most of the time one orientation is better than the other in order to provide as large of an image as possible.

           

          Regards,

          Lawrence

            • Re: Template overlay orientation is not correct for Portrait template
              Robert Galvin

              Lawrence Ng wrote:

               

              Hi Robert,

               

              I have taken a look at your template, and found a couple of peculiarities:

               

              1. Only one region is output (a barcode); however another three regions were created as regions used to identify the form, but are not read. If this is just for testing purposes, this is ok, but in practice, if you are reading only a barcode from a form, you would choose the "Barcode Only" option, which would allow for you to create a form with only barcode regions. A "Barcode Only" form can scan with greater speed than one with Mixed Content and does not need a form border, unlike the Mixed Content forms, which require a border.

               

               

              Yes this was a test - wanted to start simple and then was going to decode the other fields like From Address, To Address, etc

               

               

              2. No barcode symbology is specified in the template for the barcode region. Since there are two barcodes on the form, either one could be chosen as this barcode. Again, if this is a test, this is ok, but in practice, one should qualify the barcode with some characteristics (symbology, character checking, length, or a combination of these) to distinguish one barcode from another.

               

              I thought it would only try to decode areas of the form that have been highlighted. Seems like uneccesary processing on the device on areas that the user is not trying to extract data from. I also assumed that by having other fields to 'id' and orientate the form, that it would know where the particular barcode is to be by the coordinates. I guess in a practical sense most use cases would know the type of barcode that is to be in that area. But what if you have two of same type of barcodes in different locations. How is this different? isn;t the coordinates of the bounding box the deciding factor? I know the analyze form is not complete yet, but I would expect that this feature on TB might warn the user that there are possible problems?

               

              I could not recognize the form on my device, so I was not able to see the resulting rectangle wireframe. However, I will continue to investigate this, as the behavior that you described shouldn't happen, as the device software should have displayed the wireframe in the portrait orientation. For the record, the orientation of the form does not matter to our software, although most of the time one orientation is better than the other in order to provide as large of an image as possible.

               

              I am still not clear on 'orientation does not matter'. To get the camera to display the entire frame of the display to get maximum readability, it should be in the same orientation. I think in most cases trying to decode a form in opposite orientation will make the image less clear and longer to decode (if at all). Why allow the user to fumble with this maybe put an icon in the overlay to indicate preferred orientation - I would rather see this then the large text of the template name (which I think is too big BTW). So far portrait labels for me are showing the wireframe opposite of the orientation of the device and cannot get the boxes to align to get a decode of the form data.

               

              Regards,

              Lawrence

              Hi Lawrence

               

              Thanks for the reply - See comments above inline.

               

              Rob

                • Re: Template overlay orientation is not correct for Portrait template

                  Hi Rob,

                   

                  Your notion of regions used for identification and the decoding of highlighted regions is correct for most region types (Picture, OCR, OMR), but Barcode regions are a somewhat special type of region in the sense that unless the "Barcode's location is fixed" checkbox is checked, the barcode can be anywhere on the form. This is useful for forms where the barcode is placed arbitrarily on the form (such as a sticker), as we would still be able to read the barcode in these cases. If there are two barcodes of the same type in different locations, one must use other additional characteristics to categorize them (e.g. character checking, barcode length). This would help the software distinguish the two barcodes from each other. The manufacturing sample form in the DPXDemo is a good example of using these other characteristics to distinguish a barcode on a multi-barcode form. In the future, we will have a verification module that will hopefully pick up on these things in the Template Builder.

                   

                  I think we are on the same page regarding the orientation playing a role in decoding. As I've mentioned, "For the record, the orientation of the form does not matter to our software, although most of the time one orientation is better than the other in order to provide as large of an image as possible." I think we both agree with this statement. Regarding the portrait labels showing the wireframe in the opposite direction, I am still trying to reproduce this; if you could send over a screenshot that displays the issue, we can get a visual confirmation on what is going on and take appropriate action. I believe I have a good idea of what is going on, but just want to make sure before diagnosing further. Finally, regarding your input regarding the template name and alternative orientation UI cues, we have noted them and will take the into consideration.

                   

                  Thanks,

                  Lawrence

              • Re: Template overlay orientation is not correct for Portrait template
                Robert Galvin

                See attached image. Note the wireframe is not in 'portrait mode'. Also note that when I rotate the device (MC40) I never see the wireframe appear. 

                 

                Also side note: I think the experience would be better to just indicate the image is in focus (like a camera) then take the picture. Pass picture to DPX engine instead of trying to DPX -decode in live preview. The wireframe does not stay visble long enough in most cases because the motion to move you hand to tap the screen makes it go out of focus I guess.

                  • Re: Template overlay orientation is not correct for Portrait template

                    Thanks for attaching an image; we have identified and corrected this bug on our side.

                     

                    Regarding your side note: we have considered this approach. The issue is that currently it is better for a user to initiate the capture sequence, as the software does not currently know whether or not the image is taking up a good amount of the screen. Thus, in the automatic scenario you described, it may be possible for the form to be identified and captured from far away as opposed to up close, which would result in a lower resolution form capture once the borders have been cropped out. If the wireframe does not stay visible long enough, there may be a couple reasons for this. One possibility is that the regions used to identify the form can be better defined (e.g. make regions a little larger/smaller to better encompass identification regions, use less identification regions (2-3 is optimal), etc.). Another possibility is that the user's hands are shaking a bit, causing the image to go in and out of focus.