Skip to main content

Filter by idea status

10000+ Ideas

kk1018
kk1018Participant

I would like to be able to set the brush color of a paint layer using the Python API.Open for Voting

## SummaryPlease add a Python API to set the active brush color (Base Color and other channels) on Paint Layers.## ProblemCurrently, there is no way to set the brush color of a Paint Layer through the Python API in Substance 3D Painter. The available APIs allow:- Reading and writing **Fill Layer** uniform colors via `_substance_painter.source.set_source_uniform_color()` and `set_fill_source()`- Reading and writing **shader parameters** via `alg.shaders.setParameters()` (but this only covers shader-level params like sssColor, not the active brush color)However, there is no public or private API to set the **active brush's Base Color** that gets applied when painting on a Paint Layer.## Use CasesThis limitation blocks many useful tools and workflows:1. **Per-stroke color picker / eyedropper plugins** - Sample colors from the viewport, a reference image, or a baked map (World Space Normal, Position, etc.) and apply them as the brush color for each stroke. This is critical for stylized texturing workflows.2. **Color palette plugins** - Custom color management UIs that let users build palettes and quickly switch brush colors via shortcuts or buttons.3. **Procedural color workflows** - Drive brush color from external data sources (CSV files, gradient curves, animation keyframes, etc.).4. **Tablet/hardware integration** - Bind brush color to physical color picker devices, MIDI controllers, or other input hardware.5. **Multi-channel synchronized painting** - Paint Base Color, Roughness, and Metallic simultaneously with values derived from a single source.## Workarounds Attempted (and why they fail)- Sending keyboard shortcuts (e.g., 'P' for the native eyedropper) via QApplication: unreliable, doesn't allow programmatic color values- `alg.project.settings.setValue("painting/color", [r,g,b,a])`: writes to a project key-value store but does not affect the brush- `alg.shaders.setParameters()`: only works for shader-level parameters (sssColor, etc.), not Base Color- Modifying `PaintLayerNode` properties: no color-related methods exposed- QML widget manipulation via Qt widget tree: blocked, color picker widgets cannot be modified externally- Using Fill Layers as proxies: works for fill content, but doesn't translate to actual brush behavior on Paint Layers## Proposed API```python# Pseudocodeimport substance_painter.toolsubstance_painter.tool.set_brush_color(    channel_type=ChannelType.BaseColor,    color=(1.0, 0.5, 0.2)  # RGB 0-1)# And/or per-channelsubstance_painter.tool.set_brush_value(    channel_type=ChannelType.Roughness,    value=0.7)```Alternatively, exposing the existing internal mechanism that the Material panel uses to update brush colors would solve this.## ImpactThis single API addition would unblock an entire category of plugins and significantly extend Painter's scriptability. Many users in the texturing/stylized art community have requested this functionality for years.Thank you for considering this request.

MagicalSakuraParticipant

It would be nice if Photoshop wasn't bloatware.Open for Voting

I'm incredibly frustrated with Adobe. I've been using Photoshop CC 2018 since likely 2018 and recently Adobe made it so I could no longer use the software despite my subscription. Instead of opening the app, it gives me the option for a trial version of Photoshop CC 2018. Adobe support told me there was nothing they could do to fix this aside from updating the software or pirating it. The person I spoke to literally told me I should try pirating the software when I asked if that was the only way to use an older version of the software. I'm extremely frustrated because the latest version of Photoshop has ridiculous spec requirements. Photoshop 2018 only needed a minimum of 2gigs of RAM and recommended 8 gigs of RAM. The latest version of Photoshop needs a minimum of 8 gigs of RAM but recommends 16 gigs of RAM. This is getting ridiculous. I primarily used Photoshop for editing, color balance, and text. I do not need any of the new features nor do I want any of the generative AI crap.  I have not and will never use Adobe Cloud storage as Photoshop is too bloated to use on anything but my desktop pc. I don't need or want any of the updates. I primarily use the latest version Clip Studio Paint for my creative work and it has basically the same spec requirements of Photoshop 2018. Clip Studio Paint is frankly a better program for digital painting, but I still liked Photoshop for editing and preparing print files. I don't understand why photoshop is so ridiculously bloated. I also don't understand why I can't continue to use Photoshop 2018 when I don't use any of the cloud features. I don't understand why the programs are so bloated despite the fact people are, or were, paying a subscription. Why can't photoshop be smaller and run more smoothly with all that people are paying you'd think they'd make a lighter program that doesn't eat 50gig of space just by being open. 

thomas5CEDInspiring

P: Custom Whitepoint adaption when changing Camera ProfilesOpen for Voting

When switching Camera profiles in LrC and “As Shot” white balance is selected, LrC will change the Temperature/Tint so the visual result is the same before and after the profile switch. Yet, when the whitepoint is set to “Custom” the numbers are not changed so the visual result is different. Since this is hard to explain here is a small screencast: notice that Temperature changes when white blaance is “As Shot” (“Wie Aufnahme”, sorry for German), but does not change when it is set to “Custom” (“Benutzerdefiniert” in German).  The user effect is the follows:With as shot white balance: the image is visually kept identical (apart from the different camera profile), with the same temperature and tint even though numbers change With custom white balance: the image visually changes, the perceived temperature and tint is different in addition to the different camera profile When using the white balance picker tool a neutral gray patch that was selected with one profile is not neutral gray with another profile This sounds clearly unexpected to the user.Now I can understand this decision: with custom white balance the user gave us exact numbers, so they are never changed. With “As shot” the user doesn’t care about the numbers, but the photo should look the same as shot, so updating the numbers is okay. Yet, I’d argue that even with custom WB, the user is more interested in keeping the photo visually similar with the same visual tint and temperature and not numerical. This is a feature request to change the behavior and always adapt white balance to the color profile and not only for “As shot”. Technical details, this is just my understanding of DNG/DCP, you can skip the rest if not interested.  I worked with DNG/DCP profiles before, So I understand what is happening. “As shot” white balance is usually encoded in camera space (in AsShotNeutral) whereas temperature/tint give xy color space (camera independent) numbers. The conversion from camera color space to xyz is basically the camera profile. White balance always happens in camera color space. SoAs shot always does: AsShotNeutral is already camera color space, so it can be directly used for WB correction For display we need temperature/tint, so we do: AsShotNeutral → xy → temperature/tint when the camera profile changes, the xy conversion changes, so numbers change Yet, AsShotNeutral DOES NOT change, so the actual WB does not change With custom WB:  We ignore AsShotNetural for Whitebalance instead we do  temperature/tint → xy → whitepoint in camera space we use this white point for correction Since the xy → camera space conversion changes with the profile, the WB correction is now different, even though numbers are the same What this feature request technically asks to do is to adapt the xy white point on profile change. Let’s say we change from profile A to profile B. Then the white point is updated such that we do old WP xy → profile_A → WP in camera space → profile B → new WP xySo to make sure that the white point correct in camera color space stays the same, we transform the custom whitepoint to camera color space and back.

touchbParticipant

P: (Masking) - Sync on faces, not person numbersOpen for Voting

Hello,   TLDR: I wish the Ai was more clever when syncing subject masks, syncing faces rather than 'Person numbers'    While editing I often create Ai subject masks for one or two people in an image. Let's say it's the bride & groom walking down the aisle for example... I've then got a big sequence of these images that I would like to sync.  But when you sync, the Ai more often than not decides to choose 2 random people sitting off to the side, instead of the first image where I've selected the bride & groom.    Looking into it deeper, it seems it always syncs the 'person number(s)' rather than the actual intended target. So after correcting the mask to the correct people - some shots of the bride & groom could be labelled differently... 'Person 2 & Person 3' while the next shot could be 'Person 3 & Person 4' or if it's getting it really wrong 'Person 5 & Person 6' ....even though the shot is only marginally different from the first.    It would be good if there was some rhyme or reason to it, but it seems it's just random as to how Adobe and the Ai software are numbering each 'Person' in the shot. It then takes a great deal of time to delete the incorrect mask and reselect the correct person every time for each shot.   It already recognizes each face, why can't it sync on the face rather than the person numbering system? There's probably a reason but would be a brilliant improvement and a massive time saver!  I surely can't be the only one.    Thanks for listening.   Cheers.