Images appended from disk do not have data #73761

Closed
opened 2020-02-12 16:24:38 +01:00 by Christopher Gearhart · 21 comments

System Information
Operating system: Broken on Mac OS and Windows 10
Graphics card: --likely irrelevant--

Blender Version
Broken: 2.83 (sub 9), branch: master, commit date: 2020-03-14 18:05, hash: a210b8297f
Worked: 2.81a

Short description of error

Appended images from disk do not have data, and it seems the only way to load the data is to open it in the 'Image'/'UV' editor. This is not a solution, however, because I need to append an image and then access the image data via a script running on a background instance of Blender.

I believe the image should automatically have data when appended, but if not, there should at least be some way to load the image data via Python API.

Exact steps for others to reproduce the error

  1. From default startup, open any image into Blender (e.g. via the UV Editing workspace)
  2. Run the following script:
import bpy
import tempfile
import os

data_blocks = set([bpy.data.images[<image_name>]])

path = os.path.join(os.path.expanduser("~"), "Desktop", "texture_issue_lib.blend")
print(path)

bpy.data.libraries.write(path, data_blocks, fake_user=True)
  1. From the 'Layout' editor, Open a new default startup file, and append the image written to the library file at the path printed by the script above.
  2. Without opening the image editor/uv editor, switch to the 'Scripting' workspace, and type the following into the Console:
bpy.data.images[<image_name>].has_data
  1. Assuming your results match mine, this will print False, and the im.reload() and im.update() image utility functions will not change this.
**System Information** Operating system: Broken on Mac OS and Windows 10 Graphics card: --likely irrelevant-- **Blender Version** Broken: 2.83 (sub 9), branch: master, commit date: 2020-03-14 18:05, hash: a210b8297f5a Worked: 2.81a **Short description of error** Appended images from disk do not have data, and it seems the only way to load the data is to open it in the 'Image'/'UV' editor. This is not a solution, however, because I need to append an image and then access the image data via a script running on a background instance of Blender. I believe the image should automatically have data when appended, but if not, there should at least be some way to load the image data via Python API. **Exact steps for others to reproduce the error** 1. From default startup, open any image into Blender (e.g. via the UV Editing workspace) 2. Run the following script: ``` import bpy import tempfile import os data_blocks = set([bpy.data.images[<image_name>]]) path = os.path.join(os.path.expanduser("~"), "Desktop", "texture_issue_lib.blend") print(path) bpy.data.libraries.write(path, data_blocks, fake_user=True) ``` 3. ***From the 'Layout' editor***, Open a new default startup file, and append the image written to the library file at the path printed by the script above. 4. ***Without opening the image editor/uv editor***, switch to the 'Scripting' workspace, and type the following into the Console: ``` bpy.data.images[<image_name>].has_data ``` 5. Assuming your results match mine, this will print `False`, and the `im.reload()` and `im.update()` image utility functions will not change this.

Added subscriber: @bblanimation

Added subscriber: @bblanimation

#86777 was marked as duplicate of this issue

#86777 was marked as duplicate of this issue

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Tested on Linux, both files are the same size. Maybe it's spesific to windows.

Tested on Linux, both files are the same size. Maybe it's spesific to windows.
Campbell Barton changed title from Writing images to library files in temp directory results in empty data to Writing images to library files in temp directory results in empty data on WIN32 2020-02-13 03:18:12 +01:00

Ah, I have new information.

The problem is not actually on writing the files - the files are the same size for me as well. The problem is in appending the data. If I take the library file from my desktop and copy it into my Temp folder, the image appends without data, but if I place it back on my desktop, the image appends fine with all of its data.

I've also confirmed the same issue is present on MacOS.

Ah, I have new information. The problem is not actually on writing the files - the files are the same size for me as well. The problem is in appending the data. If I take the library file from my desktop and copy it into my Temp folder, the image appends without data, but if I place it back on my desktop, the image appends fine with all of its data. I've also confirmed the same issue is present on MacOS.

Added subscriber: @mano-wii

Added subscriber: @mano-wii

I also cannot reproduce the problem. Am I doing something wrong?
image_bug.gif

Operating system: Windows-10-10.0.18941 64 Bits

I also cannot reproduce the problem. Am I doing something wrong? ![image_bug.gif](https://archive.blender.org/developer/F8341472/image_bug.gif) **Operating system:** Windows-10-10.0.18941 64 Bits

Perhaps it has something to do with the image file I'm using? Here's the image file:

diego-on-my-mind-self-portrait-as-tehuana-frida-kahlo.jpg

Perhaps it has something to do with the image file I'm using? Here's the image file: ![diego-on-my-mind-self-portrait-as-tehuana-frida-kahlo.jpg](https://archive.blender.org/developer/F8341592/diego-on-my-mind-self-portrait-as-tehuana-frida-kahlo.jpg)

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'

Also could not reproduce the problem with the image attached.
This can be a problem when reading the directory (special characters or something).
Which directory is printed in print(path2)?

Also could not reproduce the problem with the image attached. This can be a problem when reading the directory (special characters or something). Which directory is printed in `print(path2)`?

I won't have access to my Windows machine at the moment, but I believe it was something like this:

C:\Users\chris101343\AppData\Local\Temp

I did notice that, for my Mac at least, the problem doesn't seem to happen when run from default startup – only when run using my bare-bones test file. I've attached the file below.

texture_issue.blend

I won't have access to my Windows machine at the moment, but I believe it was something like this: `C:\Users\chris101343\AppData\Local\Temp` I did notice that, for my Mac at least, the problem doesn't seem to happen when run from default startup – only when run using my bare-bones test file. I've attached the file below. [texture_issue.blend](https://archive.blender.org/developer/F8345023/texture_issue.blend)

Changed status from 'Needs User Info' to: 'Needs Triage'

Changed status from 'Needs User Info' to: 'Needs Triage'

I have a bit more information as I continue to investigate:

The problem seems to be that for some reason, my image does not have data. If I type the following into the console:

print(bpy.data.images[<image_name>].has_data)
bpy.data.images[<image_name>].update()
print(bpy.data.images[<image_name>].has_data)

It prints:

False
True

I imagine this has something to do with why the image does not write correctly. Perhaps the image is not properly loaded when opening the blend file?

I have a bit more information as I continue to investigate: The problem seems to be that for some reason, my image does not have data. If I type the following into the console: ``` print(bpy.data.images[<image_name>].has_data) bpy.data.images[<image_name>].update() print(bpy.data.images[<image_name>].has_data) ``` It prints: ``` False True ``` I imagine this has something to do with why the image does not write correctly. Perhaps the image is not properly loaded when opening the blend file?
Christopher Gearhart changed title from Writing images to library files in temp directory results in empty data on WIN32 to Images appended from disk do not have data 2020-03-17 22:41:02 +01:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

I've updated the title and description to reflect the state of this bug in 2.83 – The steps to reproduce the error should be very clear.

I've updated the title and description to reflect the state of this bug in 2.83 – The steps to reproduce the error should be very clear.

Changed status from 'Needs Developer To Reproduce' to: 'Archived'

Changed status from 'Needs Developer To Reproduce' to: 'Archived'
Germano Cavalcante self-assigned this 2020-07-09 16:38:56 +02:00

Trying the script here, has_data also returns False if it is not loaded in an editor.
Seeing the description of has_data, it is said:

"True if the image data is loaded into memory"

So the image was simply not loaded into memory.

I don't see why that would be a bug.

For questions about the python API, you can try: https://blender.stackexchange.com/

Trying the script here, `has_data` also returns `False` if it is not loaded in an editor. Seeing the description of `has_data`, it is said: ``` "True if the image data is loaded into memory" ``` So the image was simply not loaded into memory. I don't see why that would be a bug. For questions about the python API, you can try: https://blender.stackexchange.com/

The issue is not with the has_data property. The issue is that images not yet loaded in memory do not write to disk correctly with bpy.data.libraries.write(), which is a bug. At the very least, an error should be thrown if the image data has not been loaded to memory, rather than writing bad data to a file.

The issue is not with the `has_data` property. The issue is that images not yet loaded in memory do not write to disk correctly with `bpy.data.libraries.write()`, which is a bug. At the very least, an error should be thrown if the image data has not been loaded to memory, rather than writing bad data to a file.

Added subscriber: @brecht

Added subscriber: @brecht

By default, the image datablock is just a reference to an image file on disk. What has_data tells you is if the image pixels are cached in memory, the image file on disk is still where the permanent storage is.

If you want pixels to be written into a .blend file, you need to pack the image.

By default, the image datablock is just a reference to an image file on disk. What `has_data` tells you is if the image pixels are *cached* in memory, the image file on disk is still where the permanent storage is. If you want pixels to be written into a .blend file, you need to pack the image.
Member

Added subscribers: @Andrew_D-1, @lichtwerk

Added subscribers: @Andrew_D-1, @lichtwerk
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
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
6 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#73761
No description provided.