PL7 wish list

[migo33]

Great job DXO team on PL6. I would suggest that for PL7 you will concentrate more on the overall UX and UI. It’s a bit dated and needs some polishing in my opinion.

1. Presets - add it to the main toolbox , allow hover or click (not double clicking) to see the effect on the main photo not some small preview box.
2. Filter and sorting. Get rid of the drop down menu! it’s a PITA to quickly filter and sort photos.
3. Please add a summary photo overlay on the photo not as a popup on hover or relying on the left image info. (similar to info in LR)
4. Make the repair options (the top bar) a dedicated space as the other tools (colour, effects etc.).
5. Move the horizontal bottom photo strip scroll bar or make it slight bigger as it often triggers the apps shortcut bar on a Mac.
6. Automatically make selected project photos ‘duplicates’ so they can be modified without touching the master.
7. Allow users to change and add keyboard shortcuts.
8. Add third-party plugins and extensions especially exporting options.
9. Improve rendering performance when editing a photo. For example, when moving a correction slider don’t blur the photo for a split second.
10. Add manual rotation within crop mode. Or just add a rotation tool not a ‘horizontal’ tool.

[Joanna (Joanna Carter)]

@migo33

10. Add manual rotation within crop mode. Or just add a rotation tool not a ‘horizontal’ tool.

You mean like already exists in PL6?

[migo33]

Could be. I am on PL5 and not going to upgrade to 6. I thought more of a ‘handle’ rotation like most other design/ photo tools.

[Joanna (Joanna Carter)]

That’s just what you get. It’s just that the handle doesn’t show on a screenshot

[Egregius ((Greg) - Windows 11)]

@migo33

Improve rendering performance when editing a photo. For example, when moving a correction slider don’t blur the photo for a split second.

Already available in Preferences > Display:

[W.B]

I think item 7, the scheme of customizable shortcut keys is very feasible. If so, each of us can set shortcut keys according to our own software habits, or even assign only necessary shortcut keys as needed. And I also hope to add a side-by-side preview and comparison function, similar to the “side-by-side preview function” in the “Nikon Workshop” software (two or four images can be previewed on the same screen), which makes it easier to screen consecutive photos or photos with similar angles to help us speed up film selection efficiency.

[migo33]

This seems a bit harsh compare to other editing apps.

[Aearenda]

@migo33

• Filter and sorting. Get rid of the drop down menu! it’s a PITA to quickly filter and sort photos.

This! Please!

[platypus (Canon & Mac (Intel and M1))]

@migo33

ted project photos ‘duplicates’ so they can be modified without touching the master.

Sounds interesting, specially if the duplicates are virtual copies. If we then added a possibility to apply a preset per project…

For clarity of use, the menu could then say e.g.

• add to project
• add as virtual copy
• add as real copy

[migo33]

Yes something like that or just a virtual copy. This way you always have the master files even if you decide to remove the image from the project. This is what happened to me. I deleted photos from my project thinking they are still in the original folder. I think this is how LR handles project files.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@migo33

Automatically make selected project photos ‘duplicates’ so they can be modified without touching the master.

@migo33 I understand the notion that project VCs could have a separate existence to those in the original file.

But I have yet to work out fully how that could be implemented in the database because currently all VCs (and the [M]aster) are accessed simply via one index and all are entries in the ‘Items’ structure with the same image name. A ‘Project’ simply contains pointers to those entries in the 'Items structure, i.e. there is only one copy of the data but it is being “shared” between two paths (or many paths because the copy could be in many projects at any one time) one via the directory structure and one via the project structure.

That does not lend itself easily to having independent VCs in the project and what if users want to retain the shared existence, i.e. what is available today, and/or mix and match!

@migo33

This way you always have the master files even if you decide to remove the image from the project. This is what happened to me. I deleted photos from my project thinking they are still in the original folder.

Now you have me really confused!!

While you have two paths to the data only the directory “path” is a “destructive” path, at least on DxPL(Win)!!

The original directory:-

The Project:-

The Project after the mass delete, i.e. an empty Project:-

But a full directory is still present:-

@platypus is this different on the Mac and @migo33 is that what you meant by the deletion operation and by your statement, because your statement seems to imply (to me at least) that when you delete from the project the other (in fact the only real) copy will also be deleted!?

Update:-

You can add VCs to a project in DxPL(Win) but they will also appear in the original directory view and be accessible in both places. This is what the database looks like after I

1. saved the database
2. loaded a "blank database
3. Navigated to the directory with the huge number of VCs
4. Created a project
5. Deleted all but one of the VCs with the project selected!

The DxPL view:-

The ‘Sources’ structure which holds the [M]aster (original images) details:-

Please note all images are taken from DxPL(Win)db @platypus it would be good to see the structures used for the DxPL(Mac)db!

The ‘Items’ structure, one entry for every copy held in the database:-

The first entry accessed by the index is the [M]aster

The ‘Projects’ structure:-

The ‘ProjectItems’ structure which is “just” references back to ‘Items’:-

@migo33 essentially there is very little in the ‘Project’ structure except one entry containing the name of the project and its ‘Id’ and another which relates that ‘Id’ to a set of 'ItemId’s, i.e. effectively pointing to the entries in the ‘Items’ structure, there is absolutely no data held in the Projects structure.

Any management logic is in the code and on Win 10 deletion of project “entries” (i.e. “pointers”) has no impact on the original data (according to my tests), you just lose some or all of your ‘ProjectItems’ entries, with no “damage” to the original data.

To implement an “independent” existence of customizations within a project then a new entry would have to be made in ‘Sources’ which could/would have new entries in ‘Items’.

Avoiding a major change to the database the change might stand some chance of being implemented e.g. add an ‘As new’ option to the ‘Create project from current selection’ and ‘Add current selection to project’ which would result in a new image or images being created, either in the same directory but given - or in a separate directory - or …

The issue is that currently ‘Projects’ will not survive a database clear-out and a reload could return to a state that ‘ProjectId’ is re-used and the code would need to be able to handle potential duplicate clashes with re-used ‘ProjectId’ values.

This isn’t rocket science but do you really need this capability or are you looking for a solution to the “problem” that deleting from projects appears to delete from the main directory!?

[migo33]

Thanks @BHAYT ,
I can confirm that when deleting/ removing a Project image it does not remove the original source image. It was my mistake. however, I do think it will be great to have an option to create a VC for project images. this way the source file will not be affected.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@migo33

I can confirm that when deleting/ removing a Project image it does not remove the original source image. It was my mistake. however, I do think it will be great to have an option to create a VC for project images. this way the source file will not be affected.

@migo33 Thank you for the update.

With respect to VCs for the project the problem is that the current database structure simply wouldn’t support that, effectively projects “share” the VCs (and the [M]aster) with the normal directory centric processing of DxPL.

To achieve what you want, useful though it would be, entries in the database would need to be created that are not shared with the directory structure and I think that would need some changes to the database and also to the processing logic?

You would need entries in ‘Items’ that are marked as 'P’roject that could then be excluded from normal directory processing!

But while ‘P’ might designate a ‘Project’ only VC would those also sit alongside what we have right now, i.e. [M]aster and VCs effectively shared between the Project view and the Directory view?

Actually if DxPL allowed a VC to be created in a project and assigned as 'P’roject only, and the Directory view coding was changed to ignore 'P’roject VCs then I believe it could work!

For “safety” the 'P’roject entries would need to be exclusive to one project, I believe to avoid clashes over which project had the “rights” to delete the VC.

It isn’t really that difficult after all, I think!

@migo33

this way the source file will not be affected.

But I am not sure what you mean by this? It is always possible to have [M]aster, VC[1], VC[2], VC[3] and VC[4], with VC[1] and VC[2} also assigned to a Project and VC[3] and VC[4] assigned to another Project.

If the Projects are used to “manage” the editing workflow then the relevant updates can be done via the projects, the only disadvantage with the current scheme is that through the Directory View all the edits will be visible!? If Projects are used to compartmentalise edits does it really matter that they are also visible outside the Project!?

The above scheme that I proposed would (fully) isolate edits to within Projects and associated Project VCs but is what I have suggested here workable because it is available without any changes and my ‘P’ “idea” has not been scrutinised to ensure it doesn’t cause more damage than good!?

Regards

Bryan

[platypus (Canon & Mac (Intel and M1))]

@migo33

I do think it will be great to have an option to create a VC for project images. this way the source file will not be affected.

Using VCs in a project opens up a few possibilities, and we can already do it by creating VC(s) first, before we put them in the respective project(s).

Other than hat, a RAW source file is never affected by DPL because of its non-destructive nature.

[migo33]

@BHAYT

But while ‘P’ might designate a ‘Project’ only VC would those also sit alongside what we have right now, i.e. [M]aster and VCs effectively shared between the Project view and the Directory view?

@platypus

Using VCs in a project opens up a few possibilities, and we can already do it by creating VC(s) first, before we put them in the respective project(s).

Other than hat, a RAW source file is never affected by DPL because of its non-destructive nature.

Thanks guys.
Your suggestions are valid and a good workaround. The reason I suggest an ‘automatic’ VC when creating a project is for a far quicker and less risk workflow. A scenario can look like this:

1. Photos from a photo-shoot are uploaded to PC/ MAC.
2. Photos are marked for future work (keep/ delete, convert to jpeg, star rating etc)
3. User selects photos to add to a dedicated project in order to batch process!
4. VC are created in Project folder.
5. User batch process all photos (preset, black and white, white balance etc.)
6. User shares/ sends project photos to client, print, social media etc (as one batch).
7. Project can be archived, deleted etc. keeping the source files intact.

In this scenario there is no need to create VC first as it adds more photos to sort later as each VC will also need to be marked (star rating, label, colour etc). making the process longer and riskier. This scenario if really for large amount of photos, usually after a professional event…

Generally speaking PL is not the greatest when it comes to large DAM so maybe I need to put PL in its right place and not expect it to be something that it’s not.

[platypus (Canon & Mac (Intel and M1))]

DPL has some asset management capabilities, because of limited search and database health functionality, the long term usability is limited though.

Creating virtual copies manually in step 4 is a workaround too, and there is no need to rate, select and keyword each VC again, but the workflow feels clumsy anyway.

When I create VCs in Lightroom, the new copies are selected automatically and can be bulk moved to a collection, which improves the procedure greatly. Nevertheless, I usually add a colour label to each “generation” of VCs and filter by label instead of using collections.

[asvensson]

Proper license management would be high on my list: being able to activate and deactivate a PL installation without having to contact Customer Support and debate the issue with them, which I’ve had to do on more than one occasion.

DxO seems surprisingly reluctant to let you move an activation at all. In one case they even wanted me to demonstrate that PL was no longer installed on a computer after I told them that the disk had failed, and even after they understood that they were less than helpful. The fact that disk images makes any such demonstration pointless was apparently lost on them.

It’s just amateurish to have to contact a person during working hours to ask them if you could please move an activation to another computer, and then for them to question it.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@migo33 To be honest when I started with the PL5 Beta testing I was wondering why the interest in Keywords and the separation between keywords in the greater “world” and those that might be applied and used only within DxPL.

One scenario that I had envisaged for such a “split” was the definition of “containers” for the processing/progressing of a clients work within DxPL using keywords that would not be “shared” with the client, i.e. they would exist only within the domain of DxPL.

This has one “flaw” in that such keywords would be “shared” with the client when a JPG etc. is exported! The ‘Export to Disk’ can inhibit the inclusion of ‘Keywords’ and that selection or rather un-selection can be defined in an export preset but that would then exclude any keywords that came from the image metadata!

But the IPTC metadata might be a better source for such communication so keywords could be used internally for “client” and “project”/“progress” management and the IPTC for labelling the images and communicating with the client.

As @platypus has stated the original images are safe but with one caveat, currently if you ‘Remove’ a [M]aster DxPL reaches outside its domain and deletes not only the contents of its database with respect to that image and the DOP but also the image itself.

I personally object to the combining of the two functions into one command!

Although the following creates issues with respect to re-discovery I believe there should be two separate commands

1. ‘Remove from database’ or ‘Remove all edits’ which will do that including removing the (current) DOP
2. ‘Remove from Disk’ which will perform the current operation
   or something like the above

@platypus

DPL has some asset management capabilities, because of limited search and database health functionality, the long term usability is limited though.

The search is certainly limited but not necessarily too limited for the scenario we are looking at here!

As for the asset management capabilities Lightroom has more commands for managing the database, and you can certainly create a new Catalog at any time fortunately - of all the products I have “played” with while testing DxPL the only one that I needed that facility was Lightroom when a Catalog became corrupted, with a handful of images in it!? In truth the database management facilities are better and could easily be improved in DxPL!

@asvensson

It’s just amateurish to have to contact a person during working hours to ask them if you could please move an activation to another computer, and then for them to question it.

@asvensson it should be an unnecessary experience, licences should be available online to be activated and de-activated at will, what does it matter if I have the product installed on a number of machines as long as I stay within my allotted licence limit. It might be good if DxO offered additional seats at a nominal cost, I remember the days when Skylum offered 5 seats then went down to 1 as standard because they said photographers had indicated they didn’t need more than that!?

@migo33

Generally speaking PL is not the greatest when it comes to large DAM so maybe I need to put PL in its right place and not expect it to be something that it’s not.

@migo33 is this from personal experience or from what you have read in the forum posts?

In my experience there is nothing inherently wrong with the database! It is SQLite like most of the products with databases except ACDSee which uses some variant of DBase I believe.

FastRawViewer takes the data from the image but doesn’t do anything except ‘Labels’ and ‘Rating’ (and ‘Rotation’/‘Orientation’) and Photo Mechanic handles all the metadata without a database except with the Plus version which introduces DAM functions using a database.

The DxPL db is probably one of the simpler databases and I haven’t any experience of large volumes other than my ‘Bulk Test’ data of 11,000+ images which takes some time to “swallow”.

[migo33]

Thanks @asvensson, please add this to the feature topic. I agree, there needs to be an easy activation toggle option in 2022 (actually way before 2022…)

[asvensson]

I don’t know if there’s a previous feature request on this or not (haven’t yet searched), but if not then I can write one. DxO is the only company I deal with where this is an issue, but I find it an increasingly irritating one.