Scaling UDIM images via Image.scale() only scales one tile #117539

Closed
opened 2024-01-26 11:32:44 +01:00 by Lewis Toohey · 8 comments

System Information
Operating system: Linux-6.5.0-15-generic-x86_64-with-glibc2.38 64 Bits, X11 UI
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 535.154.05

Blender Version
Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: 9be62e85b727
Worked: (newest version of Blender that worked as expected)

Short description of error
Resizing a UDIM image results in inconsistent image sizes for each tile when saved externally. Only one of the UDIM tiles is saved with the correct size. The others remain at the original size.

Exact steps for others to reproduce the error

  1. Start with a fresh blend file
  2. Go to the Image Editor and create a new image. Name="Untitled". Resolution=1024,1024. Tiled=True.
  3. Add two new tiles (1002, and 1003).
  4. Paint something accross all 3 tiles.
  5. Pack the image (Image->Pack).
  6. Choose Image->Resize. Resize to 512,512.
  7. Choose Image->Save As and save to somewhere in the external file system as a PNG.
  8. Files created will be "Untitled.1001.png", "Untitled.1002.png", "Untitled.1003.png".
  9. Only one of the files will be the correct size (512,512). The other two files will be the original size (1024,1024).

This only affects me because I maintain an addon (SimpleBake) that offers the option to scale the images. As such, this affects my script.

In SimpleBake, instead of choosing Image->Resize, I am executing the equivalent of "bpy.data.images["Untitled"].scale(512,512)". The result is the same. Only one of the UDIM images is saved with the correct size. The other two remain at the original size.

**System Information** Operating system: Linux-6.5.0-15-generic-x86_64-with-glibc2.38 64 Bits, X11 UI Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 535.154.05 **Blender Version** Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: `9be62e85b727` Worked: (newest version of Blender that worked as expected) **Short description of error** Resizing a UDIM image results in inconsistent image sizes for each tile when saved externally. Only one of the UDIM tiles is saved with the correct size. The others remain at the original size. **Exact steps for others to reproduce the error** 1. Start with a fresh blend file 2. Go to the Image Editor and create a new image. Name="Untitled". Resolution=1024,1024. Tiled=True. 3. Add two new tiles (1002, and 1003). 4. Paint something accross all 3 tiles. 5. Pack the image (Image->Pack). 6. Choose Image->Resize. Resize to 512,512. 7. Choose Image->Save As and save to somewhere in the external file system as a PNG. 8. Files created will be "Untitled.1001.png", "Untitled.1002.png", "Untitled.1003.png". 9. Only one of the files will be the correct size (512,512). The other two files will be the original size (1024,1024). This only affects me because I maintain an addon (SimpleBake) that offers the option to scale the images. As such, this affects my script. In SimpleBake, instead of choosing Image->Resize, I am executing the _equivalent of_ "`bpy.data.images["Untitled"].scale(512,512)`". The result is the same. Only one of the UDIM images is saved with the correct size. The other two remain at the original size.
Lewis Toohey added the
Priority
Normal
Type
Report
Status
Needs Triage
labels 2024-01-26 11:32:45 +01:00
Member

All image operators work on the active tile, see 9531eb24b3

So I was thinking you just have to do the following before scaling:

bpy.data.images['Untitled'].tiles.active_index = 1

However, this is still resizing only one.

The operator probably relies on a bit more context we have to prepare (via context overrides), will check the details...

All image operators work on the active tile, see 9531eb24b3172d83660649cc0936c05f66aff79b So I was thinking you just have to do the following before scaling: ```python bpy.data.images['Untitled'].tiles.active_index = 1 ``` However, this is still resizing only one. The operator probably relies on a bit more context we have to prepare (via context overrides), will check the details...
Author

@lichtwerk Thanks! - but yeah I've already tried this. I expected this to work, but it doesn't:

i=0
ts=len(img.tiles)
print(f"Num of tiles {ts}")
while i < ts:
    print(f"Working on tile {i}")
    img.tiles.active_index = i
    img.scale(sbp.outputwidth, sbp.outputheight)
    i+=1

Once again, only a single tile is resized.

@lichtwerk Thanks! - but yeah I've already tried this. I expected this to work, but it doesn't: ``` i=0 ts=len(img.tiles) print(f"Num of tiles {ts}") while i < ts: print(f"Working on tile {i}") img.tiles.active_index = i img.scale(sbp.outputwidth, sbp.outputheight) i+=1 ``` Once again, only a single tile is resized.
Member

Ah, sorry, was misreading the report, so this is not about the operator, but about the function, will check that as well

Ah, sorry, was misreading the report, so this is not about the operator, but about the function, will check that as well
Author

@lichtwerk Amazing, thank you for any help.

@lichtwerk Amazing, thank you for any help.
Blender Bot added
Status
Archived
and removed
Status
Needs Triage
labels 2024-01-26 14:42:31 +01:00
Blender Bot added
Status
Needs Triage
and removed
Status
Archived
labels 2024-01-26 14:42:42 +01:00
Author

Sorry - clicked the close issue button by mistake!

Sorry - clicked the close issue button by mistake!
Member

I assume you could just use the operator (but only if your Addon does this from the Image Editor - or at least have the Image Editor available for context, otherwise overwriting the context is hairy since we need an ImageUser and you cant create one from python).

However, we can also tweak the python API (I mean the function) by changing BKE_image_scale a bit.

Not totally sure (yet) if this might have side-effects, but will check further and create a PR for this.

I assume you could just use the operator (but only if your Addon does this from the Image Editor - or at least have the Image Editor available for context, otherwise overwriting the context is hairy since we need an ImageUser and you cant create one from python). However, we can also tweak the python API (I mean the function) by changing `BKE_image_scale` a bit. Not totally sure (yet) if this might have side-effects, but will check further and create a PR for this.
Philipp Oeser added
Status
Confirmed
Interest
Images & Movies
Module
Python API
and removed
Status
Needs Triage
labels 2024-01-26 15:12:13 +01:00
Philipp Oeser self-assigned this 2024-01-26 15:12:29 +01:00
Author

@lichtwerk - Thank you for your attention on this.

I am not running from the Image Editor, unforutnately.

I have another part of my script that overrides the context to call bpy.ops.image.tile_fill. This doesn't seem to have a function equivilent, so it was my only choice. I could potentially try and copy what I did there to call bpy.ops.image.resize in the same way, but it sounds like you are saying that this wouldn't work.

If the resize function could be patched to respect the UDIM active index that would be amazing. It feels like it should behave in that way.

Many thanks

@lichtwerk - Thank you for your attention on this. I am not running from the Image Editor, unforutnately. I have another part of my script that overrides the context to call `bpy.ops.image.tile_fill`. This doesn't seem to have a function equivilent, so it was my only choice. I could potentially try and copy what I did there to call `bpy.ops.image.resize` in the same way, but it sounds like you are saying that this wouldn't work. If the resize function could be patched to respect the UDIM active index that would be amazing. It feels like it should behave in that way. Many thanks
Philipp Oeser changed title from Scaling UDIM images does not work correctly to Scaling UDIM images via Image.scale() only scales one tile 2024-01-31 09:37:19 +01:00
Blender Bot added
Status
Resolved
and removed
Status
Confirmed
labels 2024-02-01 17:28:51 +01:00
Member

"frame" & "tile_index" arguments to Image.scale() were added

"frame" & "tile_index" arguments to Image.scale() were added
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117539
No description provided.