标签：#imageprocessing

`California's AB 723 has been in force since January 1, 2026. It amends Business & Professions Code § 10140.8 and it applies to any real estate listing image that has been digitally altered. Virtual staging is the obvious case, but the definition is wider than that. The rule has two parts: A statement that the image has been altered, "reasonably conspicuous" and placed on or adjacent to the image. A link to a publicly accessible URL, or a QR code, that includes and clearly identifies the original, unaltered image. Everyone builds the first part. It is a text label on a photo, an afternoon of work. The second part is a small piece of infrastructure: a permanent public URL, per image, that outlives the tab the agent had open when they exported. I build a virtual staging product, so I had to ship both. This is how the second part is put together, and the one thing I got wrong. What counts as altered Worth getting right before writing any code, because it decides which of your features need the label and which do not. Subsection (b)(2) carves out ordinary photo editing. Covered: Adding furniture, rugs, art or decor Removing furniture, clutter or personal items Changing paint, flooring or wall finishes Sky replacement and day to dusk Greening or reshaping lawns and landscaping Anything that changes the facade or the property itself Not covered: Exposure, lighting, white balance, color correction Sharpening Straightening, cropping, angle In the codebase that line is a set, and the two omissions are deliberate: ts export const TOOLS_ALTERING_LISTING_IMAGES = new Set([ "virtual-staging", "sky-replacement", "day-to-dusk", "grass-greener", "declutter", "object-remover", ]); image-enhancer is out because exposure and white balance are precisely what the statute excludes. A floor plan generator is out because a diagram is not an altered photograph. Attaching a legal claim to a feature the law does not cover is not a harmless extra: it is the fastest way to make the rest of your

ImgProxy is an open-source image-processing server — resize, convert, and transform images on the fly via URL parameters, ideal as a caching layer in front of a CDN or web app. This guide builds ImgProxy from source on Ubuntu, runs it as a systemd service behind Nginx with TLS, walks through its URL processing options, and secures it with signed URLs. Prerequisites: an Ubuntu server, a domain A record (e.g. imgproxy.example.com ), non-root sudo user. Install ImgProxy ImgProxy uses libvips for image processing; this builds it from source with Go. $ sudo add-apt-repository ppa:dhor/myway $ sudo apt update $ sudo apt install libvips-dev -y $ sudo snap install --classic --channel = latest/stable go $ git clone https://github.com/imgproxy/imgproxy.git $ cd imgproxy $ sudo CGO_LDFLAGS_ALLOW = "-s|-w" go build -o /usr/local/bin/imgproxy Create the environment config: $ sudo touch /usr/local/bin/imgproxy.env $ sudo nano /usr/local/bin/imgproxy.env IMGPROXY_BIND = :8080 IMGPROXY_NETWORK = tcp IMGPROXY_READ_TIMEOUT = 10 IMGPROXY_WRITE_TIMEOUT = 10 IMGPROXY_WORKERS = 2 IMGPROXY_REQUESTS_QUEUE_SIZE = 0 IMGPROXY_QUALITY = 100 IMGPROXY_PREFERRED_FORMATS = webp,jpeg,png,gif,avif IMGPROXY_LOG_FORMAT = "pretty" IMGPROXY_LOG_LEVEL = "INFO" IMGPROXY_WATERMARK_URL = https://example.com/watermark.png IMGPROXY_WATERMARK_OPACITY = 1 Key settings: IMGPROXY_WORKERS should be ~2× your vCPU count; IMGPROXY_REQUESTS_QUEUE_SIZE=0 means unlimited queueing; IMGPROXY_WATERMARK_URL points at whatever image you want overlaid when watermarking is enabled. Point ImgProxy at the config and test: $ export IMGPROXY_ENV_LOCAL_FILE_PATH = /usr/local/bin/imgproxy.env $ cd $ imgproxy WARNING [2024-05-28T00:40:42Z] No keys defined, so signature checking is disabled WARNING [2024-05-28T00:40:42Z] No salts defined, so signature checking is disabled INFO [2024-05-28T00:40:42Z] Starting server at :8080 Stop it with Ctrl+C once verified, then set it up as a service. Run ImgProxy as a systemd Service $ sudo useradd

Disclosure: I work on Passlens, a browser-first passport and ID photo maker. This post is about the product decisions behind that workflow, not a neutral review of every tool in the space. A passport photo looks simple until you try to make one that an upload form will actually accept. It is a headshot, yes, but it is also a small chain of constraints: physical size, pixel size, background, head position, print scale, and whatever the destination country's portal decides to reject that week. That is why generic photo editors feel slightly wrong for this job. They can crop. They can resize. They can export. The hard part is not any one of those actions. The hard part is keeping all of them tied to the document rule the user picked. The unit problem For developers, document photos are awkward because two units matter at the same time. A user may need a 2x2 inch passport photo. A visa portal may ask for 600x600 pixels. A print sheet may need 35x45 mm photos at 300 DPI. These are not the same request, but people often treat them as if they are. If the app only thinks in pixels, the print can come out the wrong physical size. If it only thinks in millimetres or inches, the digital upload can be rejected for the wrong pixel dimensions. A good workflow has to keep both ideas alive: the document size and the export target. That is the main reason Passlens keeps presets and print layouts as first-class pieces of the workflow instead of treating them as labels on a crop box. The crop is not the output Another small trap: the crop the user sees is not always the final output. For a digital upload, the crop usually becomes one image file. For printing, the same crop may become several photos arranged on 4x6, A4, or Letter paper with spacing, margins, and optional cut marks. If that print sheet is scaled by the browser or printer dialog, the whole thing is wrong. So the editor needs to separate three things: the face and shoulder crop the finished document-photo size the print s