GNOME Bugzilla – Bug 675262
Reading and saving of 3D MPO files in GIMP
Last modified: 2018-05-24 13:09:51 UTC
Some cameras create MPO files which contain multiple images. The cameras Fujifilm W1 Finepix Real 3D and Fujifilm W3 Finepix Real 3D for example save the right and the left picture of a 3D picture in a MPO file and the camera Ricoh CX5 saves serial pictures in a MPO file. On this site (http://cstein.kings.cam.ac.uk/~chris/mposplit/index.html) there is a sourcecode which splits the MPO file in two or more JPEG files. The idea is to use this code to implement a MPO import filter for gimp which reads a "3D MPO" file of the Fujifilm W1, for example, and loads the right picture as layer 1 and the left picture as layer 2. The advantage of this would be that the right and the left picture are edited simultaneously in the same way. At the moment GIMP only reads the first image of the MPO file. On the GIMP developer mailing list there was a little discussion about this idea of an import filter. Please check the following link: http://comments.gmane.org/gmane.comp.video.gimp.devel/21613
Do you plan to implement this, or do you know some people who're using this format and would be interested in implementing it? This is the way most new plug-ins are created, whether they'll be included in GIMP or as add-on packages on http://registry.gimp.org
I use this format with my 3D camera and I know some people that use a 3D camera with this format, too. On the market there is no picture manipulating program which supports this format. The only way to edit those pictures is to split them and to load them separately into a picture manipulating program. Unfortunately I don't have time to implement this but I can help to test the MPO filter. For GIMP it would be a "unique selling point" to support this format.
I've looked at the mposplit code mentioned in comment #1 and found a potential problem: It determines the start offset of the file data of constituent images (which should be two in the stereoscopic case) by searching for SOI ("Start of Image", 0xff 0xd8) immediately followed by APP1 (EXIF data, 0xff 0xe1) which may just work right now, but even the next firmware revision of said cameras might use a different segment, e.g. APP0 (JFIF tag, 0xff 0xe0) which would be more standard-conformant. I think one should take a look at the MPO file format surrounding the JPEG/JFIF data to carve out the constituent images rather than guessing based on JPEG/JFIF segment markers.
Albrecht, maybe you could attach an example file in this format to this bug for people who'd want to take a shot at this.
Under the following links there are some sample MPO images for the FinePix 3D cameras. "FinePix REAL 3D W1" http://www.albrechtloh.de/box/gimp/DSCF2874.MPO "FinePix REAL 3D W3" http://www.steves-digicams.com/camera-reviews/fujifilm/finepix-real-3d-w3/DSCF2097.MPO Today I got a mail from the mposplit.c author. He updated the header of the c-file with the "Revised BSD license" and an appropriate copyright notice. I hope that the mposplit.c is now usable for the MPO import filter. Under the following link there is a PDF file with the MPO file format specification. Maybe it helps to improve the mposplit.c source code. (JFIF tag problem) http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf I think for the first implementation of this filter we can use the original mposplit.c with the JFIF tag problem and improve this later.
I started implementing the plug-in. I will be using "mposplit.c" in the plug-in. Will finish it soon!
(In reply to comment #3) > I've looked at the mposplit code mentioned in comment #1 and found a potential > problem: > > It determines the start offset of the file data of constituent images (which > should be two in the stereoscopic case) by searching for SOI ("Start of Image", > 0xff 0xd8) immediately followed by APP1 (EXIF data, 0xff 0xe1) which may just > work right now, but even the next firmware revision of said cameras might use a > different segment, e.g. APP0 (JFIF tag, 0xff 0xe0) which would be more > standard-conformant. Thats right. > > I think one should take a look at the MPO file format surrounding the JPEG/JFIF > data to carve out the constituent images rather than guessing based on > JPEG/JFIF segment markers. Can you suggest me an idea for resolving this? I am working on the plug-in.
Thank you, K Sashi Kumar, for creating this plug-in. I'm closing this bugreport now as we have a solution. If there are any bugs, please report them directly at the plugin registry site.
(In reply to comment #7) > Can you suggest me an idea for resolving this? I am working on the plug-in. Hi K Sashi Kumar, I have developed command line utility which both reads and writes MPO files. The reading is done with more sophisticated way than just searching for SOI. Please let me know if you are going to implement it into your plug-in, otherwise I would create and publish my own. The code is available here http://sourceforge.net/projects/mpoutils/ Pavel
Is the plug-in mentioned here part of the default GIMP distro now - or at least in Git master? If not, then this bug should not be marked as fixed.
(In reply to Michael Schumacher from comment #10) > Is the plug-in mentioned here part of the default GIMP distro now - or at > least in Git master? If not, then this bug should not be marked as fixed. Michael: if you mean the plugin available along mpoutils, then it is most likely not in git, or at least I am not aware of it. And I have no ambitions to be somehow involved in it. I've just created the utility and plug-in since I am using it. I know that there is only few people over the world interested in 3D (stereoscopy). I even don't provide binaries for the plugin, it must be compiled by the user. Moreover, the plugin has at least two problems. It uses gdk_pixbuf to read and write JPEGs, so it can only store RGB images (it fails if the source JPEG images are grayscale, which can happen if you want to create MPO from old stereographs), and the JPEG quality is set to 90% by default and cannot be changed. But if you or somebody want to include it into GIMP core, you ale welcome to use the code.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/399.