Re: [Gimp-developer] Using GIMP in the textile industry
Hi all. Please see my previous mail for more context of this problem. We also discussed some changes to the UI: The company representative I was talking to was also concerned about the amount of functionality in the GIMPs UI and fears that it might be overwhelming to the operators, plus that it also makes it easy to use functionality that actually is harmful to the task at hand. I explained that it is possible to reduce the amount of stuff shown on screen (including making specific tools invisible, possibly even changing XML files to reduce the number of menu entries), but also mentioned that we're not too keen on having that, since it possibly increases the support ballast for our community. It remains to be evaluated how much changes are actually needed there. One thing which came up though (and which we already have discussed in the past IIRC) is the need for a better support for multiple documents in single window mode. The software they're using currently is using a classic Windows Multiple Documents Interface (MDI) and they do in fact make use of it. I tried to explain why I personally consider GIMPs multiple window interface as quite good, but the not-so-great support for multiple desktops in windows (and the bad window management) made this a tough point to sell... :) I see two options here and I think we've been discussing these in the past. a) create multiple side-by-side image views within the single window mode. We could allow for tiling the image area into multiple notebooks, each containing its own set of images, allowing for Drag'n'Drop between them etc. ppp. My gut feeling is that this should be quite doable. It might be a bit tricky to control the keyboard focus there and to make it clear to the user, which of the images will be affected by the next keystroke. b) (not necessary XOR) it might be feasible to allow for a kind of hybrid single/multiple window mode, where one can drag out notebook-tabs into their own image view that then is managed by the window manager. So we would have one dedicated main window containing the toolbox and the notebook-area with image views as well as separate windows containing image views (or a notebook of image views?). Not sure how much consensus we have on this point and what amount of effort is needed here. Another thing related to the UI was to have a dockable, which would contain a configurable set of buttons referring to specific actions (as in "menu items"). That might be a handy thing for quickly acessing frequently used functionality. Another thing was a histogram for indexed images: Obviously counting the indexed colors is important to calcuate the amount of color needed for the carpet. The current histogram dockable could be extended with a more tabular view for indexed images. I'd welcome input on that topic. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Using GIMP in the textile industry
Hi all. Please see my previous mail for more context of this problem. In the textile industry working with patterns is hugely important: One quite important aspect of designing carpets is dealing with patterns. The kind of projects we're talking about here is of the scale "print carpet for a whole building, adhering to a common design across the building". So the layout of the building is known and the area of the floors gets "sliced up" in advance so that it is known, which part of the room will be filled with what part of the carpet run. It is vital that the patterning of the carpet will seamlessly match when the carpet runs are finally placed in the building. In GIMP the fill tool provides no control over how a pattern is placed in the selection to be filled, which in this context obviously is a huge problem. I imagine it should be feasible to provide on canvas controls for the fill tool, allowing to move a pattern around and to finetune how a pattern is placed inside the selection. I also saw other workflows where they worked with patterns dragged onto the canvas and subsequently being expanded onto the image by dragging on the pattern bounding box. The pattern in this case would be "locked" into a specific position. One application is to place a pattern for a trim on the carpet and then expand it in a repeating manner across one side of the carpet. I am not sure if this is a feasible thing for GIMP. I'd welcome input on that topic. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Using GIMP in the textile industry
Hi all. Please see my previous mail for more context of this problem. Working with indexed images: I witnessed one very funky way of working with indexed images and I am not sure if I have fully wrapped my head around the ways they use some features of the proprietary tool they're using now. The tool in question does not provide multiple layers, but it does have some sort of floating selection. It however has funky means of dealing with indexed images. For each entry in the color palette you can a) set the resp. color to transparency and b) protect specific colors I've seen these features used in various workflows: * If you want to extend a patterned area you'd drag the pattern onto the canvas and roughly align it to an already patterned area. You'd then swich some colors to transparency, making it easier to align the patterns in a pixel exact manner. To actually do the expansion of the patterns you'd then make the colors visible again and drag on the bounding box of the pattern to extend it into the desired areas. That way it is ensured that the alignment of the new area fits the old area pixel perfectly. * if you want to combine a decor element of a pattern over a different pattern (with the same repeating properties) you can place the new pattern on top of the old one, then protect certain colors of the old pattern and expand the area of the new pattern by dragging on the bounding box. This basically places the new pattern "behind" certain areas (as defined by the protected colors) of the old pattern. This also can be used in conjunction with swiching some colors of the new pattern to transparent, making parts of the new pattern invisible. As I said, I was kind of swamped by the speed the operator toggled the properties of the different indexed colors and it was hard to judge what she actually was trying to do. I kind of suspect that it is worth evaluating if there are more straightforward ways to arrive at the same goal of the workflow, but right now I do not have specific ideas there. That having said: being able to "protect" some indexed colors (in a similiar way to a protected alpha channel maybe?) as well as temporarily making some indexed colors invisible/transparent might be helpful to other pixel based artists as well. Opinions? An interesting side problem is: If we had patterns with indexed colors and would want to use them in an indexed image - how could we go about mapping the two palettes to each other? I'd welcome input on that topic. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Using GIMP in the textile industry
Simon Budig schrieb am Di., 28. Mai 2019 13:24: > Hi all. > > Some of you will have noticed the Mail from Thomas Völker from the end > of last February. He was looking for some Developers for paid Gimp > development. > > [putting on my business head] > > I co-own and work for a small company doing embedded linux / customer > specific application development. > > After discussing this in the GIMP IRC channel I was ready to dip my toes > into the somewhat murky water of doing paid development for my hobby pet > project. So I went ahead and visited the company in question. It was a > nice and productive meeting with interesting questions and I'd like to > ask for your thoughts and input on the problems I'm about to explain. > I'll split up this mail, so that different problems can be discussed in > separate sub-threads. > > If you're interested in doing paid development work on some of these > problems please feel free to speak to me. > > If you're interested in the problems, have input on working with > printing in the textile industry please feel free to speak to me. > > I am currently in Saarbrücken and would welcome discussions about these > topics at LGM. > > > The Problem: > > The Company is based in Germany and is manufacturing carpets, printing > them with various customer specific designs. > > Due to changes in their software toolchain (product upgrades with very > unwelcome additional restrictions) they are looking for free > alternatives and one part of a new toolchain could be GIMP. > > During the two days of my (paid) visit there we tried to assess what > features they need and looked for ways to fit GIMP into their needs. > > I was very clear about that we need to be very careful about feature > additions and how they fit into our future roadmap. That having said I > really do believe that there are areas which would be useful for GIMP, > other things are maybe a bit more tricky to incorporate in a sane manner > into the GIMPs UI. > > As for the background: the company in question manufactures long > (dozends of meters) 4m wide runs of carpet, which then get printed on > with customer specific designs in three different production lines. One > of these lines uses a four color CMYK process, but the focus of this > project are the two other lines using machines to print 24 and 32 > individually mixed colors. > > Since rooms wider than 4m are not uncommon site specific carpets need to > get prepared in a way that multiple runs of carpet can be placed next to > each other and the pattern globally match perfectly. This is one of the > main concerns and I have the impression that the current tools in GIMP > are not that great to deal with this kind of design constraints. > Adressing these might expand our audience further into the realm of the > textile industry, but I also believe that it might be helpful for people > working with textures. To develop tools that make it more easy to work > with this kind of constraints is probably the most tricky and > questionable part of the project. > > Lets first look at the in my opinion quite simple and uncontroversial > things for the GIMP. > > The two printing lines in question print with 24 resp. 32 customer > specific colors. Each carpet project has its own color palette and while > there is a predefined set of color recipes readily available it is not > uncommon that specific projects get their own customer specific > colors. > > That is the basic situation. I'll send some follow up mails for the > following sub-topics: > > - Better handling of colors in indexed images > - Changes to the UI > - Working with patterns > - Working with indexed images > - Integration into a Document Management System > > Thanks! > Simon > > -- > si...@budig.de http://simon.budig.de/ > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Using GIMP in the textile industry
Having read things to this point, a first short remark on the feature you mentioned of allowing a pattern rotation/scaling before filling up an area: That'd be great. I remember we used to have this as a feature request a long time ago (10+ years), and it was dismissed at some point. That was well before we had on-canvas controls. But I think it would be great to have that for the fill tool, and maybe as a post-adjustment when dragging the pattern directly to the image. As for the various instances you mention of "expanding a selection containing a pattern", the current way of doing this with GIMP would be to have initially a layer with a small (GIMP) selection on it, do the proofs there, then recreating a larger selection with the rectangle tool, and re-filling the pattern. Another thing on the top of my mind is the current behavior for a pattern being used in a palette-constrained GIMP image GIMP will transform the colors in the pattern to near colors on the image - a behavior of replacing near-colors, and carefully add new colors could be implemented with the current plug-in system. Best regards, and a nice LGM for however is there! js ><- On Tue, 28 May 2019 at 08:41, Sven Görsmann via gimp-developer-list < gimp-developer-list@gnome.org> wrote: > Simon Budig schrieb am Di., 28. Mai 2019 13:24: > > > Hi all. > > > > Some of you will have noticed the Mail from Thomas Völker from the end > > of last February. He was looking for some Developers for paid Gimp > > development. > > > > [putting on my business head] > > > > I co-own and work for a small company doing embedded linux / customer > > specific application development. > > > > After discussing this in the GIMP IRC channel I was ready to dip my toes > > into the somewhat murky water of doing paid development for my hobby pet > > project. So I went ahead and visited the company in question. It was a > > nice and productive meeting with interesting questions and I'd like to > > ask for your thoughts and input on the problems I'm about to explain. > > I'll split up this mail, so that different problems can be discussed in > > separate sub-threads. > > > > If you're interested in doing paid development work on some of these > > problems please feel free to speak to me. > > > > If you're interested in the problems, have input on working with > > printing in the textile industry please feel free to speak to me. > > > > I am currently in Saarbrücken and would welcome discussions about these > > topics at LGM. > > > > > > The Problem: > > > > The Company is based in Germany and is manufacturing carpets, printing > > them with various customer specific designs. > > > > Due to changes in their software toolchain (product upgrades with very > > unwelcome additional restrictions) they are looking for free > > alternatives and one part of a new toolchain could be GIMP. > > > > During the two days of my (paid) visit there we tried to assess what > > features they need and looked for ways to fit GIMP into their needs. > > > > I was very clear about that we need to be very careful about feature > > additions and how they fit into our future roadmap. That having said I > > really do believe that there are areas which would be useful for GIMP, > > other things are maybe a bit more tricky to incorporate in a sane manner > > into the GIMPs UI. > > > > As for the background: the company in question manufactures long > > (dozends of meters) 4m wide runs of carpet, which then get printed on > > with customer specific designs in three different production lines. One > > of these lines uses a four color CMYK process, but the focus of this > > project are the two other lines using machines to print 24 and 32 > > individually mixed colors. > > > > Since rooms wider than 4m are not uncommon site specific carpets need to > > get prepared in a way that multiple runs of carpet can be placed next to > > each other and the pattern globally match perfectly. This is one of the > > main concerns and I have the impression that the current tools in GIMP > > are not that great to deal with this kind of design constraints. > > Adressing these might expand our audience further into the realm of the > > textile industry, but I also believe that it might be helpful for people > > working with textures. To develop tools that make it more easy to work > > with this kind of constraints is probably the most tricky and > > questionable part of the project. > > > > Lets first look at the in my opinion quite simple and uncontroversial > > things for the GIMP. > > > > The two printing lines in question print with 24 resp. 32 customer > > specific colors. Each carpet project has its own color palette and while > > there is a predefined set of color recipes readily available it is not > > uncommon that specific projects get their own customer specific > > colors. > > > > That is the basic situation. I'll send some follow up mails for the > > following sub-topics: > > > > - Better handli
Re: [Gimp-developer] Using GIMP in the textile industry
Am Dienstag, 28. Mai 2019, 13:30:08 CEST schrieb Simon Budig: [...] > One thing which came up though (and which we already have discussed in > the past IIRC) is the need for a better support for multiple documents > in single window mode. The software they're using currently is using a > classic Windows Multiple Documents Interface (MDI) and they do in fact > make use of it. I tried to explain why I personally consider GIMPs > multiple window interface as quite good, but the not-so-great support > for multiple desktops in windows (and the bad window management) made > this a tough point to sell... :) > > I see two options here and I think we've been discussing these in the > past. > a) create multiple side-by-side image views within the single window > mode. We could allow for tiling the image area into multiple > notebooks, each containing its own set of images, allowing for > Drag'n'Drop between them etc. ppp. My gut feeling is that this > should be quite doable. It might be a bit tricky to control the > keyboard focus there and to make it clear to the user, which of the > images will be affected by the next keystroke. > > b) (not necessary XOR) it might be feasible to allow for a kind of > hybrid single/multiple window mode, where one can drag out > notebook-tabs into their own image view that then is managed by the window > manager. So we would have one dedicated main window containing the > toolbox and the notebook-area with image views as well as separate > windows containing image views (or a notebook of image views?). What about this: The tabs in single image mode are not just for one image each but contain "workspaces". By default an image is opened in a new workspace containing a single image, so it's the same we currently have. It would however be possible to split the image area to show more than one image or view. I somewhat like the quick and easy way that's done in blender, however, one would need to think about what to do when the last view of an image is closed. That way each tab could contain a arbitrarily complex setup of image views with the toolboxen staying the same for all of them. Having rip-off windows might be nice, but I personally don't feel the need, and having both a single image window mixed with some floating windows might be confusing. I'm also CC'ing the gui list as that seems to be a better place for this part of the discussion. [...] > Bye, > Simon Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Using GIMP in the textile industry: Document Management
Hi all. Please see my previous mail for more context of this problem. Integration into a Document Management System It will be necessary to incorporate GIMP into a site specific Document Management System. I kind of suspect that this will end up being either a separate plugin to access the files within the DMS. As of now I am unsure what is needed there exactly and if it maybe is feasible to develop something a bit more flexible, allowing for an integration into different DMS backends. This very well might end up in a customer specific plugin. If someone more familiar with DMS's than me has any input on that I'd be glad. I'd welcome input on that topic. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
