@migo33
I’ve just tested in PL5, select files in filmstrip, create VCs by Cmd/Ctrl+D, VCs created are automatically selected, right clic on one VC to get the menu in which I select Create a projet from the selection, and the project is created and opened directly.
That’s it.
1 Like
I want it to do batch processing like DXO PureRAW for some corrections. NOT Batch Copy and Paste… actual batch processing that analyzes the images individually and applies a series of adjustments based on the individual photos. As a volume shooter… I don’t have time to do that individually to 10,000 images that need to be done in 2-5 working days from an event.
Then… after a baseline of automatic adjustments are made… if someone orders a image based on that I will then take an individual look at an edit for it as required.
Turns out there’s a feature request on license management from almost three years ago:
1 Like
Just from experience and using many tools over the past 25 years. I really don’t care about the type of DB an app is using nor should PL users care. I am not expecting PL to have DAM capabilities but it will be great to at least have an Import option.
What would be the purpose of an import option? What would it allow you to do that you can’t do now? One of the reasons I ditched Lightroom was the extremely annoying import requirement.
Mark
2 Likes
DAM starts from a proper import process. Naming, sorting, adding presets, keywords, copyrights and location removes tons of work later on.
I can do most of those types of things on a folder by folder basis. I don’t need to do it while importing and I would certainly not want to have an import as a requirement like LightRoom. If it was an option rather then a requirement I might support it , but I would be unlikely to ever use it.
Mark
3 Likes
It’s not a requirement in Lightroom either. You can copy photos to a folder and sync the folder later. Everyone has a different process.
Exactly. One of the (original) reasons I started with PL is that it does NOT require an import process.
John M
5 Likes
Yes, but this is so sluggish to use it’s unusable. My Laptop is not an old one either (Core i7, SSD etc), everything else is pretty speedy.
I will definitely skip the update to PhotoLab 6. Even if it costs 1 euro.
What would make me upgrade to PhotoLab 7 in a year could be:
- User-selectable working color space (including sRGB).
- Comfortable color balance (not white balance).
- Speed up editing by using AI.
- Fixed the problem with the missing color profile when exporting to sRGB.
- Improved control points - RGB controls that work additively after white balance.
The principle “what I see on the screen is the exported file” is a red line. If it is broken PhotoLab becomes useless to me.
You mean that the color profile isn’t set correctly in exported images on the Mac version? That has been fixed about a month
Core i7 itself doesn’t say that much, as there are 13 generations of Intel Core i7 processors. Heat often is a problem with laptops which results in throttling. But PL6 indeed is quite heavy on resources
You’re right of course, and it’s not the latest but I didn’t want to get into too much spec talk.* Most of PL5 & 6 operations are pretty quick when I’m using it and others are a bit slow but satisfactory, but I tried the “rotate while cropping” and it was the last time I will ever try that! I can’t see how anyone could think it useable. I was genuinely surprised at the way it worked.
* 10th Generation Core i7-10875H (16MB Cache, 5.1 GHz, 8 cores), GeForce RTX 2060 6GB GDDR6 + Max-Q
sRGB profile is still not attached when selecting sRGB in the export menu. Last tested on photolab 5.5 and Windows. I am specifically referring to the sRGB!
1 Like
when I noticed (that is quite some time ago now – long before PL6 !) I exported with the custom profile
to overcome
while in PL6.0.1 Build 33 it is
@migo33 I also like DxPL for not having an explicit import function, having played with software that does while testing DxPL’s keyword handling in particular. But it does have an “implicit” import function which is used whenever a user navigates to a directory which is new (to DxPL) or contains new elements.
But the only edit template that can be applied is the one and only template defined in the ‘Preferences’ and that contains image editing functions only, i.e. no metadata handling whatsoever.
So now I understand what DAM functions you are referring to or rather what element of DAM functions you are referring to!
For those of us who value the “simplicity” and “freedom” of the implicit import process what is currently on offer is fine and we can select images to apply metadata updates to at our leisure, albeit the metadata ‘Templates’ on offer in Photo Mechanics are nowhere to be seen! The best that is possible is to make changes to an image and then copy it to other images, as appropriate!?
I don’t know if it will be possible for DxPL to ever have the assignment of metadata to an image on import because implicit import on discovery and explicit import with rules applied are difficult to reconcile.
But it would be possible to “not” import on the “discovery” of a new (to DxPL) directory and prompt for import or not, this would address the issue raised by some users of wasting space by adding a directory to the database every time a directory is “discovered”!
To that simple prompt could then be added an “import” function where an edit preset and a metadata template (preset), the metadata preset is arguably required anyway but doesn’t currently exist, could be added @Musashi at a (slightly) later stage!?
I don’t think that DxO envisaged DxPL to be a competitor for software with more advanced DAM functions, and definitely not a competitor for those that are “just” a DAM, but rather a product that could co-exist with those products.
However, adding metadata templates to a system that already handles edit presets is not “rocket” science, allowing the current discovery process to be interrupted to
-
Prevent database “clutter”, except someone (me) would suggest that they want the ability to wander around a directory without automatically importing the data and then suggest that they might want to be able to selectively import data as and when the “mood” took them!
-
To provide the ability to assign an edit template to the discovery (“import”) process from the introduction of that facility (the current process is useful but totally inadequate)
-
To add the ability to assign a metadata template to the discovery process, when they have been added to the product, for general use, in the same way as edit presets!
PS:-
Rather than changing the flow for all users add an option to enable the current automatic discovery (the default) or allow for selective discovery (maintain the existing options but allow for the introduction of new facilities/work flow etc…)
Implicit import has one major drawback in combination with DPL’s eagerness to instantly start calculating previews. This sucks up resources and DPL is quite a slug then… Most other apps handle import and preview rendering more intelligently.
The absence of reference to the sRGB profile in the exports is neither a bug nor a lack: it is the normal behavior, in accordance with the original standard (W3C/ICC).
The sRGB profile being the basic profile, any software capable of displaying an image must have this profile internally and use it… if it does not find any indication of another profile.
Whether the file to be displayed is tagged sRGB or there is nothing, it will always be displayed with sRGB. There is absolutely nothing to fear!
I use this way from PhotoLab2. But it is not good for new users who don’t have enough knowledge of color management. Judging by the forum posts few people understand color management.
Which sRGB profile? Nikon, Canon or Adobe? The truth is that no one is doing things right with regard to sRGB, because the “mistake” is small and unnoticeable. Now that you have a wide working color space, the poor color management in photolab starts to become visible. But instead of realizing first-class color management in PhotoLab, patches are still being made…