标签：#background

Short answer: use automated background removal for volume, then reserve manual crops for images where a wrong edge costs more than the bandwidth and review time. The useful design is a queue with a confidence gate, not a permanent argument over which tool is “best.” How Should Catalog Teams Balance Background Removal and Manual Crop? Catalog isolation sounds like a visual task. In a SaaS catalog, it is a data pipeline. A seller uploads a product photo, the service produces an isolated asset, and every downstream surface expects the subject to stay inside a predictable box. Quality and bandwidth pull in opposite directions: a high-resolution source preserves fine edges but costs more to move and process; an aggressive resize is quick but can erase the exact detail the mask needs. The decision therefore belongs in a policy that engineering, catalog operations, and support can inspect. Give that policy named outcomes such as auto , manual , and needs_source ; attach the crop rectangle and confidence to each result; and retain enough input metadata to reproduce the decision. Without those records, a quality complaint becomes a debate over screenshots. With them, the team can compare the received file, preview dimensions, mask, final derivative, and policy version in order. Start with an explicit decision table. It gives support and operations one shared vocabulary when an image lands in the review queue. Input or business signal Default path Why Reconsider when Clean background, centered object, thousands of SKUs Automated removal at a bounded preview size Fast throughput and consistent framing Hair, glass, or transparent parts dominate the silhouette Irregular edges or a high-value hero image Manual crop and edge review A person can preserve meaningful contours The review queue becomes the release bottleneck Uncertain subject or cluttered scene Keep the original and request a better photo Prevents a confident-looking bad cutout The seller can supply a controlled backdr

A small word that changes the rhythm of a job For as long as I have been writing Actions workflows I have been carrying a quiet workaround in my head. Want to warm a cache while the build runs? Append & to the shell command, then squint at logs that arrive out of order and pray the job doesn't exit on you. It worked, sort of. It also meant that anything more interesting than "run one thing, then the next thing" lived as folklore, hidden inside run: blocks. GitHub closed that gap this week. On June 25 the Actions changelog announced that steps inside a job can now run concurrently, marked with a new background keyword and supported by helpers to wait for them and cancel them. Until now, the changelog notes, every step in a workflow ran in sequence, with each step starting only after the previous one completed. That single rule has shaped every workflow I have ever written. It is gone, and the replacement is the kind of feature you don't notice until the day you reach for it and it's there. What the keywords actually do There are four pieces, all of them documented in the announcement. background: true is the entry point. Set it on a step and that step starts running, and the next step starts immediately. It does not block the job. wait and wait-all are the rendezvous. wait pins on one or more named background steps and pauses until they finish. wait-all is the same idea against every background step still in flight. Either way you get back into a linear flow on your terms. cancel is the cleanup. It gracefully terminates a background step when you no longer need it, which is the missing piece if you have ever tried to kill a long-running side process from inside a job and ended up shelling out to kill . parallel is the convenience wrapper. The changelog describes it as taking a group of steps and converting them into background steps with a wait placed after. For the common "fan out, then join" shape, you write one block instead of decorating five steps by hand. Where