How does JPEG endianness matter on coding?

I'm currently working on a big project that involves pictures. One of the big issues I'm having is with the endianness of the picture (jpeg to be clearer). I always thought that in our modern world we didn't have to bother about this subject, but now I'm not sure.

What I do:

1. I do an HTTP request to an IP camera, the camera returns me an array of bytes.
2. I parse these bytes into an object Image in .NET using Image.FromStream.
3. I take my Image object and do a Save to a physical file on the hard disk.

These pictures are then use in another module from my application which uses a 3rd party "viewer" that do some manipulation to the image. The viewer works with all the pictures generated using computer in Windows XP and Windows Vista. But when the pictures are generated using a Windows 7 machine, the pictures are all messed up.

Let's say that the picture created with Windows XP will be called PictureXP and the picture created using Windows 7 will be called Picture7. I checked the files using exiftools and discovered that there were 2 fields that wer开发者_C百科e different between PictureXP and Picture7.

PictureXP: Exif Byte Order: Little-endian <Intel, II>

Picture7: Exif Byte Order: Big-endian <Motorola, MM>

Picture7 also has an additional field: User Comment: .

The two pictures can be opened normally in any photo viewer, it's only in this 3rd party viewer that the picture shows up all mixed up and the only difference between the 3 pictures are these fields.

What I want to know:

1. Is it possible that the 3rd party needs to put additional code to his software so it needs to deal with endianness of the picture? I guess all pictures program out there deal with that?
2. Is it possible for me to change the endianness of my jpeg to be always little-endian? I've read somewhere that the content of a jpeg file is always supposed to be in the same endianness but it seems that it's not considering the exif data. If it's possible, I would love a solution in .NET...
3. Anything that could help to go through this situation will also be considered as an answer.

EDIT 1 : I found this article confirming that the endianness found in the exif header is only applicable to the exif header and that a jpeg file is always in big-endian. So is there a way to change the exif header so the 3rd party soft would be able to read what he needs?

---

Ok so I found my answer by asking question to Phil, the author of exiftool

You can see the thread I had with him here.

1. Yes it's possible. The 3rd party SDK was not aware that the exif header could be encoded using little-endian or big-endian and was only reading using little-endian. Changing all my picture to little-endian fixed the problem.
2. 2 parts answer: First, the data of a jpeg is always big endian as said in my edit. Second, the exif header can be in either little-endian or big-endian and it's possible to change it using exiftool.

In command line:

exiftool -all= -tagsfromfile test.jpg -all:all -unsafe -exifbyteorder=little-endian test.jpg

You can also found a wrapper for the tool in almost any language in this page.

Thanks a lot for your interest in the question and the answer I received.

---

I think maybe the problem is with the user comment field. I read somewhere that Windows Vista (and probably windows 7) saves the user comment field as Unicode in little-endian byte order, irrespective of the byte ordering of the EXIF information. Since the only difference between PictureXP and Picture7 is the endianness of the exif information and the user comment field, maybe you should look that way

Good luck