Thank you, Egor! Yes, Ai is the industry standard for apparel design which I don't think is often recognized when thinking about some of the tools end uses. My current company has at least 50 or so designers who could benefit from a tool like this and I know other major apparel brands are the same (I have worked for 5 over the past 20 years). By the way- turntable is really starting to pick up steam for us!! We can use it for additional views sometimes needed by factories (side views, a glimpse at the inside of a garment that is lined with a different color etc.) Would be even more incredible if it didn't expand your outlines- and that brings us full circle to this tool request. In both cases it would generate new images that remain their ability to be edited. Also happy to chat more about apparel workflows if that’s helpful — feel free to reach out anytime.

That’s a great exploration. Thank you so much for making all the effort describing the workflow and creating a request in the first place.
This is what I love about Ai — people making actual work with it. My personal opinion is that while Turntable is flashy toy, fueled by a bunch of predictions, dealing with a lot of low-level assets (and I consider symbols to be the under-loved entities) is what Ai needs. Small things + professional things.
I’ll try to get more attention to it, please do the same — share a link with those you think would love it. Vote count matters, and I believe apparel and textile designers use Ai a lot.

Please see the attached example for a rough example of a merge workflow that compares two design states, preserves structure and color relationships where possible, and surfaces only unmatched objects for manual resolution.

Hi Egor — this is a helpful breakdown, and I think the key gap is how the workflow plays out in practice.
The example I shared is a simplified version — in reality, the types of changes we make to a style often do break the conditions where color is preserved.
In many cases, updating a design involves:
* Replacing shapes entirely (rather than morphing them)
* Breaking edges or bounds of an object
* Creating new objects within the symbol
For example (shown in the attached):
* Converting a flap pocket into a rectangular patch pocket
* This is not done by modifying the original shape — it’s typically rebuilt as a new object (mush simpler update)
* As a result, the new object does not retain the original color
This ties into your point about new objects not triggering anything — that is exactly the issue in practice.

Where this becomes a larger problem
This is a condensed example — in reality, a single garment can have 20–30 colorways.
When a structural update like this happens:
* Each new or rebuilt element must be manually recolored
* Across every color variant
So instead of updating one design, we are effectively reapplying color logic dozens of times.

Important distinction
If a new object truly has no visual relationship to an existing element, it’s reasonable that it would need to be colored manually.
The challenge is when updated geometry does conceptually relate to an existing part of the design (e.g., a pocket replacing a previous pocket), but that relationship is not recognized.
In those cases, all color information is effectively lost, even though the intent is a direct replacement — and that is what creates the majority of the manual rework.

On Color Theme Picker
Color Theme Picker doesn’t solve this for our workflow because:
* We work from a fixed, company-wide palette (often ~100 colors)
* Colors must be applied to very specific regions of the garment
* Automatic color remapping does not preserve the intended placement of colors
So while it’s useful for palette exploration, it doesn’t provide the level of control needed for production workflows like this.

Ultimately, the challenge is not just preserving color — it’s maintaining the relationship between color and structure as the design evolves.
Let me know if helpful to expand further — happy to share more cases if useful.

Also, we might go through these types of changes in a garment from 2-10 times in a season as we fit it and review the design. So it can become quite tedious after a few rounds of changes.

Thank you for looking into this!! A solve would be extremely helpful for my company’s large pool of designers. Looking forward to continuing to discuss this and hear any other thoughts or suggestions.

I see. Indeed, in dynamic symbols making a duplicate of existing shape won’t make it get the same color (even a global one) assigned to a symbol’s instance (so creating a pocket from another pocket won’t work). Altering a shape doesn’t force it loose local color applied though, so altering a pocket into another pocket would work. And surely new objects inside made won’t trigger anything at all.
Some recognition would be required to detect a new pocket and see an older design had something similar, to adopt its look.

Have you tried Color Theme Picker in the compact Recolor? I hope it could wok for this case, but I don’t think it does.

Thanks for asking for a more complex example — sharing one here to better illustrate the workflow.
In this scenario:

File 1 contains two versions of the same symbol:

a base design
and an updated version that introduces structural changes (e.g., pocket shape, seam placement, proportions)

File 2 contains multiple color variants of the original design, where each variant has its own unique distribution of color across different regions of the garment

Goal
Apply the structural updates from File 1 across all variants in File 2 while preserving each variant’s existing color logic.

Why this is difficult today
The challenge is not just transferring shapes — it’s maintaining the relationship between structure and color across multiple variants:

When geometry changes (e.g., pockets or seams), the underlying regions that define where colors are applied also change
Each variant has a different color layout, so the result cannot rely on a single shared appearance
There is no way to automatically detect how updated structural elements should inherit or map to the correct color regions in each variant

This results in a highly manual process:

Rebuilding or re-mapping color regions for every variant
Reapplying fills and details individually
Repeating the same update across all colorways

Desired capability
A workflow that can:

Compare two related design states (original and structurally updated)
Detect and apply structural changes to a target set of variants
Preserve each variant’s existing color placement, even when the underlying geometry has changed

This becomes especially important in symbol-based workflows, where a single structural update needs to propagate cleanly across many variations without breaking or redefining the visual styling in each one.
Let me know if helpful to expand further — happy to share more about our workflow to help further explain.

Interesting. A 'style eyedropper' of sorts?
The example is somewhat simplified (and is solvable with a current Eyedropper’s click), but you mention a specific workflow — can you please share several examples, complicated enough to see where the current toolset is lacking?