Announcement

Collapse
No announcement yet.

uCam-III decoding bytes to JPG Image

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • uCam-III decoding bytes to JPG Image

    Hello,

    I have successfully received packages from the uCam-III, and I am now attempting to decode the bytes into an image.

    The steps I took follows as shown on page 15 of the specification for the camera (Attached below in the attachments)
    The only change I made was to use 64 bytes per package as opposed to 512 bytes.
    This should not affect anything, except that I would need to read more packages.

    I have stored the output from the camera to a text file, and attempted to decode them into images with Java.
    The text files are attached below also, where each file is one image.

    I am currently assuming that the FFD8 from the camera means 0xFF and 0xD8, where every two represents one hex.
    Please let me know if this assumption is false.

    Is there a good algorithm to do this? Or some kind of converter?

    Thanks
    Attached Files

  • #2
    Hi,

    The only change I made was to use 64 bytes per package as opposed to 512 bytes.
    This should not affect anything, except that I would need to read more packages.
    Yes. Seeing the file has '0xFF' and '0xD8', I guess you have already truncated the ID and Data Size

    I have stored the output from the camera to a text file, and attempted to decode them into images with Java.
    Have you tried to open the file using a 'Hex editor'? How are you saving the data? Upon checking the file, I think you are saving
    only one hex character in a byte, where a byte must contain 2.

    Do you have a programming cable? You can try to capture an image from uCAM using the uCAM Demo Application,
    then save the file and open it using the 'Hex editor'. You can observe the output of your save txt file and the JPEG file from the uCAM.

    I am currently assuming that the FFD8 from the camera means 0xFF and 0xD8, where every two represents one hex.
    Please let me know if this assumption is false.
    '0xFF' represents a byte.

    Best Regards,
    Kevin

    Last edited by John Kevin; 16th May 2019, 06:53 PM.

    Comment


    • #3
      Originally posted by John Kevin View Post
      Yes. Seeing the file has '0xFF' and '0xD8', I guess you have already truncated the ID and Data Size
      Yes, I only grabbed the data bits, not the ID, size, or the verify bits.

      Originally posted by John Kevin View Post
      Have you tried to open the file using a 'Hex editor'?
      I haven't tried using a 'Hex editor', but I can try later.

      Originally posted by John Kevin View Post
      How are you saving the data? Upon checking the file, I think you are saving
      only one hex character in a byte, where a byte must contain 2.
      I am using an Arduino Uno to receive packets from the uCam.
      After the Arduino receives them, it prints them to the serial monitor, which I copy and paste into a TXT file.
      Then I run the Java algorithm and converts it to a JPG file.
      The Java algorithm has been tested on a TXT file from other sources and it works.

      Originally posted by John Kevin View Post
      Upon checking the file, I think you are saving
      only one hex character in a byte, where a byte must contain 2.
      I am reading two characters as one byte when I convert. The TXT file is like this because this is what the uCam sent back, and I just copy and pasted into a TXT.

      What I think might be the issue is that maybe the data coming back from the uCam to Arduino is somehow corrupted.
      Because for the TXT file that works(also attached below), the file starts with FF D8 FF, and ends with FF D9, which is the start and end indicator for JPG files.

      The files from the uCam starts with FF D8 FF, but does NOT end with FF D9.
      Attached Files

      Comment


      • #4
        Hello,

        I am reading two characters as one byte when I convert.
        Ok, thank you for making this clear.

        I am using an Arduino Uno to receive packets from the uCam.
        After the Arduino receives them, it prints them to the serial monitor, which I copy and paste into a TXT file.
        I think the problem is that by copying and pasting the data in a text file, you are saving it in a character-text format, whereas it should be in a byte.
        That is why when decoding the data you are getting a corrupted image.

        Please see the attached image.

        Click image for larger version

Name:	Pic.png
Views:	71
Size:	61.4 KB
ID:	68296

        This is a sample text file of an image captured by UCAM.

        Click image for larger version

Name:	Default.png
Views:	41
Size:	47.8 KB
ID:	68298

        I hope this helps.

        Best regards,
        ​​​​​​​Kevin

        Attached Files

        Comment


        • #5
          Thanks for the reply,

          Originally posted by haomiy View Post
          The files from the uCam starts with FF D8 FF, but does NOT end with FF D9.
          So, is this expected then?

          Originally posted by haomiy View Post
          I think the problem is that by copying and pasting the data in a text file, you are saving it in a character-text format, whereas it should be in a byte.
          That is why when decoding the data you are getting a corrupted image.
          I realize that I am saving it as a character-text format, but took care of this in my decoding algorithm.
          For example, if the txt says FFD8, I write to my new file the bytes 0xFF and 0xD8, which is what the created JPG expects.
          I am mostly certain that my algorithm for decoding this is correct, since it has been verified by 2 people now.

          I think it is more likely that I'm not understanding what the bits represent, based on what I have read here:
          https://www.file-recovery.com/jpg-signature-format.htm

          It shows that a JPG should:
          1. Start with FFD8, which mine does
          2. End with FFD9, which mine does NOT
          3. Have FFE0 following the FFD8, which mine does NOT
          etc...

          Based on what I know, shouldn't all JPG follow this?
          For your reference, I have re-attached the three output files from the serial monitor(each file is one image)

          Thanks
          Attached Files

          Comment


          • #6
            Hello,

            The files from the uCam starts with FF D8 FF, but does NOT end with FF D9.
            2. End with FFD9, which mine does NOT
            Yes, FF D8 FF is the JPEG file header. It does not necessarily need to always end on FF D9, as far as I can tell, you can also receive some characters after that.

            3. Have FFE0 following the FFD8, which mine does NOT
            As you can see on the image I have attached (image captured by uCAM) "FFD8" is followed by "FFDB" which is also true on your output files.
            So I think you are already receiving the correct data.

            For example, if the txt says FFD8, I write to my new file the bytes 0xFF and 0xD8, which is what the created JPG expects.
            I am mostly certain that my algorithm for decoding this is correct, since it has been verified by 2 people now.
            Can you also attach here your JPEG file? Thanks

            Best Regards,
            Kevin

            Comment


            • #7
              Originally posted by John Kevin View Post
              Can you also attach here your JPEG file? Thanks
              Done. "output1.jpg", "output2.jpg", "output3.jpg" corrosponds to "test1.txt", "test2.txt", "test3.txt" repectively.
              I had to upload a zip file since it says "Image resize failed due to insufficient memory", when I try to upload the jpg files.
              Attached Files

              Comment


              • #8
                Hello,

                In your attached image, I am looking for the data on the size of the image.
                It should be included on the image file but I am not seeing anything from the Hex editor (JPEG size: 160x128, 320x240, 640x480).

                I have attached a picture for your reference.


                Best Regards,
                Kevin
                Attached Files

                Comment


                • #9
                  Hello again,

                  Originally posted by John Kevin View Post
                  In your attached image, I am looking for the data on the size of the image.
                  It should be included on the image file but I am not seeing anything from the Hex editor (JPEG size: 160x128, 320x240, 640x480).
                  I should be 640x480, because I was following the example on page 15 of the specification(re-attached below).

                  Would could have caused this to have occurred?
                  I will keep taking new images and see if I can fix this.

                  Thanks for all the help
                  Attached Files
                  Last edited by haomiy; 17th May 2019, 08:11 PM.

                  Comment


                  • #10
                    I think I might know what the issue is.
                    When I set my package size to 64 bytes, I very often get less than that.
                    For example, after reading the ID and the package data size from the package, I should have 60 bytes remaining, with 58 bytes of data and 2 bytes of verifying info.
                    However, I am only getting 58 or 59 out of the 60 bytes, meaning I am actually missing bytes.

                    The ID and package data size(the first four bytes) have been verified to be correct.
                    This means that I am missing a byte in either the actual data or the verify bytes.

                    Is there a good way to fix this issue?

                    Thanks.

                    Comment


                    • #11
                      Hello,

                      For example, after reading the ID and the package data size from the package, I should have 60 bytes remaining, with 58 bytes of data and 2 bytes of verifying info.
                      However, I am only getting 58 or 59 out of the 60 bytes, meaning I am actually missing bytes.
                      I really haven't encountered this issue and usually, upon sending the correct commands you can get the correct data from the uCAM.

                      Since you have said that you are setting your package size to 64 bytes, I did try to emulate your setup and this is the commands I send to uCAM.
                      I hope this helps you to troubleshoot your program.

                      1. Command: Sync[AA 0D 00 00 00 00]
                      2. Reply: <AA 0E 0D 04 00 00> <AA 0D 00 00 00 00>

                      3. Command: Ack[AA 0E 00 00 00 00]

                      4. Command: Initialize[AA 01 00 07 01 07]
                      5. Reply: <AA 0E 01 05 00 00>

                      6. Command: Set Package Size[AA 06 08 40 00 00] #4th-byte = LOW byte and 5th-byte= HIGH byte (which is 64 bytes)
                      7. Reply: <AA 0E 06 06 00 00>

                      8. Command: Get Picture[AA 04 05 00 00 00]
                      9. Reply: <AA 0E 04 07 00 00> <AA 0A 05 14 36 00> #This is the size of the image, which is returned by camera. 10th-byte = LOW byte, and 11th-byte = HIGH byte

                      You can use this data to send the number of packages,

                      imagesize = reply[10]*256 | reply[9]

                      numofpackages = int(imagesize/(64-6))+2
                      #-> 64 is the package size, and the +2 is just an offset.


                      10. Command: Ack[AA 0E 00 00 n 00] #-> Send this n times, where n = numofpackages
                      11. ImageData (64 bytes)

                      Best Regards,
                      Kevin





                      Last edited by John Kevin; 20th May 2019, 02:37 PM.

                      Comment


                      • #12
                        Originally posted by John Kevin View Post
                        numofpackages = int(imagesize/(64-6))+2 #-> 64 is the package size, and the +2 is just an offset.
                        The lab specification shows this though:
                        Click image for larger version

Name:	Screen Shot 2019-05-19 at 8.10.36 PM.png
Views:	40
Size:	66.8 KB
ID:	68361
                        Where did the +2 come from?

                        Also, is it normal that I have to send "SET PACKAGE SIZE" or "GET PICTURE" multiple times before it gives me back an "ACK"?

                        Originally posted by John Kevin View Post
                        10. Command: Ack[AA 0E 00 00 00 00] #-> Send this n times, where n = numofpackages
                        Do I not need to follow this format?
                        Click image for larger version

Name:	Screen Shot 2019-05-19 at 8.14.10 PM.png
Views:	34
Size:	123.9 KB
ID:	68362
                        It shows that the ACK is different for each package.

                        Comment


                        • #13
                          Hello,

                          Where did the +2 come from?
                          As I have said on the comment, it is just an offset. In case there are overheads in the computation.
                          Let's say you have a 13K size of an image, using the formula on the datasheet you will have decimal places as a result, in these case you need to send another ACK to get the last package. I hope I make this clear.

                          Also, is it normal that I have to send "SET PACKAGE SIZE" or "GET PICTURE" multiple times before it gives me back an "ACK"?
                          You only need to send "Set Package size" and "Get Picture" command once. You should receive an ACK once you have sent these commands.

                          It shows that the ACK is different for each package.
                          Yes, as you can see in the diagram, you need to send the package number by incrementing the 5th byte of the "ACK" command until the last package.
                          I have edited my post above. Please check again, thanks

                          For reference, you could also take a look at this uCAM Arduino library https://forum.4dsystems.com.au/node/45394

                          Best Regards,
                          Kevin
                          Last edited by John Kevin; 20th May 2019, 02:56 PM.

                          Comment

                          Working...
                          X