I doubt that you’re missing anything. The Nik collection consists of several completely independent applications without a common interface or anything else binding them together except by the name Nik Collection.
Regardless of the software package you are using, like Lightroom, PL2, or even PSE, you send a .tif or .jpg image to the Nik application of your choice and when completed it is returned to the original application. If you want to use a different Nik application on the same image you need to send it again.
There is no way around that process flow unless and until, DXO completely integrates all these separate Nik applications into Photolab. like they have with Filmpack, or integrates all of the separate Nik applications into one cohesive Nik application where all features and functionality can be addressed from a central point requiring only a single export. Of course, a better solution would be a completely non-destructive approach if Nik Collection could be modified to accept raw images with DXO side car files and/or access to the DXO database.
Yes. I understand that. And since it is basically a new image PL should display it. as it is, not as it was before it was sent to the external editor.
I agree that PL is a raw editor, but it also edits tiffs and jpgs as anyone can see by browsing to a folder containing them. If it is going to allow you to edit tiffs and jpgs, then by does support or anyone else say that it is a raw editor with the implied statement that you should not edit anything else?
As far as whether round-tripping makes more sense in a DAM, I do not see why that should be. I have no need for a DAM, and do not wish one, but I often need to send a raw image, as an exported tiff, to Photoshop to fix something PL can not fix, and then need to edit it properly. Why does that not make sense to support? And what is the difference between editing a returned Photoshop-edited tiff and editing one produced by a camera? Or doing the same with a jpg?
And, of course, the immediate response is why, if you should not edit returned tiffs and jpgs, did the PL developers just release fixes to allow you to do just that? And why are those changes marked as “fixes”, implying that there was an issue, if they do not expect a user to do exactly what the “fix” allows users to do?
Personally the workflow of sending a RAW file out to Photoshop for corrections and then automatically bringing it back into PhotoLab risks confusing users. There is no “round trip” what left is no longer attached to the original RAW in any way and is a new file, with all the limitations of TIFF.
Frankly it’s less confusing to have the user then bring his finished master back into PhotoLab in a different import and folder than having it showing up beside the real master (the RAW file).
That said, if TIFFs which are brought back into PhotoLab are clearly marked as TIFFS and given some kind of colour coding, the feature would be neither here nor there. The crowd using PhotoLab as web export software is barking up the wrong tree. PhotoLab is very good for creating masters but has limits as web export software (watermarking, speed). Very capable image converter with batch conversion and advanced watermarking and really fast processing are either free or cost in the $10 to $20 range.
All of this fiddling around with file handling and web export takes away from developer time which could be spent improving the core functionality of RAW development, both performance (sadly lacking) and efficiency.
PS. The title of this thread should probably be changed by a moderator as forum threads with this kind of language in the subject creates a very negative atmosphere on the forum. @sgospodarenko PhotoLab is amazing software as it stands right now, with no parallel for semi-automated advanced RAW development and aesthetic experience. PhotoLab is easily the most attractive and easiest to learn advanced RAW tool in the world.
Confusing to whom? Are you saying it is confusing to you? If not you, then who?
It is certainly not confusing to me, and probably not to anyone who uses round-tripping with any other workflow tool. Pick one - CaptureOne, ON1, Alien Skin, Luminar, AfterShot Pro - they all support round-tripping and I have never seen a post about this functionality being confusing to a single user until your comment.
I originally titled this thread with exactly how I felt. I had been asking for this change for 5 years, pointing out that OP, and now PL was the only workflow software that had this limitation and, after 5 years, I had frankly given up, and so I said exactly that. The moderator is certainly entitled to change the title if he or she so wishes, but it would change the entire tone of the original post, which was a sad acknowledgement that it looked like this change would never happen and I would have to leave software I had been otherwise happily using for many years.
The idea that posters should be censored in their post (other than concerning language or offensive comments or off-topic comments), lest other users be discouraged, seems a bit odd to me.
As far as I can tell anyone reading the post and following the thread would have hope rather than despair as the problem was addressed, indicating that the developers and staff were listening to their users. That seems to me to be a positive message, not a negative one.
As far as PL being a great tool, that has been, and remains, my opinion as well, but I also feel that support has been less than supportive of the user, at least until recently, and that change should also give users hope.
The title of the thread has nothing to do with the feature and uses very negative loaded language. Moreover, the title is clickbait and gives no information about the nature of your complaint.
It’s not a matter of censorship but of basic forum/communication hygiene.
So the thread is about the lack of basic processing functionality in Photo Lab, the fact that 5 years of requests to update processing to match all other workflow tools had produced nothing, the despair that had produced in me and my decision to find another software package, but your complaint is that you think the title was click-bait?
In fact I did not expect any responses and was surprised that support, which had not responded to any of my previous postings about the problem in any positive way, did so with this post. If that response had anything to do with a title that caught their attention, so be it, and if the fix was a result of what you call “click-bait”, all the better.
The fact is that round-tripping functionality was added after 5 years of complaints about it not being available and if getting that basic functionality added to Photo Lab costs me the charge of using “click-bait”, that seems like a minor inconvenience to me considering the result.
But, aside from all of that, I am puzzled by your earlier comment that Photo Lab is a raw converter and that I should not be processing tiffs or jpgs with it, even if they were the result of round-tripping. I can not help but wonder if you think that Photo Lab should stop processing tiffs and jpgs completely and only work on raw images. That is an honest question. Would you prefer that Photo Lab only accept raw images as input and ignore all tiffs and jpgs, regardless of their source?
As it is I use PL to process the raw images from my camera, but also the jpgs from my wife’s point-and-shoot. Are you suggesting that PL should no longer allow any images other than raw images to be processed? And, if that is not your view, what is the difference between tiffs and jpgs from user’s cameras and those produced by round-tripping? Why allow one and not the other? As I said, that is an honest question. I am trying to understand your view on the matter.
Have you heard of the sophists, Mike? Your justification for using clickbait rather than factual titles to your posts seems like sophism. As does your attempt to put words into my mouth about not processing jpegs.
The point which I made very clearly is that any file sent out of PhotoLab is no longer within its workflow and is a new file when it comes back, with no link to the original file. Why you even care about this pseudo-roundtripping is a mystery to me as the file you get back is just a new file which you could just as easily save the final image in the target application if it’s a Nik application or bring back en masse (I assume you’re not processing single files in a day) for a new round of touchups when you’re done with your Nik work.
Again, I don’t care if the functionality is there or not as long as it’s not misleadingly labelled round tripping. The file which comes back is a new one, like it or not, with no ability to go back and correct the RAW and see updates with the third party processing.
It seems to me you are deliberately misunderstanding and misinterpreting all communication here. What I don’t like is how a thread with a false title is now very prominent. This forum vandalism was deliberate it appears. What’s worse is that once there’s one broken window others follow.
I will make the following comment. Round-tripping an image does not mean that it is any longer associated with the original raw, and I never suggested that it did. In fact the term “round-tripping”, as used by CaptureOne for example, means specifically that the image is a new image, it has been edited by an external editor other than CaptureOne and stands on its own. The same is true with Photo Lab. I never said, nor did I imply, that a round-tripped image is in any way tied to the original raw. That does not mean that it should not be editable in its new form.
Having said that, it seems to me that there is no point in continuing to respond to your posts. Your accusations (I am a sophist, I am deliberately using click bait, I am deliberately misconstruing your comments) are both wrong and personally offensive enough that there seems to be no point in continuing to respond as you are no longer posting about functionality but rather have descended into personal invective. I thought that a forum like this was to discuss Photo Lab, not to belittle or accuse others.
Believe what you wish. You will anyway, regardless of what I post.
I have been tracking your odyssey since the old Optics Pro forum; and so I understood the context of the subject heading of this post immediately when I saw it (exasperation). Congrats on getting a resolution. I admire your persistence along with kudos to the DxO team for following through…
For maximum compatibility between your photo files and DxO PhotoLab 2, only the original and unmodified photo files from your camera should ever be used in PhotoLab 2. Your workflow needs to be as follows
ORIGINAL CAMERA PHOTO FILE > DXO PHOTOLAB 2 > NIK COLLECTION 2018 (OR ANY OTHER POST-PRODUCTION PROGRAM) > FINISHED PHOTO FILE
If you need to make additional changes to your original files in PhotoLab 2, you should return to them in PhotoLab to make those changes. The program keeps a complete history of all changes made to your photos.
Indeed, I can understand that it would be puzzling to get such a reply. The first part, though, is quite true, in a certain context.
We recommend that you use your RAW files, straight out of your camera, without having them pass through another editor first. What could happen there is that the image could go through Photoshop / Camera RAW, or through other so-called importers, that actually change the file. When that happens, some MakerNotes are lost in the image, which leads to us not being able to identify the body/lens properly.
However, once a file is exported, working on it in various applications, whatever the order, is perfectly fine, of course! You’ll lose the benefit of the RAW, obviously, which means that some corrections will be impossible or less effective, so it’s of course recommended to apply those before you export the first time, but then, it’s up to you to do as suits you.
I’ll discuss that with my colleagues in the Support team so that they are clear on that. Thanks for pointing it out!
I face the same issue (I skip the details here as not relevant), and I have the same concern as you do. I fully support your request, and hope that DxO will somehow manage to fix it - though I am guessing that only a small percentage of users with more complex workflow are currently affected.
By the way, on any forum there are some who prefer to play the man not the ball – indeed, not responding directly to such individuals is the best practice (don’t feed…).
That was always the way I handled it. I never sent my original raw images to ACR and Photoshop, but always sent exported images, mostly tiffs, to Photoshop for some adjustments that I could not do in PL2. For example, if I had lens flare that could not be repaired in PL2 I would export a tiff to PS, fix it there if I could, return it and then wish to continue processing. The inability to see the fixes that had been repaired in PS was the issue.
The same sort of thing happened if I had content or distortion to remove. I would export the image, as a tiff, to PS, fix the problem and return it. Until the latest fix which addressed this image I always had to either exit PL, change the name of the folder (to force a re-read) and restart it or, alternately, rename the saved tiff. Now I no longer have to go through all of that.
DxO need to introduce “layers” into PL like many other software have done, the RAW file isn’t affected and keep your RAW edit in the xmp file.
The edit image in plugin comeback in a second layer, chance are no you can’t keep the record of the edit done elsewhere but its there, you can adjust the intensity, paint it or turn it off, having layer would make working with the control point so much easier, you can insulate and name your layer by what’s being affected, that’s what I wish DxO would do.
DXO has a large backlog of updates and new features in the pipeline, and are very slow getting them implemented as it is. Do you really believe the DXO team are in any position to consider implementing a fundamental redesign of PhotoLab to include layers?
I know it can be done. ON1 has even figured out how to use layers non- destructively with raw files. But Photolab is still a much, much better raw converter then ON1. So its not a question of can it be done, but more of having sufficient resources available and a commitment to get it done. I don’t believe they have the resources, which is evident by the small number of feature updates.
The addition of layers would be welcome, but I am not sure that there are sufficient resources to do the work and I personally think there are other features that would be more helpful. I would like to see the addition of Luminosity Masking and the complete integration of the Nik stuff, although completely integrating the Nik functionality would remove the need to buy the Nik apps, so that would probably not be high on the accountant’s list.
I suppose they could integrate Nik similarly to the way they integrated FilmPack. You would still have to buy it like Filmpack. And there are probably many more people interested in the Nik collection who are not PhotoLab users so I doubt integrating it would hurt sales. However Its unlikely all of the very significant amount of Nik functionality will ever be implemented, and lots of it can also be done in FilmPack, albeit with much greater effort, My guess if if they implement it in PhotoLab at all, it will be bits and pieces, and may include a lot of new preset groups, each representing the existing presets of various Nik programs.
I agree although it seems to be mainly a Mac performance issue. However, even though I’m on Windows 10 I’m in favor of diverting resources to bring the Mac user experience up to the same level I’m enjoying in Windows. The lag I experience is minimal.