Thanks. Hope you found a solution to the problem. On Tue, Aug 20, 2019, 2:51 AM Cameron Simpson <c...@cskk.id.au> wrote:
> Please remember to CC the list. > > On 19Aug2019 22:06, Paul St George <em...@paulstgeorge.com> wrote: > >On 19/08/2019 14:16, Cameron Simpson wrote: > [...] > >>There's a remark on that web page I mentioned that suggests that the > >>leading '//' indicates the filename is relative to the Blender model, > >>so the context directory for the '//' is likely > >>/Users/Lion/Desktop/test8. > > > >Yes. That makes sense. The reason I was testing with two images, one > >at /Users/Lion/Desktop/test8/image01.tif and the other at > >/Users/Lion/Desktop/images/image02.tif is that I cannot rely on images > >being in the same folder as the Blender file. > > > >So, let's assume the context directory is /Users/Lion/Desktop/test8 > >and see how we get on below. > [...] > >>realpath needs a UNIX path. Your //image01.tif isn't a UNIX path, it > >>is a special Blender path. First you need to convert it. By replacing > >>'//' with the blend file's directory. Then you can call realpath. If > >>you still need to. > > > >Understood. Now. Thanks! > >> > >>[...snip...] > > > >Did you just [...snip...] yourself? > > Yes. It keeps the surrounding context manageable. In this way you know > to which text I am referring, without having to wade through paragraphs > to guess what may be relevant. > > >> from os.path import dirname > >> > >> # Get this from somewhere just hardwiring it for the example. > >> # Maybe from your 'n' object below? > >> blend_file = '/Users/Lion/Desktop/test8/tifftest8.blend' > >Is this setting a relative path? > >> > >> blender_image_file = n.image.filename > >> > >> unix_image_file = unblenderise(blender_image_file, > dirname(blend_file)) > >> > >>Now you have a UNIX path. If blend_file is an absolute path, > >>unix_image_path will also be an absolute path. But if blend_file is > >>a relative path (eg you opened up "tifftest8.blend") unix_image_path > >>will be a relative path. > > > >Does unix_image_path = unix_image_file? > > Yeah, sorry, my mistake. > > >Two possibilities here. > >blend_file (and so unix_image_file) is an absolute path OR blend_file > >(and so unix_image_file) is a relative path. > > > >I just want to check my understanding. If I supply the path to > >blend_file then it is absolute, and if I ask Python to generate the > >path to blend_file from within Blender it is relative. Have I got it? > > Not quite. What seems to be the situation is: > > You've got some object from Blender called "n.image", which has a > ".file" attribute which is a Blender reference to the image file of the > form "//image01.tif". > > I presume that Blender has enough state inside "n" or "n.image" to > locate this in the real filesystem; maybe it has some link to the > Blender model of your blend file, and thus knows the path to the blend > file and since //image01.tif is a reference relative to the blend file, > it can construct the UNIX path to the file. > > You want to know the UNIX pathname to the image file (maybe you want to > pass it to some unrelated application to view the file or something). > > So you need to do what Blender would do if it needs a UNIX path (eg to > open the file). > > The formula for that is dirname(path_to_blendfile) with n.image.file[2:] > appended to it. So that's what we do with unblenderise(): if the > filename is a "Blender relative name", rip off the "//" and prepend the > blend file directory path. That gets you a UNIX path which you can hand > to any function expecting a normal operating system pathname. > > Whether that is an absolute path or a relative path is entirely "does > the resulting path start with a '/'"? > > An absolute path starts with a slash and is relative to the root of the > filesystem. You can use such a path regardless of what your current > working directory is, because it doesn't use the working directory. > > A relative path doesn't start with a slash and is relative to the > current working directory. It only works if you're in the right working > directory. > > _Because_ a relative path depends on the _your_ working directory, > usually we pass around absolute paths if we need to tell something else > about a file, because that will work regardless if what _their_ working > directory may be. > > So, you may well want to turn a relative path into an absolute path... > > >If I decided not to supply the path and so ended up with a relative > >UNIX path, I could now use realpath or abspath to find the absolute > >path. Have I still got it? > > This is correct. > > Abspath may even call realpath to do its work, unsure. > > >It works very well. So thank you! I tested it with a Blend file that > >had two images, one in the same folder as the Blend file and the other > >was in a folder on the Desktop called 'images'. > > > >The initial results were: > >Plane uses image01.tif saved at //image01.tif which is at > >/Users/Lion/Desktop/test8/image01.tif > >Plane uses image02.tif saved at //../images/image02.tif which is at > >/Users/Lion/Desktop/test8/../images/image02.tif > >BUT as you say, this was easily sorted by using os.path.realpath or > >os.path.abspath. Both worked equally well. > > Yep. Abspath does some things in a purely lexical way: it resolves '.' > and '..' components in the path even if they don't exist. For example it > resolves 'a/b/c/d/../../../../foo' for me even though here 'a/b/c/d' > doesn't exist: it see the '.. and strips off the preceeding component, > repeatedly. So it starts with 'foo' after that pahse and prepends the > working directory path. > > The system realpath is not documented to work if some of the path is > fictitious, but the Python realpath seems to work even then, maybe it > falls back to abspath or something. > > Abspath takes a relative path and returns you an absolute path with the > '.' and '..' components stripped out. > > Realpath follows symlinks and stuff and returns you the direct absolute > path _after_ all that - one that doesn't traverse symlinks. > > For your purposes the results are equally functional. > > >Plane uses image01.tif saved at //image01.tif which is at > >/Users/Lion/Desktop/test8/image01.tif > >Plane uses image02.tif saved at //../images/image02.tif which is at > >/Users/Lion/Desktop/images/image02.tif > > > >So, everything now works. Thank you again. I am just a little unclear > >on the absolute and relative, hence my questions. > > Hope the above xaplinations help. > > Cheers, > Cameron Simpson <c...@cskk.id.au> > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list