I guess I give up

DxO PhotoLab macOS topics
21

I see. Tried again and found the same thing as you did as well as another workaround:

  1. select images
  2. create a project from the selection
  3. send intermediate files to PS as TIFFs
  4. process in PS and save (without renaming)
  5. open the original folder in DPL

This workaround skips the renaming and works well, unless you assemble files from multiple folders into one project. DPL seems to be smart enough to display new files in a folder and dumb enough to notice changes. DPL is also dumb enough to not display intermediate files in projectsā€¦

DxO definitely needs to do something about this.

1 Like
22

I will try this. I have not used projects before and perhaps that will provide a way around this issue.

UPDATE:

Well, that was interesting. I did as you suggested, created a project and modified some images using Photoshop. It did work, so it is a valid work-around. There are a couple of issues. In the Project I could not see the created tiff, so I had to switch to the folder to further adjust any modified images and then switch back to the project to work on the next image, but it did work.

So ā€œNo day is truly wasted if you learn something newā€.

Thanks for the work-around. It does save me the trouble of adding new large tiff files when there is no real reason to have to do so but, as you said, Dxo really should fix this problem. It has been years now.

23

Just out of interest:
1 it seems to be a Mac issue.(?) (i didā€™t test larger amounts of tiffs)
2 what is the difference, software wise, to label a image as ā€œprojectā€?
I know it is only tags the files which you choose to put in project. So is this workaround not the pointer to the software coding problem?
How can this be a problem for years? before PL was dxo optic pro a addition for pixel editors. plugin or firstbase. So this problem would be a major issue from the start or not?

24

Hello guys,

  • Yep, thatā€™s true. Windows users are not able to reproduce the issue because we fixed it ~ 1.5-2 years ago (do not remember the exact date it was reported on the Forum).

Regards,
Svetlana G.

25

If it was fixed on Windows computers years ago why was it not fixed on Mac computers?

26

This has been an issue ever since I began using Optics Pro on my Mac and as I remember that was version 5 or 6. I have been complaining about it almost from the start, and it was apparently fixed on Windows but not on the Mac. I have no idea why that would be, but it is discouraging to find out that the Dxo folks paid attention to the problem on Windows but left the issue to continue on the Mac.

27

DxO is revenue driven like every other company, just more so, and, yes, it is discouraging

28

Hello Mike,

Well, itā€™s because these are 2 different systems (and probably on Mac side itā€™s far more difficult to solve this issue) and 2 different teams and as you know the bugs are mostly different as well. When I reported about this problem to my team (Win) I didnā€™t know that on Mac there is the same problem.
So let me try to draw attention of the Mac team to this issue (@akarlovsky could you, please, have a look? ).
Please, do not give up.

Regards,
Svetlana G.

1 Like
29

Hello Mike,

Iā€™ve just created a bug on our (Mac) side. Weā€™ll take a look how difficult is it to fix and if itā€™s possible to include in one of the next release builds.

Best regards,
Alex

2 Likes
30

Thank you for doing this. I appreciate it. But please understand that I have been filing this as a bug report against the Mac for years. Literally for years, having first filed it perhaps 3 or 4 years ago, and have done so more recently as well. I am puzzled as to why no one knew of the problem, given my bug reports.

31

That would be very nice. Even a refresh command for the selected image would be better than nothing. Anything to force the Mac version to re-read the image file and display the changes done by an external pixel editor.

It would be good if something could be posted here to indicate if this will actually be fixed and, if so, what the timeline might be. Not necessarily a fixed date but some indication. As I have posted before this has been an issue for many years and it would be nice to know it would actually be addressed.

32

Hey Mike,

Rest assured, we still have that bug filed, and even if some members of the Mac team donā€™t know about it or donā€™t remember it, I do, since I was the one who took a look at one of your support tickets on this issue back in November 2013.

I understand how this can be quite frustrating, and I can see the limitation here and how this makes no sense to not have this. Having a feature that exports an image to another app, where you can actually modify it, means you want that image to be updated when you come back, and it should be there out of the box.

That being said, let me elaborate a bit on the reasons for this limitation. OpticsPro/PhotoLab is an app that has been working exclusively on RAW files for a long time, and those are never being modified. Exporting to an external app was quite a change in that regard, and it means that files need to be considered quite differently if they can change behind PhotoLabā€™s back. Unfortunately, quite a few important pieces of the app had been thought out for the first case only, and this means that making everything update properly when the fileā€™s contents are changed is not as easy as it would seem at first glance. In particular, we are keeping quite a few internal caches so that coming back to an image you just saw is way faster than reloading it from scratch. This is one of the pieces that would need to fully reload if we detect that the file has changed, but this requires quite a bit of work.

As Svetlana was stating above, the Mac and Windows versions are different, and this means that both have different limitations and issues. Some features or bugs can prove really nasty on one side, while being a breeze to fix on the other. And unfortunately, you stumbled onto one of those.

Given the complexity of solving this bug, and the low count of reports, this ended up being low priority against other things, as the team has to make choices, especially in the face of limited resources.
However, some coming features may end up creating some similar issues, and as the code base evolved since then, the issue may prove simpler to solve now. Iā€™ll take another look at it in the coming weeks and see if I can find some way to roll that out to you.

3 Likes
33

Thank you. It is encouraging to think that someone somewhere cares about this issue.

PhotoLab, and Optics Pro before it, has been my preferred workflow tool ever since I bought my first version of OP, and I have updated regularly in spite of this issue, but 5 years has been a long time to wait for resolution of this problem. Perhaps I can look forward to it getting fixed relatively soon. As you pointed out in your response, it makes no sense for PL to export to an external application and not expect the image to be changed by that app.

1 Like
34

I am a relatively new DXO user, and was disappointed that this feature did not work in Optics Pro versions I used before as well as in PL.
That feature is one of the main features I hoped would work but sadly discovered it did not.
I do hope that it will be fixed.
I have been going back and forth between various photo editing software hoping to narrow down the best combination for my workflow. I thought DXO was a main piece to the puzzle, but began to question it. I hope this feature will be resolved sooner than later. thanks

35

Mike, wouldnā€™t it make more sense not to roundtrip to Photo Lab? When a tiff has been edited elsewhere it doesnā€™t come back to Photo Lab at all (except as a new file)? I agree though it should be easy to export a tiff, work it in an external application and save back to that file. Thereā€™s no reason to protect the exported tiff as we can always create another one from the original RAW.

36

I guess I either do not understand your response or disagree with it. I am not sure which because I am not sure exactly what you mean. My fault, not yours.

> When a tiff has been edited elsewhere it doesnā€™t come back to Photo Lab at all (except as a new file)?

Why not?

What is the purpose of exporting an image to an external editor if not to change it? And then why should that changed file not be returned to PL for further editing? Consider - I have an image with something wrong or something I wish to adjust. Perhaps there is some lens flare, or perhaps I wish to remove or add something, perhaps I wish to change a sky, or correct some distortion that can not be fixed in PL itself (I do have Dxoā€™s ViewPoint 3). I fix or change what needs to be changed, but that does not mean that the image does not need further processing, so I return it to PL for that processing.

I do not see why you would not consider this to be normal editing. Perhaps I am missing something?

> Thereā€™s no reason to protect the exported tiff as we can always create another one from the original RAW.

Then why not be able to save it back to the original tiff image and edit it further in PL? I must be missing your point here.

37

Mike, thanks for the additional explanation.

DxO Photo Lab is a RAW converter with a little bit of local adjustment added on (like Repair). Itā€™s not a DAM or an all-in-one image management program like Adobe Lightroom (thank heavens).

When a RAW is ready, DxO Photo Lab exports that RAW in whatever format you need. Hopefully when you have exported the RAW you would then take it into your bitmap editor and it would not need to come back to DxO Photo Lab. Of course, I can imagine instants where one might want to bring a file back for some additional colour tweaks as a jpeg. But this would seem to me a fairly infrequent occurrence if the photographer has thoughtfully processed his RAW in the first place.

Each additional round of corrections and processing adds digital noise. The joy of a RAW converter is when it does as many corrections in a single round from a single master without roundtripping. Your photo processing would be so much simpler if you would respect the role of the RAW processor and not impose an extra roundtrip back to DxO Photo Lab. Your workflow seems like a fairly infrequent way of working with a RAW converter (once one of my images moves to a pixel editor I donā€™t bring a photo back to a RAW converter for further processing).

Even when I used Apple Aperture as my DAM and RAW processor I would strive to avoid the kind of double processing you are proposing, although Aperture supports it. I noticed a distinct fall off in image quality when doing two rounds of corrections within Aperture after round tripping an image to an external bitmap process. What you propose would make more sense if image editors were able to share and work on RAW files. Sadly, we are tens of years away from a common RAW format and corrections language. Agreeing on how to save and encode tiffs and include metadata took decades and remains imperfect.

Letā€™s take your example:

have an image with something wrong or something I wish to adjust. Perhaps there is some lens flare, or perhaps I wish to remove or add something, perhaps I wish to change a sky, or correct some distortion that can not be fixed in PL itself.

Iā€™d suggest you complete the RAW conversion in DxO Photo Lab, including any perspective correction you wish to apply there (keep in mind most bitmap editors have fairly good perspective tools themselves). When you export to the bitmap editor, itā€™s for good. You remove the lens flare and correct the sky and save for publication. If you were wish to use DxO Photo Lab colour correction tools again on those particular images, you then reopen those new files as separate files (even in a separate folder) for the additional processing. Youā€™ve lost nothing over your proposed workflow and avoided potential file corruption and non-compatible saves (not all applications save tiffs and metadata in exactly the same way).

38

Your argument seems to be that PL is a raw editor and therefore it is basically malpractice to try to further process tiffs and/or jpgs. That argument would carry more weight, at least with me, if PL just did not open and edit tiffs and jpgs. That is, if you are right, then why does PL even open tiffs and jpgs and allow me to edit them? And if it is going to allow me to edit tiffs and jpgs, why will it not allow me to open and edit one returned from an external pixel editor?

The fact is that there are some edits that can only be done in a pixel editor and which are so central to processing an image that it then needs further processing which can not be done until those critical edits are completed. Lens flare is one of those, adding or removing things to an image is another, and there are more such edits. Your suggestion would limit PL to only doing the initial processing. I would add to that two more things. One, the comment by the Dxo staff member in this thread:

I can see the limitation here and how this makes no sense to not have this. Having a feature that exports an image to another app, where you can actually modify it, means you want that image to be updated when you come back

That is right. Having the functionality to export to another application makes no sense if you donā€™t expect to get it back for further processing. This is done in the Windows version so your argument would seem to be either that it is OK to do this in the Windows version but not in the Mac, or the Dxo staff did not know that they were making a mistake when they fixed it in the Windows version. Neither of those makes sense to me.

Second, as I pointed out, every other raw converter workflow on the market accepts that exporting to an external editor implies that the image will come back for further editing. What is it that makes PhotoLab different from those tools? CaptureOne is a professional workflow tool that is a raw converter, and it not only does ā€œround-trippingā€ with images, it advertises that as a central and core function. Or course LR does it, as does AlienSkinā€™s Exposure X3/4, Corelā€™s AfterShot Pro, ACDSeeā€™s Photo Studio and all of the others. They are all raw converters, some better than others.

I understand that your workflow does not require (or will not allow) images to ā€œround-tripā€ to an external editor, but I do not see why your workflow is any more ā€œcorrectā€ than mine, which does allow images to ā€œround tripā€. All that I am trying to do is make my images the best that I can make them and do so with the least amount of work, and for me that means ā€œround-trippingā€ those images.

Dxo can make whatever processing decisions they wish. If they wish to continue to disallow ā€œround-trippingā€ of images that is their choice, but I also can make the the same decisions as they apply to whatever processor I choose to buy and, for me, that functionality is important and central to my workflow.

You mentioned that PhotoLab is not a DAM. True enough, although it seems to be headed in that direction. You also said that it is not an all-in-one image management program, but then neither is Lightroom unless you consider Lightroom and Photoshop to be a single processing entity. Personally I need both the ease of a workflow tool that is also a raw editor and an external pixel editor to take care of my images and I need them to be able to interact. My choice for that is PhotoLab and Photoshop, provided Dxo will allow me to use them that way. If not, then I will replace PhotoLab with something that will.

39

Hey Mike,

I see that this bug is still generating quite a bit of discussion in there. Iā€™ll keep out of the arguments for or against making a roundtrip back to PhotoLab, because we usually reckon that people may have different workflows, and we need to at least be able to support whatever youā€™re trying to do as best as we can. Itā€™s also not uncommon to have you guys find new creative ways to do stuff we hadnā€™t thought about!

In any case, Iā€™m happy to report some good news: I managed to make the reload work properly for images modified outside of PhotoLab. We ran into other trouble, so itā€™s depending on a few other things that are not finished yet, but itā€™ll come in the next weeks. You may see a minor version coming out soon that wonā€™t have that, for the same reasons, but itā€™ll come eventually. When Iā€™m sure that itā€™s fully ironed out and ready to get to you, Iā€™ll let you know!

40

Hi hettch,

are you from the DxO staff? If so, you need a ā€œDxO Staffā€ badge, like Svetlana, otherwise it is easy to oversee important information, DxO gives us.