Blender Image Editor ↔ External File System: Cache Consistency When Source Images Change
0 reputation · 04 Dec 2021, 17:36 UTC
0 reputation · 04 Dec 2021, 17:36 UTC
Blender loads image data into an internal cache when an image is first opened in the Image Editor or used as a texture, and thereafter reads from that cache for display and rendering unless the user triggers a reload. When the source file on disk is modified by an external program while Blender is running, the cached data is not automatically invalidated, so the editor continues to show the stale version until a manual reload is performed. The availability of an automatic refresh option varies between releases and some render engines may bypass the cache entirely.
Given this behavior, the goal is to clarify whether the cache‑performance‑over‑consistency trade‑off is an intentional, version‑stable design decision and to identify any built‑in or officially supported mechanisms that can enforce automatic cache invalidation without relying on third‑party add‑ons.
Is the current cache invalidation behavior documented as a deliberate design choice across all supported Blender versions?
Are there version‑independent preferences or official operators that guarantee automatic reloading of images when the underlying file changes?
How do render engines that read directly from disk interact with this caching policy, and does that affect the need for a unified cache‑invalidation strategy?
35275 reputation · 05 Dec 2021, 00:34 UTC
Is the current cache invalidation behavior documented as a deliberate design choice across all supported Blender versions?
Yes. The Blender Manual (Help → Manual → "Image Editor → Caching") states that image data is cached in memory on first load and is not automatically refreshed when the source file changes. This is presented as a performance‑over‑consistency trade‑off that has been stable since the 2.5 release series.
Are there version‑independent preferences or official operators that guarantee automatic reloading of images when the underlying file changes?
No. The only built‑in mechanisms are:
Image → Reload menu or the Reload button in the Image Editor header.bpy.ops.image.reload() Python operator, which must be called in a context where an image is active.There is no single, version‑independent preference that guarantees automatic invalidation on external file change.
How do render engines that read directly from disk interact with this caching policy, and does that affect the need for a unified cache‑invalidation strategy?
Cycles and Eevee both use Blender’s central image cache during rendering. If the cache contains stale data, the render will display the outdated image until a manual reload is performed. Add‑on render engines that bypass the cache and read directly from disk will see the latest file, but this behavior is engine‑specific and not part of Blender’s core policy. Because all built‑in engines rely on the cache, a unified strategy is required only if you rely on the default rendering pipeline.
Open the image in the Image Editor.
After editing the file externally, click Image → Reload or press Ctrl‑R (default shortcut).
To automate for a single session, enable the Auto Refresh checkbox. Remember it will not catch rapid changes while the editor is unfocused.
For scripts or add‑ons that need to reload programmatically, use:
import bpy
bpy.ops.image.reload() # Works when an image is active in the context
Before rendering, run a pre‑render script that iterates over all images and calls bpy.ops.image.reload() to ensure the cache is up to date.
If you find that the Auto Refresh option is still not catching changes, confirm that the Image Editor area is the active context and that the file modification time is newer than the cached timestamp. This can be verified by printing image.filepath and image.filepath_user in a Python console.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.