Jump to content
You must now use your email address to sign in [click for more info] ×

Using Photoshop Plugins


Recommended Posts

Mike

 

Yes, while exploring the Aperture/Topaz environment to see if there was either something that could shed light or provide a "back door" I noted that Fusion Express is an app that runs the Topaz plugins (it is the FE app that is called from Aperture, not the plugins themselves) - which is yet another reason etc etc ... and totally supports your idea of AP producing an external app interface.  The quality of AP shows that they know their way around OS X and photo editing, so this should not be beyond them.  

 

I don't think the problem is that they are not paying attention (@russ.carpenter above) more that they have nothing to say at this time, perhaps there are several options being bench-tested even as I type  :unsure: ?

 

Bill

Retina iMac (4K display, 1TB SSD, 16GB RAM) OS X 10.11.6  Capture One 10.

 

Link to comment
Share on other sites

I don't think the problem is that they are not paying attention (@russ.carpenter above) more that they have nothing to say at this time, perhaps there are several options being bench-tested even as I type  :unsure: ?

Bill,

 

I agree. Now that I understand the problem, as I did not before, I have both more sympathy for the problems the developers face. I would like to think that you are right in that they are looking into this problem to see what solution would be best.

 

I do not know why no one has ever responded, positively or negatively, to my suggestions that they implement an external app interface as that would solve many of the problems. You could use Fusion Express 2 (or photoFXlab) for all of the Topaz plugins and I have had some luck with using photoFXlab (the app, not the plugin) to run other plugins such as Perfectly Clear and Dxo ViewPoint 2. In addition we could use all of the OnOne Suite as well.

 

The thing I keep coming back to is that the developers have done a wonderful job in getting AP to release and, for all of my uses, it is completely stable. I can do everything I need except call all of my plugins, and perhaps they are still working on that. One would like to hope, anyway.

 

Mike

Link to comment
Share on other sites

bill here is the answer from topaz.....

 

The reason for this is that in Aperture, Fusion Express 2 is required, and the memory handling done through Fusion Express 2 complies with the IPC Memory requirements of the App Store. The reason this is different is simply related to the mechanism used to launch external editors vs plugins between Lightroom and Photoshop.

Our plugins cannot be launched directly in Lightroom, as Lightroom requires external editors that can be launched as standalones. This is where Fusion Express 2 comes into play. Given that Fusion Express 2 is able to use IPC more efficiently with Lightroom's configuration, it does not encounter these issues, and does not throw errors when used in Aperture. However, the .plugin format that Photoshop uses implements IPC Memory in a different way that violates the App Store restrictions. This is why many plugin vendors provide downloads from their site directly, rather than as a package on the App Store.

Our earlier products were very CPU intensive, which requires us to use IPC memory in a certain way. Apple does not like this approach, though there are workarounds.

....so now everything seems clear so far.

 

 

Link to comment
Share on other sites

Thanks once again csp.  

 

I think I get it ...  What they are saying is:  AP is set up to manage plugins by mimicking Photoshop.  The way that PS implements IPC memory violates MAS conditions, therefore ... 

 

However, if AP called plugins the way that Aperture and LR do (or a similar way) then we could use Fusion Express and the Topaz plugin problem is solved!  (And perhaps there is a similar path to other manufacturers' products).

 

And if AP replaced the tab in Preferences called "Photoshop Plugins" with one called "Plugins" it would enhance the fact that "AP is not Photoshop".

Retina iMac (4K display, 1TB SSD, 16GB RAM) OS X 10.11.6  Capture One 10.

 

Link to comment
Share on other sites

  • Staff

We are still investigating various options to improve our plugin support. Many plugin developers updated their installers to improve support for the Mac App Store version of PhotoShop Elements so that just one of the options we are looking at.

 

We will update you all when we have a definite plan and schedule.

Link to comment
Share on other sites

Thanks Tony - glad to hear all that!

 

I take it that "PhotoPlus Elements" refers to your Windows editor and that you are looking a cross-platform solution?

Retina iMac (4K display, 1TB SSD, 16GB RAM) OS X 10.11.6  Capture One 10.

 

Link to comment
Share on other sites

  • Staff

Thanks Tony - glad to hear all that!

 

I take it that "PhotoPlus Elements" refers to your Windows editor and that you are looking a cross-platform solution?

 

No, just a typo that I have just fixed  :o

Link to comment
Share on other sites

We are still investigating various options to improve our plugin support. Many plugin developers updated their installers to improve support for the Mac App Store version of PhotoShop Elements so that just one of the options we are looking at.

 

We will update you all when we have a definite plan and schedule.

I am glad to hear that no one has given up and that there is still work going on concerning this issue.

 

I know I have said it before but if the developers would give us the ability to call an external editor it would solve a lot of these problems for a lot of us.

Link to comment
Share on other sites

I am glad to hear that no one has given up and that there is still work going on concerning this issue.

 

I know I have said it before but if the developers would give us the ability to call an external editor it would solve a lot of these problems for a lot of us.

 

File reveal in finder  then select open with ...

Seems to be the easiest work around so far, pass a psd file to the various apps for plugin's, thats my plan for now.    

Link to comment
Share on other sites

Welcome to the AP Customer Beta Forum @blackest!

 

I don't think that is quite what several of us have been asking.  For example I can (and already do) do that by calling various Topaz plugins from Aperture (and Mike from Mesa does it through (I think) OnOne and/or photoFXlab).  What we are asking for is a plugin UI that allows us to access all the common plugins directly from within AP.  

Retina iMac (4K display, 1TB SSD, 16GB RAM) OS X 10.11.6  Capture One 10.

 

Link to comment
Share on other sites

File reveal in finder  then select open with ...

Seems to be the easiest work around so far, pass a psd file to the various apps for plugin's, thats my plan for now.    

The whole idea is to be able to open an image in AP, edit it, then be able to further edit that same image in a plugin. What that means is that the image in the editor, along with its edits, is opened in the plugin, further adjusted and then returned to the editor in a seamless sort of way.

 

Using Reveal in Finder and then Open With fails to do that because (1) it will open the image on disc, not the one in memory and (2) will not return the image to the editor for further editing. For your suggestion to work would require more like the following:

 

1) Load image into AP,

2) Edit in AP,

3) Save image. If your original image was raw, Export, not Save, image,

4) Since an exported image will not always be the same named image you have in AP you will now have to use Finder to find the image,

5) Select the file you just found in (4) and Open With,

6) Edit in plugin or plugin app,

7) Save image from plugin or plugin app,

8) Reload the image in (7),

9) Further edit loaded image,

10) Save or Export edited image

 

The bolded steps are those you would have to add to be able to use your idea regularly. I am not saying it would not work but there are quite a lot of added steps beyond just having the built-in capability to call an external editor and pass it the file to be edited.

Link to comment
Share on other sites

The whole idea is to be able to open an image in AP, edit it, then be able to further edit that same image in a plugin. What that means is that the image in the editor, along with its edits, is opened in the plugin, further adjusted and then returned to the editor in a seamless sort of way.

 

Using Reveal in Finder and then Open With fails to do that because (1) it will open the image on disc, not the one in memory and (2) will not return the image to the editor for further editing. For your suggestion to work would require more like the following:

 

1) Load image into AP,

2) Edit in AP,

3) Save image. If your original image was raw, Export, not Save, image,

4) Since an exported image will not always be the same named image you have in AP you will now have to use Finder to find the image,

5) Select the file you just found in (4) and Open With,

6) Edit in plugin or plugin app,

7) Save image from plugin or plugin app,

8) Reload the image in (7),

9) Further edit loaded image,

10) Save or Export edited image

 

The bolded steps are those you would have to add to be able to use your idea regularly. I am not saying it would not work but there are quite a lot of added steps beyond just having the built-in capability to call an external editor and pass it the file to be edited.

 

It is less than ideal, very much so, being on a unix base it shouldn't be too hard to pipe data from one program to another and the problem is no obvious way to do it within affinity photo.

 

lightroom's external editor function is quite powerful.

Basically the user sets up the format of the call. The colour space and the file format generally psd or tiff.  

so it would be lightroom decides to run gimp with the current image as a command line argument.

kind of like $>gimp myphoto.psd

 

when gimp terminates a return code is generated and then lightroom can open myphoto.psd with the changes made in gimp. Ideally keeping the before and after in the history. There may be no change to the offered file maybe the user resized the image in gimp and saved it out to email it. There may be additional layers in the psd (which may be hard to replicate) but essentially all lightroom needs to know is I gave gimp myphoto.psd now it has finished with it i can load the new version back in and carry on working with it.

 

obviously I can hit save in affinity photo and select the file type then open the file i just saved in finder with another program do something with it save it from that program and reopen in affinity photo. Its the same difference apart from i'm working for the computer instead of the computer working for me! :)

 

Obviously it would be nice if plugin authors would be co operative with affinity photo, hopefully as infinity photo's user base grows they will see an opportunity to target affinity photo as well as adobe photoshop and lightroom.

 

An editin module is not ideal but it should be relatively easy to do, even if most popular plugins worked it'd still be handy.   

Link to comment
Share on other sites

blackest:

 

Sorry for the delay but I have been out camping and only just now returned.

 

It is less than ideal, very much so, being on a unix base it shouldn't be too hard to pipe data from one program to another and the problem is no obvious way to do it within affinity photo.

 

Remember. The idea of a plugin is to present processing as though the plugin call and interface was nothing more than another dialog box in the original program. It should be quick and it should be seamless. Given that, the idea of piping data from one program to another does not work since the data must be piped both ways. That is, the calling program would have to pass the data to the called program which would then have to pipe data back to the original. Even that is not enough since the data has to replace the original data as though another simple edit had been done. Having the called program return data to the calling program as another image simply fails as a seamless process. When you call a plugin with file1 you do not get file2 as a return. You get a changed file1.

 

An editin module is not ideal but it should be relatively easy to do, even if most popular plugins worked it'd still be handy.  

 

Even this is not as simple as it sounds. The normal way to do this is something like the following:

 

1) pixel editor saves the current image as a temporary file in the temp file location,

2) pixel editor calls the external editor with the path of the temp file,

3) external editor opens and displays the temp file,

4) user works on the image in the external editor and then saves the changed image,

5) pixel editor, which has placed a watch on the temp folder and file notices the update and loads the temp file

 

​All of this sounds fairly simple but there are some issues involved. For example, if you send a tif file to an external editor and then save that tif image in that external editor the editor may change the tif suffix to tiff and then the app watching the temp folder and file will not know that the expected file has been updated. This exact scenario is, in fact, what actually happens if you use photoLine and call Elements as an external editor. photoLine sends a tif but Elements, even though it recognizes that it has a tif, will always save the file as a tiff. To solve this problem on my machine I had to write a service to watch for the tif file being updated as a tiff and then change it back to tif. That solved the problem, but it is not the general kind of solution that can be placed into a normal external editor call.

 

The problem is certainly solvable, but it may not be as simple as it at first seemed.

Link to comment
Share on other sites

I attended a webinar for one of the Topaz plugins the other day and some one asked If Topaz planned on making their plugins work with Affinity Photo. The moderators response was " We are considering it."

Wow! That that is really news. I am very surprised. Pleased, but surprised.

 

Thank you for sharing what you heard.

Link to comment
Share on other sites

blackest:

 

Sorry for the delay but I have been out camping and only just now returned.

 

It is less than ideal, very much so, being on a unix base it shouldn't be too hard to pipe data from one program to another and the problem is no obvious way to do it within affinity photo.

 

Remember. The idea of a plugin is to present processing as though the plugin call and interface was nothing more than another dialog box in the original program. It should be quick and it should be seamless. Given that, the idea of piping data from one program to another does not work since the data must be piped both ways. That is, the calling program would have to pass the data to the called program which would then have to pipe data back to the original. Even that is not enough since the data has to replace the original data as though another simple edit had been done. Having the called program return data to the calling program as another image simply fails as a seamless process. When you call a plugin with file1 you do not get file2 as a return. You get a changed file1.

 

An editin module is not ideal but it should be relatively easy to do, even if most popular plugins worked it'd still be handy.  

 

Even this is not as simple as it sounds. The normal way to do this is something like the following:

 

1) pixel editor saves the current image as a temporary file in the temp file location,

2) pixel editor calls the external editor with the path of the temp file,

3) external editor opens and displays the temp file,

4) user works on the image in the external editor and then saves the changed image,

5) pixel editor, which has placed a watch on the temp folder and file notices the update and loads the temp file

 

​All of this sounds fairly simple but there are some issues involved. For example, if you send a tif file to an external editor and then save that tif image in that external editor the editor may change the tif suffix to tiff and then the app watching the temp folder and file will not know that the expected file has been updated. This exact scenario is, in fact, what actually happens if you use photoLine and call Elements as an external editor. photoLine sends a tif but Elements, even though it recognizes that it has a tif, will always save the file as a tiff. To solve this problem on my machine I had to write a service to watch for the tif file being updated as a tiff and then change it back to tif. That solved the problem, but it is not the general kind of solution that can be placed into a normal external editor call.

 

The problem is certainly solvable, but it may not be as simple as it at first seemed.

when you say had to write a service, was that with automator ?

I'd love to hear a little more on the details of that.

I apologize for straying off topic but its interesting :)

Link to comment
Share on other sites

when you say had to write a service, was that with automator ?

I'd love to hear a little more on the details of that.

I apologize for straying off topic but its interesting :)

I am not a long-term Mac user and I don't even know if the term "service" is appropriate for the Mac. I wrote the equivalent of a Windows service, but as a stand-alone program. It was nothing special, but it was objective-c code, written with Xcode (not the automator), that starts, monitors the temp folder that is used to create the temp tif file, notes the names of any new temp tif files and then looks for a corresponding tiff file. When, and if, it finds it, it renames it to tif and starts scanning again.

 

It is nothing very clever, just a simple little folder/file watcher and solves the problem for me. photoLine picks up the returned and renamed file and all is right with the world - or at least that part of it that lives on my Mac.

Link to comment
Share on other sites

Wow! That that is really news. I am very surprised. Pleased, but surprised.

 

Thank you for sharing what you heard.

Yes Mike I was pleasantly surprised too. The moderator did say that presently Affinity is not supported so I decided to send them an email letting them know that though there are clearly issues, some of the plugins do work. I verified tonight that I can open, use and return to Affinity with Adjust, Detail, and Simplify in both the MAS and newest beta versions and told them this in the email. I told them for me, Clarity quits before launching in the MAS version but opens and allows changes in the beta. But when I click "OK" to go back to Affinity I get a screen asking for a validation code. Strange because it accepted the code when I first loaded the plugins and tested them. I put in the code and then get a screen saying the validation failed because the code was invalid. I tried this multiple times and the code is valid and correct. I told them there is a growing community of Affinity users anxious to use their plugins. I will let you know if I get a response.

Link to comment
Share on other sites

I verified tonight that I can open, use and return to Affinity with Adjust, Detail, and Simplify in both the MAS and newest beta versions and told them this in the email. I told them for me, Clarity quits before launching in the MAS version but opens and allows changes in the beta. But when I click "OK" to go back to Affinity I get a screen asking for a validation code. 

I have five Topaz plugins - Adjust, Clarity, Detail, DeNoise and ReMask. Adjust, Detail and DeNoise work properly and do so repeatedly. That is, if I call Adjust for an image, adjust it and return I can then call Adjust, or Detail or DeNoise, again with the same image and get a working response. Clarity is different for me.

 

If I call Clarity as the first plugin for an image it appears to work. But if I then call another plugin, say Adjust which works on its own, it crashes so running Clarity seems to do something to the plugin interface and running any other plugin after it causes a crash. Generally if I first run Adjust or Detail or DeNoise, then call Clarity, it crashes.

 

ReMask 4 will not launch.

Link to comment
Share on other sites

Reply from Topaz Labs....

 

Jim,

Thank you for contacting Topaz Labs with your feedback on the webinar and Affinity Photo support.

We are indeed considering supporting Affinity Photo, but we are currently busy with other projects that are receiving a higher priority from our developers. If we decide that demand is strong enough for Affinity Photo support, then we will approach compatibility properly, and fix whatever bugs might exist to make sure our software is represented well. However, at the present time, it is not on our to-do list.

Each request like this one pushes us closer to actually making the updates!

Please let me know if you have any additional questions or concerns, and I will be happy to assist!

Respectfully,

Joe Fedric
Customer Happiness Specialist
Topaz Labs
Monday - Friday 8:30am - 5:30pm CDT

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.