RSS/Atom feed Twitter
Site is read-only, email is disabled

Using GIMP in the textile industry

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

10 of 10 messages available
Toggle history

Please log in to manage your subscriptions.

Using GIMP in the textile industry Simon Budig 28 May 11:24
  GIMP in the textile industry: handling of indexed colors Simon Budig 28 May 11:26
  Using GIMP in the textile industry Simon Budig 28 May 11:30
   Using GIMP in the textile industry Tobias Ellinghaus 04 Jun 12:31
    Using GIMP in the textile industry Jehan 04 Jun 13:13
  Using GIMP in the textile industry Simon Budig 28 May 11:31
  Using GIMP in the textile industry Simon Budig 28 May 11:34
  Using GIMP in the textile industry: Document Management Simon Budig 28 May 11:35
  Using GIMP in the textile industry Sven Görsmann via gimp-developer-list 28 May 11:41
   Using GIMP in the textile industry Joao S. O. Bueno via gimp-developer-list 28 May 13:27
Simon Budig
2019-05-28 11:24:20 UTC (almost 5 years ago)

Using GIMP in the textile industry

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

simon@budig.de              http://simon.budig.de/
Simon Budig
2019-05-28 11:26:44 UTC (almost 5 years ago)

GIMP in the textile industry: handling of indexed colors

Hi all.

Please see my previous mail for more context of this problem.

So here we go about the handling of colors in indexed images:

In the current toolchain for the carpets the images are indexed, i.e. instead of RGB data per pixel each pixel stores an index into a color palette.

At the company it is important to have good tools to manipulate color palettes and I think there definitely is room in GIMP for a plugin that provides advanced control over the colors contained in a project specific palette as well as tools to control names and order of the color entries.

In GIMP color palettes are available and they also can carry names. But while you can use these palettes to create indexed images, the indexed image itself carries a "colormap" which does not provide named colors. It would be necessary to extend the core to store names associated to the indexed colors. A small sideproject then is to make sure that these color names also end up in the final resulting image, one thought there was to define and write a specific text chunk into a PNG file that provides advanced information about the palette.

I personally think that this would be a welcome addtition to GIMP. It also is a project that is not too huge and might be beneficial to other usecases as well.

I'd welcome input on that topic.

Bye, Simon

simon@budig.de              http://simon.budig.de/
Simon Budig
2019-05-28 11:30:08 UTC (almost 5 years ago)

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

simon@budig.de              http://simon.budig.de/
Simon Budig
2019-05-28 11:31:55 UTC (almost 5 years ago)

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

simon@budig.de              http://simon.budig.de/
Simon Budig
2019-05-28 11:34:53 UTC (almost 5 years ago)

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

simon@budig.de              http://simon.budig.de/
Simon Budig
2019-05-28 11:35:44 UTC (almost 5 years ago)

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

simon@budig.de              http://simon.budig.de/
Sven Görsmann via gimp-developer-list
2019-05-28 11:41:07 UTC (almost 5 years ago)

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

--
simon@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

Joao S. O. Bueno via gimp-developer-list
2019-05-28 13:27:33 UTC (almost 5 years ago)

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 ><
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 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

--
simon@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

Tobias Ellinghaus
2019-06-04 12:31:59 UTC (almost 5 years ago)

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

Jehan
2019-06-04 13:13:01 UTC (almost 5 years ago)

Using GIMP in the textile industry

On 2019-06-04 14:31, Tobias Ellinghaus wrote:

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.

How we handle images in single window mode is anyway a real pain to me. Splitting a single tab to show several views of the same image or even different images is indeed a great idea. But also we should be able to detach image tabs (which is what you call rip-off windows, I guess?) into their own windows (same as we can detach dockables even when in single window mode). I personally don't believe this to be confusing. I mean detaching tabs is a common feature in many software (like web browsers!), and it allows to do much more than being limited by what the program will allow you. First of all, if you have several screens, you can leave some images on one screen (say your reference images) and others on another screen (the image(s) you are working on for instance). And more usage (you are then only limited by your window manager).

In other words, we should stop with the whole single vs multi window mode nonsense. We should simply have a single mode allowing all possibilities (attaching or detaching images, dockables, toolbox, etc.).

This is something which have been on my TODO-list for years, and I am never able to make the time to do this. I would support anyone wishing to work in such directions. :-)

I'm also CC'ing the gui list as that seems to be a better place for this part
of the discussion.

By the way, maybe you want to subscribe to the gui list. I had to manually approve this email. :-)

Jehan

[...]

Bye,
Simon

Tobias

_______________________________________________ gimp-gui-list mailing list
gimp-gui-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-gui-list

ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot