How can I read Fujifilm 3D .mpo files in 2021 (two jpeg)? Earlier solution code doesn't seem to work anymore.

Hello,

I have thousands of Fujifilm 3D .mpo image files from their W3 camera that contain two jpeg images.

There is code in the File Exchange from 2014, but the imread function it uses doesn't seem to work as coded in MATLAB ver2020b.

Can anyone suggest an approach for reading these files to work with?

Thank you, DP

[DGM]

I haven't worked with such files, but it doesn't look much more complicated than basic concatenation. If you can attach a sample file, maybe we can try troubleshooting.

Assuming this is the FEX submission

https://www.mathworks.com/matlabcentral/fileexchange/48763-readmpo?s_tid=srchtitle

then I doubt that it's a change in imread() that's causing the problems. With the random sample MPO files I found on the web, it fails to correctly split the file -- a behavior that's uniform in R2009b, R2015b, and R2019b. It appears to me that the way it's looking for SOI markers is returning incorrect results. I don't know if asking the author is going to yield any results. They don't look too active, but they do have an email link in their profile.

The way I used to split concatenated JPEGs was just with an awk one-liner. I haven't tried that with an MPO yet, and I loathe to recommend such a thing, knowing the questionable portability of awk expressions. I'm just saying that there absolutely workarounds.

Answer 1

[DGM]

Here. I attached a modified version. Give it a whirl and see if anything changes. It at least works for the sample images I have.

The author was reading the file by char and searching for SOI markers on the presumption that a char is one byte. This leads to potential issues; as in some cases (mine, and probably yours), fread() reads a char as two bytes.

[David W Purcell]

Sorry for the slow response to your quick solution! Thank you very much for identifying the issue with the older code and fixing it.

Can you explain, are those SOI markers used for all jpeg images?

I really appreciate your work and time with this. Many thanks, DP

[DGM]

Well, half-yes.

0xFFD8 is the SOI marker for JPEG in general. That said, the code is looking at the first four bytes, so it's looking at the SOI marker plus the first application-use marker 0xFFE1. I'm not familiar with those markers or whether they're even relevant for the purpose of splitting the file. I'm inclined to doubt that they are, but I let it be. I imagine you could adjust it to use data(1:2) instead of data(1:4) and it'd still work.

When I was splitting catted JPEG, I never bothered using anything other than 0xFFD8 or 0xFFD9 (EOI) to do the job. For example in bash:

#concatenate images into a single jpg

#image readers will only read the first image because they stop at 0xFFD9

cat a.jpg b.jpg c.jpg > catted.jpg

#split the file into individual files again

S=$(printf '\xFF\xD9'); awk '{print > "out" NR ".jpg"}' RS=$S ORS=$S $1 catted.jpg

Of course, I don't expect my sloppy awk to work for anyone else, but you get the idea.

[David W Purcell]

Thank you for the extra explanation! DP