Hi,

>Is it possible to implement an import filter which reads the MPO file and loads the right picture as layer 1 and the left picture as layer 2, for example?
>The advantage of this would be that the right and left picture are edited simultaneously in the same way when I edit a 3D picture. This sounds like a nice idea and offers new possibilities in photo editing and doing artwork with GIMP. If there are no other convincing answers which keep you off, file an enhancement request in Bugzilla. If then, there should be an MPO export plug-in, too. Maybe somebody will be willing to implement it sooner or later.

> On this site (http://cstein.kings.cam.ac.uk/~chris/mposplit/index.html) there is a sourcecode which splits the MPO file in two JPEG files. As far as I can see, it is under a BSD-style license. GIMP is GPL v3, isn't it? This might cause license issues, as they can be incompatible, see http://www.gnu.org/licenses/gpl-faq#OrigBSD. But perhaps the author is willing to choose a GPL compatible license or somebody else uses the official MPO specification to write an MPO import plug-in for GIMP.

Best regards.

"AL" == Albrecht Lohfener writes:

AL> I will write a mail to the author of the mpo splitting source code to AL> ask him if it is possible to change the license to gpl v3.

He doesn't need to change the license, but rather just to clarify *which* BSD license.

The original BSD license had an advertizing clause which was incompatible with the GPL licenses. The Revised BSD (aka 3-clause BSD) and the further simplified 2-clause BSD licenses are both GPL-compatible.

Given the relatively young age of the code in question, it is likely that he means the Revised BSD anyway, so it only should need clarification.

With such a clarification, there shouldn't be any reason to use the code as the basis for a GIMP plugin or patch.

But do ask that he add a Copyright line to the .c file.

-JimC

James Cloos          OpenPGP: 1024D/ED7DAEA6


_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

James Cloos wrote:
>With such a clarification, there shouldn't be any reason to use the code as the basis for a GIMP plugin or patch. Did I get you right? If the code wouldn't be used in GIMP, why then any clarification is needed?
Could you please clarify this? ;-)

Best regards, grafxuser

"g" == gfxuser writes:

With such a clarification, there shouldn't be any reason to use the code as the basis for a GIMP plugin or patch.

g> Did I get you right? If the code wouldn't be used in GIMP, why then g> any clarification is needed?
g> Could you please clarify this? ;-)

If the code -- or a derivative thereof -- would not be used in GIMP, then why did the first reply suggest (needlessly) trying to get the code relicensed as GPL3?

-JimC

With such a clarification, there shouldn't be any reason to use the code as the basis for a GIMP plugin or patch.

g> Did I get you right? If the code wouldn't be used in GIMP, why then g> any clarification is needed?
g> Could you please clarify this? ;-)

If the code -- or a derivative thereof -- would not be used in GIMP, then why did the first reply suggest (needlessly) trying to get the code relicensed as GPL3?

So, this seems to be a misunderstanding. I meant: if the existing MPOsplits code - or a derivative thereof - would be integrated into GIMP, then there could be a problem due to incompatible licenses
(BSD-style vs. GPL 3). So then there were two possibilities: either the MPOsplits author decides to publish his program under GPL v3 or another GPLv3-compatible license or
- even simpler - Albrecht asks him for clarification which 'BSD-style license' he exactly means and depending on this answer a developer decides to use the existing code or not. I agree with you for the case that MPOsplits original or derivative code is not integrated into GIMP and both programs would stay standalone products.
Then this clarification would be needless.

Best regards,

grafxuser

Albrecht Lohfener wrote

Hi,

I got the answer from Christian (the author of the MPO splitting software). He appreciates a MPO plugin for gimp and wrote: "So my understanding is that this does not make it incompatible with GPL v3 at all! But if it helps, I'm certainly happy to release mposplit under GPL additionally ..."
The result is that we can use the code in GIMP now!

How can we implement such an import filter? Is it more practical to add the MPO reading filter as an option to the JPEG filter or to create a new import filter that uses the JPEG source code from the JPEG filter?

Hi,

nice news and thanks, Christian! My first thoughts are:

Create a new import filter for MPO files. JPEG doesn't depend on MPO and nobody knows whether MPO will always depend on JPEG only. In future the single image files in MPO could even be DNG files or whatever. These facts are reflected best by two separate import plug-ins.

Internally the import plug-in could work as follows: 1. Use MPOsplits code (by calling its functions) to extract the embedded JPEG data to new temporary JPEG files. 2. Use the existing import filters to load these JPEG files into two separate layers. The PDB API already has the function gimp-file-load-layer(s).
3. Give the layers meaningful names, for instance 'left eye view', 'right eye view' for MPO files with only two embedded JPEG files. If the MPO file includes more than two JPEG files (like panoramic images) simply number them sequentially: 'image #1' and so on. 4. Internally clean up: delete the temporary files. The best way to use MPOsplit would be that its author Christian makes MPOsplit a library with a quite easy, elaborate and unalterable (or at least rarely altering) interface. This had the advantage that his software could have broader dissemination by reuse and GIMP could participate from MPOsplits evolution without much effort.

An MPO export filter could work like this: 1. For each single view: hide the unnecessary layers: for the edited left eye view hide the right eye's view layer and so on. Export the visible part of the result to a temporary JPEG file (using PDB APIs function file-jpeg-save) for each view. 2. Use MPOsplits code (by calling its functions) to merge the temporary JPEG files into a single MPO file.
3. Internally clean up: delete the temporary files.

In a second increment the import filter could be extended to load the MPO files thumbnail (APP1's thumbnail in the MPO file format spec) and show it in the 'Open image'-dialog.

A next step could be the proper handling of the MPO files' metadata (EXIF, IPTC, XMP and so on).

BTW: I don't want to arouse unfulfillable expectations, but this sounds like an easy task for a beginner or a GSoC student, if this feature request is of enough importance and there's yet time to fill with tasks before GSoC ends. Albrecht, could you please file an enhancement request in Bugzilla, if you haven't already done? This is the usuaI way after discussing it here and I think this helps you and our developers most for now.

Best regards,

grafxuser

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list