There is no support for HEIC at this time.
Mark
A highly welcome upgrade, particularly for the overdue evolution of the existing Prime NR. My first peeks at what DeepPrime does look promising indeed. Congrats to the team! 
2 Likes
I’ve never had a problem, whether PL is running or not. My software renames both the file and the DOP to match. As I understand it, the DOP has precedence, so I’m not sure there are any pitfalls.
I had already seen your write-up when I wrote my statement. I don’t see it as buying me anything over what I have in PL3, which is really simple: I have a custom workspace. Lesser used features or panels are collapsed. I can expand those when needed. When things get too cluttered, I just reset back to my default workspace.
If I were starting new with PL4, I might have choose a different approach, but it wouldn’t necessarily be a faster or better approach.
It sounds like your self-written rename utility is ensuring that {image+sidecar} combos are being renamed together (as a pair) and “instantaneously” … which is as it needs to be - but, which is not necessarily the case with, say, File Explorer.
John M
That’s been the case since PL1. Nobody here uses HEIC? Seriously it reduces file size buy half while maintaining image quality compared to jpg.
On the other hand, raw doubles or triples file size…
That depends on what you regard as a “normal” file size. In fact, RAW files are amazingly compact, considering how much information they contain. JPEG files have been compressed and often lose information that would have been in a RAW file. e.g. a JPEG file is usually 8 bit, which means it only contains 256 levels of each colour, whereas a modern RAW file is around 14 bits, containing 16384 levels of each colour, thus providing for much smoother tones and graduations. The really big hitter is the TIFF file at 16 bits but at a much larger file size.
1 Like
I don’t use HEIC, none of my cameras use HEIC and I have tonnes of storage space so size of file is not at all important to me. Compatibility with editing software is important to me and after hearing all the comments here about HEIC over the past week or so I won’t be moving to HEIC any time soon
1 Like
I hadn’t even heard of HEIC until I saw this. I see that right now the interest seems Apple-driven. Since I stay away from Apple products, it’s not surprising I haven’t heard a lot about it.
As a JPG replacement/alternative, it sound great. Anything that decreases files sizes and retains more image quality has to be a good thing—once everything gets updated to handle it. And most image-handling programs are already well set up to read dozens of file formats; one more shouldn’t be a problem.
But it’s not a RAW replacement at all. PL needs the RAW sensor data in order to do some of its magic. For instance, I believe that PRIME, DeepPRIME, and Lens Sharpening are all applied before or together with demosaicing.
PL handles JPGs and TIFFs with some feature reduction. I’m sure they’ll support HEIC if it becomes prevalent, but not before. And it should be a low-priority item. Right now, they don’t even support Canon’s sRAW and mRAW files, which are also not RAW files but are produced by cameras DxO supports.
2 Likes
Yes, both files need to be renamed if you don’t want to lose your changes.
File Explorer doesn’t automatically rename the pair, but one can manually rename both the RAW and DOP files using File Explorer. The renaming doesn’t have be “instantaneous”. Take as long as you like as long as PL isn’t running.
Renaming while PL is running might create some problems. If you haven’t modified the file you are renaming, you’re OK (there’s no DOP file). I did a little testing and sometimes PL gets a little confused and creates a second DOP file, but it does seem to retain all changes. It’s clearly relying on the database. I’m not sure what algorithm they are using, but it seems like this is a bug.
Congrats team DXO 
HEIC is better than JPEG like AAC is better than MP3 and h.264 is better than [whatever it replaced]. While Apple Music/iTunes has been AAC for years, the vast majority of consumer audio is MP3 because… habits.
In the video world h.264 and now h.265 are taking over. Video size is a much bigger problem than image or audio size, so it moves ahead.
The problem with File Explorer, when renaming multiple pairs of {image+sidecar} pairs, is that it does not necessarily rename them in the order you’re expecting … that is, not necessarily {image#1+sidecar#1}, then {image#2+sidecar#2}, etc … Instead, it may be renaming files in the order that they physically appear on the storage medium (unsorted), or whatever … the order cannot be guaranteed.
So, if PL is running when a rename is underway via File Explorer then there may be sufficient delay, between rename of image#1 and related sidecar#1, such that PL has time to detect a “new” image file that does not appear to have a related sidecar file … so, PL creates a new sidecar file to match it.
Your utility is obviously avoiding these pitfalls - - but I’m laying out these details for the benefit of others.
John M
Agreed. And although mentioned at various times in threads such as this, it seems that nobody has actually created a proposal to optionally turn off the database. Now there is one.
You can vote here: Provide the option to use PhotoLab without a database.
2 Likes
My utility program is not avoiding anything. Normally, in the rare case that I rename things while PL is running, it is usually after I’ve uploaded files, in which case I have no DOPs. When I do rename DOPs, I’m usually not running PL.
Your posts got me interested in checking to see what happens. Here’s my first test and what I found:
- I selected an image and customized it. A matching DOP file was created.
- I renamed the DOP file, then made a second change. A new DOP was created with all the changes. I found I had to wait a bit for this to happen, so it’s clear the changes go only into the database for a while and the DPO file update lags a bit. I’ll get back to this.
- I then renamed the image file. On my Windows system, PL picked up this change immediately. It also immediately found the matching DPO file and updated it.
I then had a left-over DPO file with the old name and a RAW/DPO file pair with the new name and the latest data. At that point, the left-over DPO could be deleted. An attempt to rename it would yield a message about a name conflict.
What if I had managed to rename the image before PL realized the DPO was missing? I don’t know. PL seems to pick up image name changes immediately, so I think it would then overwrite the renamed DPO with the same exact data. The only difference, then, would be the lack of a left-over DPO file.
I also tried reversing the rename order:
- I selected an image and customized it. A matching DOP file was created.
- I renamed the image file. I waited around for a while. No DOP file was created.
- Option 1: I changed the image. A new DOP file was created with all the changes (and the new name). The original DOP was again left over and can be deleted.
- Option 2: I renamed the DOP file to match before making any further changes. Further changes to the image went into the renamed DOP.
So, other than sometimes getting a left-over DOP, manual renames don’t seem to be a big problem, even while PL is running.
This is interesting. Does File Explorer have a batch rename facility I don’t know about?
This made me think of a third case: I rename a file that I am not currently working on. I tried it with one file and, again, the name change was detected immediately. A matching DOP was immediately created, so that was different. The original DOP became an instant left-over. However, if I then deleted the new one and renamed the original, it would make no difference. Both have the same data.
So far, I haven’t found a path that does anything worse than leave an extra deletable file lying around. I didn’t find any cases that lost data. Have you?
Yes, I have. That’s why I’ve learned to be cautious. But I’m not here for a long discussion - I’m just wanting others to understand the issues - as they don’t have the benefit of your rename utility.
John
You remain under the illusion that my rename utility magically makes me immune from renaming problems—I have no idea why.
You want others to “understand the issues”, yet I don’t see you providing any understanding—just a generic warning that I can’t confirm as being a problem, whether renaming by hand or by software,
If you’ve covered the problem in detail elsewhere, a link is fine. Or you could start a new post with the detailed explanation. I’m sure it would be useful to others and I agree that this is not the best place for this discussion.
OK, you’ve sucked me back in 
The reason I say that your utility is working well for you is that it’s obviously working optimally in the task of renaming {image+sidecar} files whilst PL is running … and I say “obviously” because if it was not then you would have experienced some issues by now.
I’m also guessing/assuming it works much like mine, in that it renames images in pairs of {image+sidecar} files (or, perhaps yours handles renaming of only one pair at at time? - which would further explain why you have not experienced any renaming problems whilst PL is running) - and it renames the sidecar/.dop file first, before its related image file. Following these “rules” will avoid renaming issues.
If you want to pursue this any further, send me a PM and I’ll be happy to discuss.
John M
I was so looking forward to using this version after beta testing it, but it appears I was deemed “not involved” even though I raised a couple of queries/issues and tested every release.
Ah well, back to what I know then. But congrats on getting it out to market.
I read all your posts and I suspect it was because none of your posts addressed any of the new features being tested for this release. In any case this public thread is not the appropriate location for this conversation.
Mark.