I am using the Linksprite Camera with Arduino. - https://www.sparkfun.com/products/retired/10061
Due to certain circumstances I am sending the image from the camera over the Internet in Dec format (255,216,255,254,...and so on).
I end up with a file - http://www.binaryorbit.org/original.txt
I then convert this file to ASCII characters in the hope of seeing the image - http://www.binaryorbit.org/pic-ascii.txt (theory is I can just rename this to .jpg). It just doesn't work though.
I'm pretty sure I have the correct characters, because when I view in in HEX, I see the all important FFD8 at the beginning and FFD9 at the end. - http://www.binaryorbit.org/pic-hex.txt
When I view the JPG in JPEGsnoop, I get "ERROR: dqt_dest_id = 11, >= 4".
That jpeg data looks header less to me.
Normally there is a JFIF at offset 7 of the header of jpg/jpeg files.
I don't see that in your data.
EDIT:
There seems to be sub variants of jpegs (i.e. JFIF JPEG and EXIF JPEG), although every jpeg that I have checked has the JFIF indicating no EXIF data.
Perhaps JPEGsnoop has problems with the one that does not include JFIF in the header?
I see what you're saying, but no matter what I do, I can't seem to get the EXIF or JFIF to appear in my data stream.
Here is a snippet of the raw data as it is piped to the Arduino COM window...so not even after the data is sent over the internet, which may introduce corruption -
What I'd like to know is does this camera definitely output a JPG file that contains JFIF or EXIF. Google is not throwing up any example images that I can interrogate.
Does anyone here use this camera and can confirm the presence of JFIF or EXIF in one of their working JPGs?
That data certainly uses JPEG data (as you correctly said starts with FF D8) but no header which could be the problem for JPEGsnoop.
I can't tell you if that camera does generate the header or not, perhaps it's meant to be used with a TWAIN driver where the app calling the driver will then add the header and save the file, I don't know.
To test, simply take a photo with a domestic digital camera and analyze that, most if not all will add the EXIF data which includes parameters such as, camera model, focal length and so on.
Look you read a byte of data from the cam and then write() it to your SDcard or what ever you don't use print() Your talk of converting from dec to Ascii makes me think your doing something wrong. Ascii,dec,hex are just way of expressing taht to make it readable to humans.
Post your code, but if you have printed (other than for debug) instead of written that's your problem.
Keep in mind that jpeg images use segments (or packets like mpeg) and a file can have several segments or packets.
The first segment must be proceeded by a header as shown in the attached table.
From the official jpeg specs:
The APP0 marker is used to identify a JPEG FIF file.
The JPEG FIF APP0 marker is mandatory right after the SOI marker.
The JFIF APP0 marker is identified by a zero terminated string: "JFIF". The APP0 can be used for any other purpose by the application provided it can be distinguished from the JFIF APP0.
The JFIF APP0 marker provides information which is missing from the JPEG stream:
version number, X and Y pixel density (dots per inch or dots per cm), pixel aspect ratio
So assuming that there is no data corruption in your conversion process, it seems to be that you are only getting the raw jpeg stream (or part thereof).
As the spec says, you need the header to tell the rendering/displaying app how to display the stream.
I am assuming that you capturing the stream from the camera then storing it in a buffer (RAM ,SD card) then doing the conversion.
So why not first add the same number of bytes as needed by the header (leave them all at 0x00 for now), carry on filling the buffer with the jpeg stream and when done, go back to the header bytes and fill in the required data then only convert.
