Functions such as os.path.exists(image.filepath) fail when Blender uses relative paths, This seems to be because Blender uses // prefix for relative paths, unlike the more conventional ./.
How can standard Python filesystem functions be used correctly on Blender paths?
The // prefix is Blender specific to denote relative paths used within Blender,
To use Python's filesystem functions you'll have to first expand this using:
bpy.path.abspath, to replace os.path.abspathbpy.path.relpath, to replace os.path.relpatheg:
filepath_full = bpy.path.abspath(image.filepath, library=image.library)
Unlike ./, which simply expands the current-working-directory (os.getcwd()), Blender supports library-linked files. This means the directory of the current data-block could be a different path then the currently open Blend file.
If you are operating data which the script created, You can skip passing the library argument.
filepath_full = bpy.path.abspath(image.filepath)
Note that this isn't specific to images, it works for movie-clip, sounds, sequencer and text blocks too.
bpy.path.abspath() around my StringProperty to always get the full path. Again, thanks!
$\endgroup$
This may be off topic, but if you encounter the following situation, this may help you.
I was automating the creation of blender files which
Took an existing file,
Replaced some textures, moved stuff around, changed sizes of some objects etc.,
SAVED THE BLENDER FILE TO ANOTHER FOLDER.
I couldn't figure out why in the saved file, all textures had relative paths assigned to them, even though in all possible settings in Blender I set relative paths to False, like the setting User Preferences / File / Save & Load / Relative Paths to [ ] (unchecked) and using bpy.context.user_preferences.filepaths.use_relative_paths = False.
All textures still had their paths in the form '//.../.../...' which was not what I wanted AND those paths were relative TO THE LOCATION OF THE ORIGINAL BLENDER FILE and not relative to the newly saved one.
Then it dawned to me, but this is not documented anywhere, that the problem is not where I had expected it, but rather when the new file is being saved. I used the method bpy.ops.wm.save_as_mainfile() and this method, as it turned out, was the reason. It has an optional argument relative_remap WHICH DEFAULTS TO True and means that THE MOMENT you save your new file, all paths get converted to relative (and relative to the location of the currently open file, not to the location where your new file is being saved to). Hope this saves you some time, it took me hours to figure out.
So, you need
bpy.ops.wm.save_as_mainfile(filepath = YourNewFilePath, relative_remap = False)
