After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694206 - New "import as layer" schemes
New "import as layer" schemes
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2013-02-19 19:48 UTC by Jehan
Modified: 2018-05-24 13:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jehan 2013-02-19 19:48:25 UTC
Hello,

I would like to propose 3 new use cases for the "import as layer" feature.
First I'll remind the current feature: it imports a "copy" of the image as a new layer, and if this image is a XCF, it creates as many new layers as the original.

My proposition is to allow choices of how the import will work in the import window.

1/ When you import XCF files, allow the possibility to only import some layers (display a list of the layers).

Indeed some times you want to import only part of an image; a little like in Blender a .blend file can sometimes be used as a "library" that you can browse to only import some objects, or some patterns, material, scene, etc.
Well here we could have library XCF which you could browse and partially import.

2/ Allow to optionally merge the imported layers in a single layer.

Well sometimes you want to have all the layers again as separate layer that you can modify again. But other times, you are only interested in copying the "finale" image that would be displayed by a XCF file. In this case, receiving sometimes several dozens of new layers can be a huge mess in your current image with already a lot of layers. Of course you can always merge these imported layers by hand yourself afterwards, but why waste your time if that was your goal from the start!

3/ Allow to "link" an image (whatever XCF or other) or layers from a XCF image instead of importing it.
When you do this, you cannot modify the resulting layer(s). You can change the "locale" (not the linked one) offset, opacity or this kind of thing, but not draw in this "linked" layer.
Of course, each time you open the file, the display would update to the current state of the linked XCF.

Once again, this is inspired by Blender where you have the possibility also to link some objects (again, whatever: scene, material, etc.). The advantage is obvious: sharing data from a central point.

For instance let's say I do an animation, and I draw some background in a XCF. This background would be used in several different cuts, each cut being a separate XCF file. Considering that, when I draw characters or objects for my cut, I will want to import my background XCF as a base in each and every of these many cuts.
Now let's say that you update the background, like for instance change slightly the chosen color of the sky. You would have to go back in each cut file which imported this XCF, delete the previous imported layer(s) and import it again. If the background XCF was linked instead, you would not need to do this (next time you run your frame extracting script, the new background would be used, without even having touched the cuts again).

Also that allows several people to work on an image in the same time for instance (one person draws the background, another the character for instance, and there is no file resource conflict).

What do you think of my propositions?
If you have comments, let's hear them.
If you think that could nicely fit it, I'd like to work on implementing such a feature sometime. :-)
Comment 1 Michael Schumacher 2013-02-20 17:09:59 UTC
I'm missing "Import as a layer group". Which should probably be the default.
Comment 2 Jehan 2013-02-20 17:15:23 UTC
About this one, I wanted it too, but I realized it already exists, more or less. If the active layer is a group, then the imported XCF layers will go in that group.
So you can create a new empty layer group, click it, then import. That's a current "OK" workaround for what you want, even though it requires a few additional steps.

But we could change the whole feature and when you import a XCF with all its layer, we could create a new group (named by default with the imported file name) and put all layers in it. I agree.
Comment 3 Jehan 2013-09-13 03:11:42 UTC
I recently stumbled upon the "Smart Objects" of Photoshop, then I checked the description on Adobe page and video (http://help.adobe.com/en_US/photoshop/cs/using/WS41A5B796-6846-4e95-8459-95243441E126.html); and I realized it was very similar to my "link" layer proposal, though my proposition is still closer to blender's linked objects.

All 3 would allow to work on object scale/position/opacity non-destructively.

Smart objects though embeds the original image, and that means you can't edit pixels at all, as they say on the linked page:
"You can’t perform operations that alter pixel data—such as painting, dodging, burning, or cloning—directly to a Smart Object layer, unless it is first converted into a regular layer, which will be rasterized."

Whereas my proposed feature would allow to work on the linked image's (but not as a linked layer. You would open the image separately, modify it, save it; and the linked image would update), same as in blender.
Also you can link a same image in several different XCF files.

The drawback is obviously that if you move the linked images, you "break" the link.
Also since currently all GEGL filters modify the original layer pixel, well we can't use filters on a linked layer (Photoshop has non-destructive filtering if I understand), until we implement this kind of non-destructive editing ourselves.

As a consequence, I think the "linked object" idea from blender is similar to the smart objects from Adobe, but will be much more powerful in the end (when we will have non-destructive editing).
Comment 4 andrea.ghensi 2013-10-14 12:42:19 UTC
I really would like to see such function in GIMP!
I'm using a trial version of photoshop to attend an online course, and smart objects are well covered because of the flexibility and non-destructive editing capabilities you gain.
To correct Jehan, in PS smart objects are embedded in the PSD file, but you can edit them by double clicking on the layer thumbnail. that way the image opens in its default editor and you can make all the adjustment you like. when you save, the main project updates itself. The statement in Adobe page simply says that you can't edit the image _directly_ from the main psd file (but a new layer and "merge sampled" work well in many cases).

Also, a nice feature allows you to replace a smart object with another image in a few clicks, so you can basically have a "template" that can be reused. 
So the workflow Jehan mentioned could be done by using a "master" XCF with the background and a "smart object" with a placeholder image that can be replaced by the actual object. A little bit of scripting and you can create multiple XCFs or flattened images in no time.

I don't know which method works best, maybe it could be an user choice when you create/import the object (a simple "link" checkbox).

Oh, and if the PS smart object is a shape (vector) layer, it opens in illustrator for further editing. I wish we can do it also with gimp and Inkscape someday!
Comment 5 Jehan 2013-10-15 01:56:42 UTC
Andrea,

Thanks for the additional information on how PS smart objects work!

I still prefer the link version, because you don't even have to ever "replace" explicitly by the actual object after an update.

But I could still see that we could load a snapshot version of a linked image (which would be equivalent). Then when we reload the image having a link, if ever the linked image has disappeared, we would still display the previously created snapshot, and a small "broken link" icon in the layer list for instance. But if the linked image is still available, we just load the new version and replace the snapshot.

This way, we have the better of both world, and don't need a user choice.
Comment 6 Steve Hardy 2013-10-24 21:18:41 UTC
Andrea’s description of how Photoshop works with it’s Smart Objects is correct.
If I could make two points as a commercial user of Photoshop (Windows) and occasional Gimp user (Ubuntu).

Non-destructive editing and smart objects are what make Photoshop what it is. I could imagine few commercial jobs, certainly on the creative side, done without these features. When dealing with a constant stream of change requests from clients; “could you make this element much smaller” - next day - “Oh no, we must have than three times the size!” you can bill the client for changing the element, not finding the original, re-importing etc. One small thing but multiplied over the months...

The second point is about having linked files. This would work for the well organised person with a bit of technical savvy, sadly that’s already dismissed most of the creative industry as potential users. Adobe Illustrator uses linked files and it is the bane of many peoples lives who have to handle files received from designers, who often produce the great designs, but do not have a technical bone in their bodies. The time spent on the phone chasing the missing files... This is probably why PDF has become so essential in the design world as the age of missing files is rapidly becoming a thing of the past.

I cannot recall the name of the programme but linked files were tried many years ago, around the time Photoshop was starting out as I recall. Then it was used to allow the production of large designs beyond the capability of the then current hardware.

I think what I’m trying to say is that the whole concept of linked files confuses the average person and often even commercial users are surprisingly non-technical.

Steve Hardy
Comment 7 Jehan 2013-10-24 23:53:34 UTC
Hi Steve,

thanks for the input. I see your point. Well then I'd say that the previous idea of a link with an embedded snapshot is worth it. Then we have the power of the link, but if the user loses it, at least one can continue to work or just view the work with the embedded version (possibly outdated).

I don't think we should just eliminate the link idea altogether just on the account that some users are not advanced, thus losing a very nice feature for all the organized users. Let's just make everybody happy with link + embed. :-)
Comment 8 Chris Mohler 2013-10-25 01:56:29 UTC
How about the Scribus approach?  File->Collect for output, which create a new directory containing: XCF with modified paths, all linked resources, document fonts?

It's a catch-22: just embed files, and if you need to make a change you have to edit the original, find the embedded in your source doc, delete, embed again.  But if you just link, it's easier to edit the imported files, but if the source file it sent/moved the linked files will be missing.

I prefer to leave everything linked until publish time and submit a format like PDF.  And if the source needs to be submitted, I just archive the whole project folder (eg for Illustrator), or use "collect for output" or similar (eg for Scribus).

The hybrid approach sounds interesting though.
Comment 9 Steve Hardy 2013-10-25 16:14:09 UTC
InDesign has collect for output, nowadays I'm not sure how often this is used as (as Chris says) most people generate PDFs and send them.

Chris, in Photoshop if using the Smart Object functionality the full original file is embedded in the PS file, whether it's another PS file, Illustrator, RAW Tiff etc. To edit you just double click in the layers palette and it opens the file in the original programme, edit it, save and it automatically updates the PS file. It's very effective.

I must mention that the whole shebag does depend one one other Photoshop advantage: the ability to handle large file with almost magical ease. Even small posters with a bit of "creativity" can reach a gig in file size, the biggest I've done is just over 2 gig for an exhibition poster. Photoshop opens a 2 gig file on unexceptional hardware (4 year old 4 core intel, 4 gig ram) in under 2 minutes and when open you can "throw the file around" as if it were a 40 meg file. Not being a programmer I have no idea how they do this but it's very impressive especially for us older guys who remember having trouble opening 10 meg file in PS on a pre 95 version of Windows!

I will agree that, as long as embed is the default, having linked files would not be a bad thing.

I suppose my original point was more about the potential average user. Those here are a self selecting group who are fairly comfortable with the technology but out "there" there are many users who, whilst being much better designers than say I am, force themselves to learn just what they have to to get the job done. The more you can turn the tech into "magic" the more you might attach these kind of people. I will admit though PS is hardly easy!

Steve
Comment 10 BernardoMello 2015-03-21 19:58:58 UTC
Olá, vim até o bugzilla pois não encontrei outro canal para acrescentar uma ideia ao projeto Gimp. Sou designer e comecei a utilizar softwares livres para trabalhar pois não tinha condições financeiras de pagar por softwares pagos como Illustrator, Photoshop, Coreldraw, etc, e não queria ser antiético ganhando dinheiro as custas dos demais; busquei no Gimp, Inkscape, Scribus e Blender a solução, mas o que encontrei foi mais doq ue uma solução, encontrei ótimos softwares, e mais: ótimos softwares gratuitos kkkk...buscando me adaptar aos softwares livres busquei ferramentas e plugins que os assemelhassem ao máximo com os softwares pagos, entretanto nem tudo foi perfeito neste aspecto. Porém, ainda assim, encontrei alternativas viáveis para algumas. Uma das ferramentas que achei uma solução viável foi para os Objetos Inteligentes do Photoshop; uma vez que o Gimp não tem suporte para Objetos inteligentes, pelo menos não ainda, comecei a utilizar o software livre SmillaEnlarger (http://www.baixaki.com.br/download/smillaenlarger.htm) que pode redimensionar imagens exatamente como é feito pelos Objetos Inteligentes do Photoshop, senão com ainda mais qualidade. Por esta razão, gostaria de sugerir aos desenvolvedores Gimp realizarem uma parceria com os desenvolvedores do projeto SmillaEnlarger, buscando criar um plugin, ferramenta, etc, que possa atribuir ao Gimp esta função tão essencial para a área de design e fotografia em uma velocidade ainda maior. Obrigado, espero poder ter contribuido de alguma forma!
Comment 11 Jehan 2015-04-02 18:13:02 UTC
I don't speak Spanish, but I think the above comment is spam. And a link with the word "enlarger" in it, I don't even want to click.
Could an admin remove this (and maybe block this user, since it does not look like he ever posted anything else)? Thanks.
Comment 12 Jehan 2015-04-02 18:28:14 UTC
So it turns out (thanks to Spanish-speaking team members, thanks!) that this comment may not be a spam, but genuine. In this case…

BernardoMello > Could you please write down in English (I'm sorry but this is our communication language), and explain us what is the relationship between what you are saying and the topic of this feature request. Because from what we understand (you want GIMP to use upscaling algorithm in SmillaEnlarger), this is totally irrelevant.
Comment 13 Joao S. O. Bueno 2015-04-02 18:30:11 UTC
It is Portuguese. It is not spam - but not event trying to use English, the guy exhibits a level of cluelesness I had not met before.  The link is downloading the Windows binaries (possibly malware enhanced binaries - "baixaki" is one of those download sites)  for  a free software project that would supposedly implement some of the "Smart" features for Photoshop mentioned elsewhere in the discussion here. (So at least there is some context to what he posted).

The project sourceforge link is: http://sourceforge.net/projects/imageenlarger/
(remember to watch for malware on sourceforge too) 


as for your request (the bug report) - maybe we could limit this request to
the "1" form -which would serve GIF, PDF and TIffs as well as XCFs 
(and adding a explicit "new group" checkbox, and a possible "flatten" checkbox)

The "link" version could be handled by a non=-destructive layer which cound contain arbitrary gegl graphs (including file load)  -  I see this is a more or less natural thing we will put on GIMP sooner or later, but we have to think on the UI for that (as on all the work needed) - anyway, "xcf_load" would be one of hundreds of options to combine in a "gegl layer" ("smart layer", "adjustment layer" or whatever) and we could detail it elsewhere.
Comment 14 Anne Adventure 2015-06-19 18:01:05 UTC
Should'nt we open a dedicated ticket for the "non destructive editing" mode (similar to the Photoshop "smart objects" system)?
Comment 15 David Philipe Gil 2015-08-27 18:31:45 UTC
I agree GIMP should have a non-destructive editing mode. Does anyone know the state this is in?
Comment 16 Michael Schumacher 2016-05-30 14:12:17 UTC
Non-destructive is where GIMP is heading as a whole. A meta-bug listing individual bugs for the changes (or even better, a (set of) entries in the GIMP wiki detailing the tasks), might be better than a single bug.
Comment 17 Jehan 2016-05-30 14:24:57 UTC
I agree. This bug report is for a specific feature though (even though this feature is relevant to the whole non-destructive plans): advanced ways to import images as layers (and in particular with possibilities to keep a "link" to the source, hence the non-destructive relationship).

So let's avoid to diverge the topic into other features please.
To answer the few questions above: there is no state right now because no patches have been done. I have high interest in this, but can't make the time right now. So I set back to status "New". Anyone who wants to contribute code for this feature is welcome to do so.
Comment 18 GNOME Infrastructure Team 2018-05-24 13:31:54 UTC
-- 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/453.