Hi
Just in early times with PL 3 on Windows 10 I have found a couple of peculiarities.
When I work on an image and chose to Export (to disk or application) for som reason PL3 creates a TIF file WITHIN PL3 (the same library and thus in the filmstrip) , a file with the character string _DxO suffixed to the original name and the same timestamp as the original file, not from the .dop file with the actual edits. Why would PL3 do that ?? An export is expected to add something to the outside world, not within PL3. I further found than when first exporting to an application, and then further editing in PL3 and a new export to the same application, the first of the generated files are exported again., not he new one with further edits. Very weird.
Regards Johannes Elkjaer Madsen
Johanes
Read this for in first place.
Table 1 in
http://tuto.dxo.free.fr/EN/Efficacite/Efficiency.html#C10_Exporter_les_photos
helaas is het waar 
Pascal
I am not sure what I should get from the info in the Efficiency document. My problem is not where the exported file (in Export to disk) ends up. It’s where it should be.
My problem is why the exported file ALSO is in PL3 - especially when Exporting to application.
Which by the way is QImage Ultimate (trial version). I don’t think this is a documented feature, but it works (apart from the surplus TIF file in PL3).
Regards Johannes Elkjaer Madsen
When you export to an application, PhotoLab automatically creates a TIFF file (as you noticed) to export to the application. It doesn’t export the source file, because the source is unchanged. All the changes are in a .dop sidecar file.
I don’t know why you would see the extra file if you export to disk, unless you have specified in the export options that the file should be created in that way.
I fully understand that PL3 exports a TIF - both to disk and application. I told it to do so in the Export preferences.
I still does not understand why any export from PL3 will change things (the number of files) within PL3, and thus clutter my file system with large TIF files I have no use of. Those exported to disk is placed in my custom folder as they should be, and those exported to application is no longer any business for PL3, but the responsibility of the receiving application.
Regards Johannes Elkjaer Madsen
Sorry, I’m trying to understand what it is you are concerned about and respond appropriately. Thank you for clarifying.
The large TIFF file created upon export takes up space in your filesystem (it’s an actual file that exists apart from other files) and is visible to PhotoLab because it’s a file type that PhotoLab can load. Other applications can load and modify the file and PhotoLab will then be able to load it with the changes without losing the original data. Of course, if you don’t want to keep working with that file, or as you noted want to make changes to the original data and export again, then it’s up to you to delete what PhotoLab exported in the first place or find a way to hide it from PhotoLab’s image browser. That’s the workflow that seems to be intended by DxO. It’s primitive for now, but perhaps it will be more configurable in the future. What is the behavior you would rather see?
Hello @jemadsen,
- Well, PhotoLab works with real folders (not collections like LR for example) and when you export to Disk -> by default it is exported to the current folder (be aware we do not overwrite the originals ever). If you want your exported images to be stored in the other folder, just set it in this window:
And we are working on the same option (select destination folder) for other exports.
Regards,
Svetlana G.
Hi
I know how my export to disk is set up: I export to a custom destination with a custom name. And it works fine. Standard and TIFF export is set the same way in my setup.
What doesn’t work is that I also end up with this TIFF file, now suffixed with _Dxo in stead of my specified _QImage, in the same folder as the original (what I call within DxO), although the timestamp is not taken at the time of export, nor from the .DOP file containing the edits in the TIFF file, but from the original RAW file.
I completely miss any understanding of why this extra export to within DxO is happening, what the reasoning behind it is.
The same when exporting to an application, why on earth would DxO also export to itself (as in the folder with the RAW file).
Regards Johannes Elkjaer Madsen
Hi Johannes. Looking at your export screen i notice that you have BOTH your standard export(which is a 16 bit TIFF) AND also 16 bit TIFF checked. I believe that DXOPL interprets this as your requesting two 16 bit TIFFs. Why they would go into different folders though is a mystery.
Hi Mark
Just minutes ago I discovered the same. I got an error which I didn’t get yesterday (duplicate file) that lead me to uncheck the Standard export setting so only the TIFF is active. And this makes DxO export ALMOST as expected: a neet TIF file is placed and named where and how I want it, BUT it is timestamped with that of the original RAW file. I don’t think that is entirely correct. Either the actual time from the export or the timestamp from any available .DOP file would be more correct.
Regards Johannes Elkjaer Madsen
Hi again
Except of course when I subsequently do an Export to application DxO PL3 insists upon saving a TIFF file in the same folder as the exported RAW. This export just asks for application as well as action and quality - no mentioning of disk locations or otherwise.
Very weird.
Regards Johannes Elkjaer Madsen
Yes this is known deficiency.
PL wants to rebuild the interface image each time and all that in the same folder.
This should soon improve.
Pascal
Hi Johannes,
I see that Qimage Ultimate is a print manager - - so, that’s probably influencing your puzzlement over why you end up with (from your perspective) duplicate TIFFs.
Mostly, tho, users are invoking a different image “manipulation” application (such as, say, Nik Color Efex Pro) - in which case, it does make very good sense for a separate TIFF file to be created - - as that’s then the version of the image that’s updated by Nik CEP (in this example).
I suggest you’re perhaps wasting a step in your workflow (?) - - If you’re using the Export to Disk feature, as I see above that you are - then why not simply invoke Qimage Ultimate in stand-alone mode and point it at your export folder (which seems to be C:\Users\johan\Pictures\Qimage … )
Regards, John M
PS. You used the term “exported RAW” above (perhaps it was a typo?) - - Just to be clear tho, the RAW file is NOT exported.
Ref. Pascal: I shall wait for the solution in a future PL3 update.
Ref. John M: What I am working on when I click Export is a RAW file - which DxO then - as of my specification converts to a 16 bit TIFF.
I will use Export to disk to fill up images in QImage which is to be printed in the same size on the same paper, so that I just start QImage printing, and it will empty my input queue.
I will use Export to application to print one image at a time when my task is to print images at different sizes and/or on different papers - that is print one image at a time.
Regards Johannes Elkjaer Madsen
I mean a major release.
At least PhotoLab 4 
Pascal
I guess I’ll wait anyway. Just miss it more and more times.
Regards Johannes Elkjaer Madsen
OK - So, it’s a TIFF that’s exported - from a RAW file.
To avoid the problem (from your perspective) of a “duplicated” TIFF file ending up in the folder containing your RAW files - rather than Export to application, why not use the same Export to disk approach that you describe as follows …
… but, to a different destination path. Would that address your concern ?
John M
Not really. My main concern is that PL3 clutters my file system with TIFF files that is of no use. My point is very simple and one dimensional: no export should change anything in the application you export from, only where you export to. In this context I define the file sytem containing my RAW files (and .DOPs) as within PL3.
I also bought the NIK collection but has concentrated on the PL3 learning curve. But a little testing of the installation quickly proved to me that this works even worse, with TIFF files galore both before and after each activation of one of the applications. Using Sharpener alone would then produce 3 TIFFS from PL3 for activating Sharpen Raw, Sharpen Monitor and Sharpen Output. Plus of course 3 more TIFFS from the Save in the module. At least 4 of these TIFFS are useless leaving only the 2 saved from the Monitor and Output roundtrips with value. This is close to intolerable.
I sincerely hope that this will be addressed as of Pascals promise earlier in this thread.
I was proposing a potential workaround, Johannes, because I very much doubt anything will be done about this anytime soon - - because (tho I do understand it’s a “problem” from your perspective) , it’s not seen as an important issue by the wider group of PL users (at least, not that I’ve seen mentioned on this forum).
John M
I will live with it for now, after the Export to disk situation was fixed and only one extraneous file is created when Exporting to application.
I’m not sure what happens when I get to work with the Nik collection, though.
Regards Johannes Elkjaer Madsen