image path

[MikeFromMesa]

I have only just started trying to learn PSP scripting, so perhaps this question should be obvious, but it is not, at least to me.

One of the things I wanted to find out about the active image is its original path. I have read through the Corel scripting guide and it refers to the Active Document and the Target Document objects, and I have also found the ReturnImageInfo command. The problem is that none of those actually return the image path if it is a newly opened raw image. The scripting guide clearly states that the Name property will be an empty string if the image has not been saved, and from my testing that means that it will be an empty string if it has not been saved by PSP.

I have not been able to find any way, even in the PSP GUI, to identify the original path of the image, and have begun to think that perhaps it is not available. Yet PSP knows the path as it uses it in the Save command and, if I record a simple script to save the image the path is clearly visible as a string. Unfortunately there is no place I can see in that script where that path is retrieved from some PSP object; it is just given as a string value.

Is there any way to retrieve the original path of an image that is newly opened and not yet saved anywhere by PSP?

[LeviFiction]

App.TargetDocument.Name will return the full path of an image that was opened from the harddrive.

If the image is a brand new image that has never been saved to the harddrive the .Name property will be empty because it literally does not exist on the harddrive so it can't have a path. But an image that you opened from the harddrive will have a path and you'll be able to see it in the .Name property.

[MikeFromMesa]

App.TargetDocument.Name will return the full path of an image that was opened from the harddrive.

If the image is a brand new image that has never been saved to the harddrive the .Name property will be empty because it literally does not exist on the harddrive so it can't have a path. But an image that you opened from the harddrive will have a path and you'll be able to see it in the .Name property.

Then perhaps the way I have my system set up is the problem.

I run Windows as a Parallels VM on my Mac, but I do not think that is the issue. However my Mac has only limited space on the main ssd so I keep my images on an external usb 3 ssd. When I load a new raw image from that ssd and look at App.TargetDocument.Name, it is empty. When I save that image, as a tif for example, on that same usb 3 ssd, I then have a valid value for App.TargetDocument.Name. The exact same thing is true if I open up the Image Information display for that same image. The path is empty if it is a newly opened image from my usb 3 ssd.

Perhaps my issue is that the images are on an external ssd? I will do some testing to see.

[MikeFromMesa]

No. That did not make any difference.

I have now opened a raw image from my external usb3 drive, from my main ssd and from the Windows VM c:\ folder structure and in all 3 cases I have no image path. Here is the output from a simple script that printed off the ActiveDocument.Name, TargetDocument.Name and ImageInfo information. You can see that the path information is blank, and that is true for all 3 cases.

[LeviFiction]

I'm sorry I completely missed the fact that you said RAW, it technically doesn't change my answer but I would have added that RAW files are brand new files in PSP.

When PSP imports a RAW file it uses a conversion tool and the resultant image is in fact just a new image with no path data at all.

I downloaded a raw canon 1dm2 file, opened in in PSP 2018 64-bit, performed the conversion and hit "Save" the save command opened in the last used folder location which just happened to be the same location as the original raw file. When I moved the raw file to my desktop and opened it in PSP and hit save, the default save was still that original download folder. Keep in mind I'm dragging the file in, not using the Open command. If I use the open command then the save command defaults to the last folder where a file was opened.And I'm not sure how to grab this information.

EDIT:

Okay I have a possible solution, though this only works if you use the Open command. If you drag and drop a raw file this won't work.

You need to use the "GetCommandInfo" command with the LastUsed parameter. And you use it on the "FileOpen" command. This will return a long dictionary of key value pairs the represent the parameters used for the command. What you're interested in is the "Folder" key. Here is an example

Code: Select all

    Info = App.Do(Environment,  'GetCommandInfo', {
                'TargetCmd': 'FileOpen',
                'ParamInfo': App.Constants.ParamInfo.LastUsed
                } )
    
    # command parameters are stored in a key consisting of library name and command name
    CmdParam = Info[ 'Library' ] + '\\' + Info['Name']
    Params = Info[CmdParam] # get a simpler dictionary to work with
    print Params['Folder']

This code will print out the folder location of last opened file. You can then use App.TargetDocument.Title to get the name of the file. Of course neither of these will tell you anything about the file extension. But it should work.

We could do a lot better if CameraRawLoader kept a list of file it opened, but it sadly does not.

[MikeFromMesa]

I'm sorry I completely missed the fact that you said RAW, it technically doesn't change my answer but I would have added that RAW files are brand new files in PSP.

When PSP imports a RAW file it uses a conversion tool and the resultant image is in fact just a new image with no path data at all.

I downloaded a raw canon 1dm2 file, opened in in PSP 2018 64-bit, performed the conversion and hit "Save" the save command opened in the last used folder location which just happened to be the same location as the original raw file. When I moved the raw file to my desktop and opened it in PSP and hit save, the default save was still that original download folder. Keep in mind I'm dragging the file in, not using the Open command. If I use the open command then the save command defaults to the last folder where a file was opened.And I'm not sure how to grab this information.

EDIT:

Okay I have a possible solution, though this only works if you use the Open command. If you drag and drop a raw file this won't work.

You need to use the "GetCommandInfo" command with the LastUsed parameter. And you use it on the "FileOpen" command. This will return a long dictionary of key value pairs the represent the parameters used for the command. What you're interested in is the "Folder" key. Here is an example

Code: Select all

    Info = App.Do(Environment,  'GetCommandInfo', {
                'TargetCmd': 'FileOpen',
                'ParamInfo': App.Constants.ParamInfo.LastUsed
                } )
    
    # command parameters are stored in a key consisting of library name and command name
    CmdParam = Info[ 'Library' ] + '\\' + Info['Name']
    Params = Info[CmdParam] # get a simpler dictionary to work with
    print Params['Folder']

This code will print out the folder location of last opened file. You can then use App.TargetDocument.Title to get the name of the file. Of course neither of these will tell you anything about the file extension. But it should work.

We could do a lot better if CameraRawLoader kept a list of file it opened, but it sadly does not.

Thank you for all of the information. It helps a lot.

As an aside, it seems odd to me that this information is not available. I did some testing and loaded two raw images, each from a different folder. I then tried to Save the first and, sure enough, it attempted to do so in the second folder that was opened. Apparently the path information for the first image is just not available and it is using the last opened folder. As a retired software engineer/architect I wonder about how the system was designed, but it is what it is, and I will have to live with what is available. One of the things I will look at is whether or not there is a way to automatically run a script when an image is loaded. That would allow me to store the path information and that would allow me to retrieve it at some later time.

By the way, your explanation about creating a new image from a raw image makes perfect sense, even if I wonder why the engineers did not just store the path in the object created for the (new) raw image. And thank you for the suggested work-around. I am going to look into that.

The one good thing is that this all gives me a chance to do some interesting experimentation as I have not had that opportunity since I retired.

[LeviFiction]

Glad you found it useful.

And yes, you can run a script when opening an image. There are three methods that I know of, or think of, and since I've never tested them I have no idea of they are even workable or not.

1) In the Open command at the bottom there should be an option to run a script on the opened image. I'm not sure at what point the script will run, before it opens in CameraRawLab or after.

2) Scriptlets - described in the Scripting for Script authors PDF it lets you drag any image onto the shortcut and have it execute a script of your choice on the opened image. Same issue of order of operations as option 1

3) Create a script to replace the Open command. Record the Open command as a script, remove all parameters so that it always starts with defaults, then set it as a bound script, replacing Open in the menu, on the toolbar, and the shortcut key. So long as nothing else uses "Open" this should work just fine. In that same script you can edit the Image Description filed of ImageInfo to include the path just in case.

You could also just make your script open an image as part of its normal function. But that all depends on what it is you're planning to do with it.

[MikeFromMesa]

3) Create a script to replace the Open command. Record the Open command as a script, remove all parameters so that it always starts with defaults, then set it as a bound script, replacing Open in the menu, on the toolbar, and the shortcut key. So long as nothing else uses "Open" this should work just fine. In that same script you can edit the Image Description filed of ImageInfo to include the path just in case.

All of your suggestions seem like good ideas, but I was particularly struck by the last one, and I think I will look into that. My current script handles both raw and non-raw, but I would prefer to actually have the raw path than have to work with a temporary location.

The one problem I seem to have is that the icons that PSP makes available for binding to scripts are all somewhat similar and if I bind more than 2 or 3 scripts I will never remember which is which. I will have to check to see if there are context menus that can be attached so I can tell them apart.

[MikeFromMesa]

PSP is relatively new to me as I usually work on a Mac and only installed it a couple of weeks ago under a Parallels Windows VM. Because of that I am almost always finding something new or unexpected when I work with PSP and this morning was no exception.

I had completed my version of the script to call an external editor from PSP (a general version of the ViewPoint stuff) and included functionality for both raw (no file path) and non-raw (existing file path) information, and was generally happy with how it worked and was going to start working on a small improvement on it when I found something unexpected.

I do not really see any reason to use Camera Raw Lab as I have seen little in that dialog box that I can not accomplish directly in PSP, so I turned it off for raw images. I then loaded a raw image and noticed something very surprising. The Image Information dialog box contained the complete path for the raw image. That same information was blank when I used Camera Raw Lab, but not when I did not use it. I then ran my external editor script and it ran properly, using the existing path information. In other words, all of the functionality built into my script for a blank file path seems to be unnecessary if I just do not use CRL.

You probably already knew this, but it was news to me, and since I do not feel any general need for CRL I will just leave it off. If there is some good reason for using it I am unaware of what that might be.

That certainly simplifies my script coding.

[LeviFiction]

Nope, did not know that at all. xD

And the only reason to use the Camea Raw Lab is if the resultant image that PSP reads doesn't look right without doing RAW level things. Of course if all of the RAW editing is being done in ViewPoint then no, there is no need for PSP to be doing any of it.

[JoeB]

Nope, did not know that at all. xD

And the only reason to use the Camea Raw Lab is if the resultant image that PSP reads doesn't look right without doing RAW level things. Of course if all of the RAW editing is being done in ViewPoint then no, there is no need for PSP to be doing any of it.

I'm not Mike but I think (and stand to be corrected) that he just meant that he had modified the Viewpoint script (which is a modified JSJ script) to run Camera Raw and now sees no need to use it because he can do that editing in PSP. Viewpoint only has one function, and that is to modify perspective issues with images. It does it extremely well and certainly better than PSP's tool. The biggest advantage I've seen so far is that you can change the verticals and horizons in a way that allows you to keep more of the image after cropping. I expect I'll post - in a new thread - a before/after of a test I did in Viewpoint to see if anyone can achieve the same result with PSP's perspective correction tool.

[MikeFromMesa]

I'm not Mike but I think (and stand to be corrected) that he just meant that he had modified the Viewpoint script (which is a modified JSJ script) to run Camera Raw and now sees no need to use it because he can do that editing in PSP. Viewpoint only has one function, and that is to modify perspective issues with images. It does it extremely well and certainly better than PSP's tool. The biggest advantage I've seen so far is that you can change the verticals and horizons in a way that allows you to keep more of the image after cropping. I expect I'll post - in a new thread - a before/after of a test I did in Viewpoint to see if anyone can achieve the same result with PSP's perspective correction tool.

Yes. You are correct. I found I did not need to do any raw adjustments in Camera Raw Lab because I found I can do them just as easily in PSP itself. I have not seen any CRL adjustments that I can not do better using the layers adjustments, so I just stopped using it. One additional side benefit is that if I do not call CRL the path information is available in PSP for both raw and non-raw images.

As you said, ViewPoint only adjusts perspective and lens distortion, and not anything else. I do all of the other processing in either my workflow tool or PSP, or one of the other plugins. The test script allows me to call any external editor, not just ViewPoint, so it is generally very helpful.

[JoeB]

As you said, ViewPoint only adjusts perspective and lens distortion, and not anything else. I do all of the other processing in either my workflow tool or PSP, or one of the other plugins. The test script allows me to call any external editor, not just ViewPoint, so it is generally very helpful.

I'm glad I ran across that script some time ago because it's absolutely great at being able to call external editors (including standalone plugins) from either the 32bit or 64bit versions of PSP. I'm presently checking out the Windows versions of Luminar and Aurora HDR which were finally just released (they have only been Mac programs in the past) and have them bound to scripts to use within PSP. It's great to be able to start in - and return to - PSP.

Luminar, with all of its presets (and more downloadable free) plus many slider tweaks for them looks as if it could be a replacement for several programs like the Nik Collection, Topaz, etc. all in one program. It doesn't have all of the Mac options yet but they're expected within the next few months.

[MikeFromMesa]

I'm glad I ran across that script some time ago because it's absolutely great at being able to call external editors (including standalone plugins) from either the 32bit or 64bit versions of PSP. I'm presently checking out the Windows versions of Luminar and Aurora HDR which were finally just released (they have only been Mac programs in the past) and have them bound to scripts to use within PSP. It's great to be able to start in - and return to - PSP.

Luminar, with all of its presets (and more downloadable free) plus many slider tweaks for them looks as if it could be a replacement for several programs like the Nik Collection, Topaz, etc. all in one program. It doesn't have all of the Mac options yet but they're expected within the next few months.

Since I work mainly on the Mac I have the Mac versions of both of those products, although they are last year's versions, not the current ones. I suppose my license would allow me to download the Windows version as well as the Mac, but I do not see how it would be easy to use Aurora HDR with PSP. The linkage to the HDR software is not the issue, but I am not sure how you can select multiple image files within PSP to send to Aurora. Of course I am only now learning PSP so it may be that there is some way to select multiple images at the same time. Just shows how much there is for me to learn.

Luminar, on the other hand, is a nice piece of software and should work well with PSP. And, as you mentioned, the ability to script to fully in PSP is a welcome addition. It appears that pretty much anything I can do in python I can do in PSP scripts, so I have a lot of experimentation in front of me.

Of course I am also new to python, but one programming language is rarely very different from another and it is only a question of learning the new syntax. Still, I find it odd that python does its parsing based on white space as that is new to me. On the other hand I get to experiment with python at the same time I am experimenting with PSP scripting so I am sort of solving two problems at the same time.

[JoeB]

Since I work mainly on the Mac I have the Mac versions of both of those products, although they are last year's versions, not the current ones. I suppose my license would allow me to download the Windows version as well as the Mac, but I do not see how it would be easy to use Aurora HDR with PSP. The linkage to the HDR software is not the issue, but I am not sure how you can select multiple image files within PSP to send to Aurora

You are, of course, correct. I have actually only tried Aurora with single images (tone mapping) because I don't have any bracketed images so I never really considered that it's best used for brackets. And given I don't usually do bracketing, only tone mapping on a single image, I can achieve the same effects just with Luminar.

You could, if you want to spend the time, try opening Aurora with a script using a single image, uncheck the Tone Mapping option at left and hit the Create HDR button. When the image opens in Aurora you could then open any 3 of your bracketed images and you'll get them in the workspace and hit Create HDR again and see if that actually uses just your bracketed images and does so properly. The only edit you'd have to do with the script is to have it return the finished image to PSP as a new image rather than as a layer on the existing image. Just a thought.

Oh! And if you did try that, when you save you'd have to do Save As, use .tiff as the format (at least that's the format I use in the script to do lossless saves), browse to your Documents file, click on the copy of the original image that was saved as Aurora_temp.tiff (or whatever name you chose in the script to use) so that the processed image could overwrite the existing temp image and save it then close Aurora. Otherwise Aurora will try to save the file in whatever format it was originally (like .jpeg) and in the same folder from which you opened the files.