Skip to main content

Filter by idea status

10000+ Ideas

Hugo TorresParticipant

Expose Firefly generation (image + video) via MCP/API so it can be driven from Claude and other AI agentsOpen for Voting

Adobe already ships an MCP connector that lets Claude reach Creative Cloud — asset storage, Lightroom-style adjustments, background removal, vectorise, InDesign merges, video render. It's genuinely good. But the one thing it can't do is the thing Firefly is actually for: generate an image or a video from a prompt.That means my workflow is split down the middle. I plan a sequence with Claude — shot list, prompt text, aspect ratios, continuity notes — and then I have to hand-carry every prompt into the Firefly web UI one at a time, download the outputs, re-upload them, and manually keep track of which frame is which. For a 7-episode vertical micro-serial, that's hundreds of context switches for work the agent could already orchestrate end to end.Higgsfield shipped an MCP server this spring that does exactly this, and it's now the default entry point for a lot of us: connect once, describe the shot, the agent picks the model, fires the generation, polls, and returns the clip in chat. It works from Claude web, desktop and Claude Code. No API key — OAuth through the account you already pay for. The result is that Firefly, which has better provenance, better integration with the rest of the Adobe stack, and a licensing story no one else can match, is losing agent-driven work to a competitor purely on plumbing.What I'm asking for:Text-to-image and text-to-video generation tools in the existing Adobe MCP server — same auth, same asset storage, outputs landing straight in Creative Cloud Files. Availability on individual Creative Cloud / Firefly plans, not enterprise-only Firefly Services contracts. The people building this way are mostly solo creators and small studios. A CLI for terminal-based agents, so the same generations can run inside scripted pipelines. Batch and reference support — style/character reference images, multi-shot batches, seed control. Consistency across shots is the whole game for narrative work. Content Credentials preserved on every asset returned through the API. This is Adobe's genuine differentiator, and it should be the default, not something I have to reattach later.Why this is worth building: agent-orchestrated generation isn't a niche. It's becoming the way serialised and high-volume creative work gets made. Adobe already has the models, the storage, the editing tools, and the connector. The generation endpoints are the missing link, and without them the connector reads as a nice editing utility rather than a production environment.

Hard CoderKnown Participant

P: Better (actual) color grainOpen for Voting

So, good color grain simulation is pretty hard to find, and a while back I came up with my own as a PS action, which is pretty good. (Optional) To give a better "pushed grainy color reversal film" look, increase saturation (even till unrealistic ... go look at E1600 +2/+3) and smooth image (texture -50 or thereabouts)Desaturate photo "-50" to avoid gamut problemsConvert to CMYKFor each channel:a) Camera Raw Filter: Grain Amount 100, Grain Size whatever (e.g. 30), Grain Roughness 100b) gaussian blur (to match grain size above)Convert back to RGBTurn saturation back up "+50" Et, voila! Now, obviously there is no reason this can't be done in Lightroom itself, as basically all of this is built in (no explicit gaussian blur but it's used everywhere internally). Here's an example up close and magnified. This is a nice clean digital photo run through the above action:  For comparison, here is a scan of +2 pushed cross-processed expired E100-something:  If looking for knobs to tweak, you could play somewhat with the "dye" colors (variations from pure CMY(K)), adjust size/roughness of the grain, blend with the original, etc. etc. Messing with the dye colors involves complicated color math that I don't want to get near in Photoshop scripting, but someone working on a pro software product would have no problem coming up with the appropriate profiles. I'm sure there are plugins and whatnot out there that do a real color grain simulation, but: PS and LR don'tDespite its excellent B/W grain simulation, Nik doesn'tIn the world of video/cinema (which I don't know much about), DaVinci Resolve doesn't Please, Adobe, make it so! See also this brief post:https://community.adobe.com/t5/lightroom-classic-ideas/p-polychromatic-film-grain-and-halation/idi-p/12433537

EdtheSeaParticipant

Add a "VR Camera in Sphere Position" to the available VR effectsOpen for Voting

While VR Rotate Sphere is extremely useful, another type of mapping would be able to create even more interesting 360 videos. I refer to 360 videos from devices such as the Insta360 X series. I am seeing more and more of these out there.That would be something like “VR Move Camera inside Sphere” effect (needs a better name!) where it would be like a rotate sphere in that there is a camera “looking” at the inside of a sphere mapped with the 360 equirectangular image/frame. But the enhancement would be to allow XYZ positioning and animation to the camera in addition to rotation. This would allow a “zoom” into objects that might be too far away to see well. I understand the resolution limits, but a modest 1.5 zoom would make for very interesting videos.I also would have a IPD setting as well to compensate for the move.Currently there is no way to do this in Pro. FOV or Motion effect changes breaks the 360 video seams. The only way to do it currently is to use animation software like Blender to map the frame to the inside of the sphere, and then animated the camera. The is very labor intensive, and my idea would be far simpler for an editor to use. From Gemini:is it possible to have the 360 video on the inner side of the sphere, then move the camera closer to the sphere for a zoom effect? would that break the 360 seams? Yes, this approach works, and no, it will not break the 360 seams—as long as the camera moves purely inside the sphere and the equirectangular footage is mapped correctly to the interior faces.Why the Seams Stay Intact Spherical Geometry: The seam of a 360 video exists only where the left and right edges of the flat equirectangular image meet around the back of the sphere (360∘ wrap). Because the texture is wrapped seamlessly around a single continuous, inverted UV-mapped sphere, moving a camera around inside that sphere does not create or reveal any new edges. Camera Translation vs. Lens Zoom: Standard FOV (Field of View) zoom or flat 2D scaling can distort perspective or stretch pixels non-uniformly. However, physically moving the 360 camera off-center toward a target on the inner wall maintains the natural spherical perspective of the projected image. Important Technical Caveats Perspective & Parallax Limits: A 360 video is a single monoscopic or stereoscopic capture from a fixed central point. Moving the virtual camera closer to the wall simulates a "dolly in," but it cannot generate real parallax (i.e., you won't see behind objects that were obscured in the original video). Resolution Pixelation: As the camera moves closer to any specific section of the sphere wall, that area will occupy more screen real estate. The video will start to pixelate or blur depending on the original source resolution (e.g., 5.7K or 8K). Stereoscopic 3D Considerations: If you are working with 3D VR footage (3D 360), moving the camera off-center without updating the eye-separation/interpupillary distance (IPD) can create minor depth distortion or eye strain for VR headset viewers. Implementation Setup (e.g., in Blender or 3D Software) Invert Normals: Assign your equirectangular 360∘ video texture to a UV Sphere, and flip/invert the faces so the normals point inward toward the origin. Set Texture Mapping: Ensure the UV mapping uses standard Equirectangular (Spherical) projection. Animate Camera: Place your perspective camera at the center of the sphere (0,0,0) and keyframe its position vector toward your subject on the inner surface.     

Fotomaker01RAKnown Participant

Replace the "Exposure" Adjustment Layer (Ps Beta) with "Brightness/Contrast"Open for Voting

In the current release of Ps Beta “Exposure” appears duplicated - as a standalone adjustment layer and as part of the newer beta “Light” adjustment layer (that brings Camera Raw Filter adjustments into Ps layers).Brightness/Contrast and Exposure don’t accomplish the same things in an image. Exposure: Multiplies pixel values. It scales the highlights dramatically and can easily blow out bright areas if pushed too far. Brightness: Shifts midtones and compresses the highlights/shadows. It protects absolute whites and blacks from clipping, making it much safer for quick adjustments. I would like to see the former “Brightness/Contrast” adjustment layer be restored to replace the current standalone (and duplicative) “Exposure” adjustment layer (in Ps beta).There’s no need for redundancy of “Exposure” since “Brightness” offers more control in certain types of light. And, it slows our workflow and is klunky to have to use the hamburger menu to restore an often-used feature by toggling to a “pre-2026” adjustment option.If the newer “Light” adjustment layer already contains “Exposure” (+ other ACR related settings) then, IMO, “Exposure” as a standalone in the category with Levels & Curves, further down in the adjustment layers list, can be removed and restored to a “Brightness/Contrast” adjustment layer. That would be a very welcome fix.Thanks!

tan349673281t5kParticipant

Support Nested Effects in the Layer StackOpen for Voting

I would like to request support for nested / hierarchical Effects in Substance 3D Painter's Layer Stack.The goal is not to introduce a full Designer-style Node Graph, but to allow the existing Effects used in Layers and Masks — including Filters, Generators, and other effect types — to be organized hierarchically.A good reference for this workflow is the nested Filter system in World Creator 2026, where an effect can contain other effects and multiple levels of hierarchy can be created.The main reason for this request is that Painter's current linear Effect workflow becomes increasingly difficult to manage as Mask and material logic becomes more complex.The Core Problem: Painter's Effect Stack Is Fundamentally LinearPainter already provides most of the building blocks needed to create sophisticated masks and material effects.For example:Curvature Ambient Occlusion Position Thickness Grunge Noise Generators Levels Histogram Scan Blur Warp etc.The problem is not a lack of available Effects.The problem is that these Effects are primarily organized as a linear sequence: Fill Layer├── Curvature├── Metal Edge Wear├── Dripping Rust├── Levels├── Warp└── UV Border DistanceA linear stack works very well when the desired operation is simply: A → B → C → DHowever, real-world material authoring frequently requires branching and nested operations.For example: A × (B + C)or: Blur( A × ( B + C ))These are not particularly complicated operations mathematically, but they are difficult to express naturally using a purely linear Effect stack.The issue is therefore not the complexity of the individual operations. It is the inability to conveniently represent their relationships.The Current WorkaroundCurrently, when a more complex relationship is required, the artist has to construct additional Layers, Masks, Groups, and intermediate results to simulate the required hierarchy.For example, instead of directly representing: Multiply├── A└── Add ├── B └── Cthe artist may have to construct several intermediate Masks/Layers to calculate B + C first, then feed that result into another Mask operation, and then continue processing the result.As the logic becomes more complicated, this can lead to structures such as: Layer└── Mask ├── Generator ├── Filter ├── Group │ ├── Mask │ │ ├── Generator │ │ └── Filter │ └── Filter ├── another Mask └── additional FiltersThe Layer Stack is then no longer primarily representing the material itself.It is being used to simulate a processing tree that Painter cannot directly represent.The Cost of the Current ApproachThis workaround has several significant costs.1. Unnecessary complexityA relatively simple mathematical relationship can require many Layers, Masks, and intermediate operations.The resulting graph of dependencies becomes much larger than the actual logic being performed.2. Poor readabilityWhen returning to a material weeks or months later, it can be difficult to understand why a particular intermediate Mask exists or how several nested Masks contribute to the final result.The artist has to mentally reconstruct the processing logic from the Layer Stack.3. Difficult iterationChanging one part of a complex operation can require navigating through several levels of Layers and Masks.This makes experimentation slower, especially when the artist is trying different combinations of existing Effects.4. More duplicationThe same intermediate processing may need to be recreated in multiple places because the current structure does not provide a convenient way to organize complex operations hierarchically.5. The Layer Stack becomes an implementation detailThis is perhaps the biggest problem.The artist is forced to think about:"How can I represent this operation using Painter's Layer/Mask structure?"instead of simply thinking about:"What operation do I want to perform on this material?"That distinction becomes increasingly important as a material becomes more sophisticated.Why More Generators Do Not Solve This ProblemAdding more Generators or Filters does not fundamentally address this issue.Different materials frequently require completely different combinations of the same basic operations.For example, a wood asset might require: Levels└── Multiply ├── Curvature └── Directional Noisewhile a copper lamp might require: Levels└── Add ├── Concavity └── Grungeand a stone asset might require: Blur└── Multiply ├── AO └── SlopeThese are asset-specific compositions.It is not practical to solve this problem by creating a new Generator for every possible combination.This is analogous to software development:A library provides reusable functions. The application decides how those functions are combined for a particular task.Substance 3D Designer is excellent for creating reusable procedural building blocks.But Painter needs a better way for the artist to combine those existing building blocks freely at the asset level.Proposed Solution: Nested EffectsAllow Effects to contain other Effects.For example: Fill Layer└── Levels └── Multiply ├── Curvature └── Add ├── AO └── GrungeAnother example: Fill Layer└── Blur └── Multiply ├── Metal Edge Wear └── Levels └── Dripping RustThe important point is that the hierarchy should apply to the broader Effect system, rather than only to Filters.It should ideally support combinations of:Filters Generators Other existing Layer/Mask EffectsThe exact terminology or UI implementation can of course be determined by Adobe.Why a Hierarchical Tree Is EnoughI am not requesting a full Substance 3D Designer-style Node Graph.A recursive hierarchy would already solve a large portion of the problem.The conceptual difference is simply:Current Effect AEffect BEffect CEffect DProposed Effect A└── Effect B ├── Effect C └── Effect DThis provides a way to express nested relationships without requiring Painter to introduce a completely different node-based authoring paradigm.The existing Painter workflow could remain intact:Layers → Masks → EffectsThe only significant addition would be:Effects can contain Effects.Reference: World Creator 2026World Creator 2026 provides a useful example of this concept.Its Filters can be organized into multiple levels of hierarchy, for example: Filters└── General - Border Blend ├── Distribution ├── Effects └── Occlusion ├── Effects └── WaveThis is the kind of hierarchy I am referring to.I am not suggesting that Painter copy World Creator's entire procedural system.The useful part is specifically the ability to organize processing operations into a recursive hierarchy.Why This Would Be a Relatively Focused FeatureI believe this could be introduced without fundamentally changing what Painter is.Painter would not need to become Substance 3D Designer.It would not require every asset to become a Node Graph.Existing Filters and Generators would remain useful exactly as they are.The primary change would be allowing the existing Effect container/stack to support a parent-child relationship.Conceptually: Current:Layer └── Effect Stack ├── Effect ├── Effect └── EffectProposed:Layer └── Effect Tree ├── Effect │ └── Effect │ ├── Effect │ └── Effect └── EffectThis would preserve backward compatibility with the current linear workflow while providing a much more powerful structure when needed.The ResultThe most important improvement would be that the structure of the Painter project could finally represent the structure of the material operation itself.Instead of having to translate: A × (B + C)into a complicated collection of Layers and Masks, the artist could simply construct: Multiply├── A└── Add ├── B └── CThe parentheses in the mathematical expression become the hierarchy of the Effect tree.This would make complex material authoring:Easier to construct Easier to understand Easier to debug Easier to modify Less dependent on intermediate Layers/Masks Less repetitive More scalable for complex assetsMost importantly, it would allow artists to spend less time working around the limitations of the Layer Stack and more time designing the actual material.The request is not for more Effects. Painter already has many excellent building blocks. The request is for the ability to freely compose those building blocks into hierarchical, asset-specific operations.