How does JPEG endianness matter on coding?

问题:

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

What I do:

1. I do an HTTP request to an IP camera, the camera return me an array of byte.
2. I parse these byte 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 picture are then use in another module from my application which use a 3rd party "viewer" that do some manipulation to the image. The viewer works with all the picture generated using computer in Windows XP and Windows Vista. But when the picture are generated using a Windows 7 machine, the pictures is 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 discover that there was 2 fields that were different between PictureXP and Picture7.

PictureXP: Exif Byte Order: Little-endian Picture7: Exif Byte Order: Big-endian Picture7 also have 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 show 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 additionnal code to his software so it needs to deal with endianness of the picture? I guess all picture 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.

Thanks a lot!

EDIT 1 : I found this article confirming that the endiannes 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?

回答1:

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.

回答2:

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