Def no change with Nik on Mac. Behaving exactly as in the last release. Mike, what is supposed to happen if I do the same thing in a Project? I tried it here but the tiff was not created or returned to the Project folder, it all happened behind the scenes in the “real” folder, if you get my drift. That seems pretty pointless to me unless a) I am missing a trick or b) its a bug.
Out of curiosity I downloaded and installed the Dxo Nik stuff and then called it from PL2. I have not used the Nik apps in a long time so I picked something that would be easy to check - Silver FX - and changed the image into B&W. I then saved it back and, sure enough, I saw the change in PL2.
So, for some reason, it worked on my system.
I have found it flaky, sometimes it works and others it does not but I cannot identify a pattern. There is also the issue with working in Projects. That consistently fails to work as I would expect. I have been using Color Efex.
how is the coupling in mac with exporting?
ive tested multiple editing on two or more niktools.
case: rawfile export to nikcollections by processing a tiff,
after editing, exit by save brings you back to dpl,
after this a new export to next niktool.
edit and save back again.
How is the behaviour and tif file naming in mac?
I have had no problems others that those I have explained, Peter. I have done no second edits though so I’ll run a test and let you know what happens. Is this the scenario you want me t look at:
- Edit raw in DPL
- Export tiff to Nik, edit and return to DPL
- Send edited tiff back to another Nik program, edit and return to DPL
Did the above. First tif generated from raw was 0025-openWith.tif and this was exported and edited in ColorEfex and then returned to DPL. Then sent that tif (exported without processing) to AnalogEfex for further editing and the tif came back to DPL with the same name - 0025-openWith.tif. This is what I would have expected but does it answer your question, Peter?
wel i did this:
small test.
And some how it didn’t do what i expected.
my first difference between v1.2 and v2.0 is that filename.temp1 isn’t used anymore.
But in order to use multiple tools of the collection without fludding the folder with stage one and stage two temporaly files i seem to cleanup myself.
So i thought is this a windows or general way it happens?
This is all very odd to me.
Yesterday I processed several hundred photos in PL2, and exported perhaps 2 dozen to Photoshop, saved them and the changes showed up back in PL. That is, the _openWith.tif got sent to PS, I edited them, flattened them and saved them and the _openWith showed the PS changes. I ran some tests with the Nik stuff and those changes showed up back in PL2.
Today none of that is working. I have repeated my tests and, so far, no changes have showed up back in PL2. I will continue to test, but I do not know what is different today than yesterday, or why none of the changes are showing up back in PL2.
That’s odd indeed, but this might be a side effect of some kind from something else we worked on. There were a few supporting components to the bug fix itself, some of them being in 2.1.0, some of them not.
But I can definitely confirm the bug fix will be in the version that comes right after 2.1.0 (along with other stuff), and it should support all cases properly.
> this might be a side effect of some kind from something else we worked on
That is what I have assumed. What is even more interesting is that the ability of PL2 to properly handle returned images from the pixel editor seems to depend upon when the last install was done. That is, if I re-install PL2, start it and then process images, everything works. If I exit PL2 and restart it, things are back to how they used to be. Send an image to PS or some other external editor and you do not see the changes back in PL2. Reinstall PL2 and again things work. I have now tried that sequence at least twice and this is how it worked each time.
I made the assumption that something in the install caused the temporary working of the returned images and that rebooting the Mac or restarting PL2 cleared that condition. I posted all of this just in case it was of some interest to the developers - it seems to me that the install is doing something to the way PL2 works with High Sierra (on my machine) and that it might be helpful for the developers to know this, but I am content to wait for the next upgrade for the problem to be fixed.
> I can definitely confirm the bug fix will be in the version that comes right after 2.1.0 (along with other stuff), and it should support all cases properly.
Thank you for taking care of this. As I said, I am content to wait for that update.
Hey folks, just a quick note because you’ll see an update appearing today (version 2.1.1)… I wanted to let you know that’s not it yet for this fix… We had to make a quick update before Christmas to fix a few nasty issues that some users were having, so it’s just 2.1.0 plus a few quick bug fixes.
The next big one (2.2) will be coming in a few weeks, and that’ll be it, pinkie promise!! 
5 Likes
Thanks for telling us. Since I now know it is coming I can wait a few more weeks.
Thanks for the heads up kettch!
Kettch, thank you for the info but I do not get any update when I open DPL
My version does not show the update and tells me, it’s up to date (v2.1.0 23440)
My version does not show the update and tells me, it’s up to date (v2.1.0 23440)
23440 would be a Windows build. This topic is about the Mac version 
Ok, sorry and thank you!
At long last, there it is!!!
Please, let me know if it works well for you guys. And sorry again it took so much time 
It works for me on a mac
1 Like
Of course I am on a camping trip when the version I have been waiting for is released … 
I will be back tomorrow and will install it then and let you know, but thank you for getting this done. I truly appreciate it.