Having some issues with work flow of Focus Stacking. I’m using DXO to make adjustments and Affinity to do the stacking. Can you bounce back and forth? If so, what settings to use and what file format to send back to DXO? Not working for me. I can get the focus stacking done in Affinity but can’t edit that imagine in DXO, at least can’t do Deep Prime.
That’s probably because you’re stacking the various images in Affinity first - and then sending the stacked result to PL for further processing ? … in which case the result is no longer a RAW file(s) - and Deep PRIME works only on RAWs.
That’s not the best workflow, in any case … You’ll get much better results by processing the RAWs in PL - and passing the results to Affinity for stacking. Here’s how I do it;
Select ALL the RAW files from your bracketed-set in PhotoLab (so that any correction changes you make will apply equally to ALL of them) … Be sure to set Deep PRIME NR on.
Export to disk with the following options: Do not enable resizing - set ICC Profile = ProPhotoRGB … this will provide Affinity with the best basis to work with.
Open Affinity in stand-alone mode (because it’s not possible - AFAIK - to send multiple images to another app. from PL) - and use Affinity’s UI to select and merge the component images.
Export the result from Affinity - and open it in PL for any tidying up you may need to do to it.
Process your raw files with PL (optical corrections and noise reduction only) and export as 16-bit tif files to AP. After stacking save as 16-bit tif and edit on PL if you like or simply continue editing in AP.
If you don’t like tif files then use linear dng files but I find them much bigger than tif with no benefit.
Thanks guys, that should be a BIG help. You can alway depend on the Aussies to come to the rescue.
Exactly what I was going to say. I take the same approach for HDR processing in Aurora HDR.
(And as a Kiwi, I felt I had to speak up )
And, as an English woman living in France, can I just add to the international accord?
Your focus merge has some flaws @Losthwy Part of the towel in foreground would have needed more images in shorter stacking steps.
That’s neither Affinity’s nor PL’s fault, but the concept of focus stacking has some traps. I still stumble into them as it’s impossible to ckeck the result when out in the field (without laptop). It might be (not 100% sure) helpful, but saving a RAW and JPG eneables you to test-run a stacking process with JPGs. If they work out without some bokeh glitches, double contours, phantom glow and whatever might happen, you still can work on your RAW. And if there are glitches you can still decide if it’s worth the effort to deepdive into editing.
And contrary on the idea of 16 bit TIF or DNG to waste energy on longer calculations with no better outcome, I prefer exporting well-edited RAWs to JPGs and put that either in Affinity Photo or focus-stacker. So far I haven’t found a direct comparison between TIF/DNG sources versus JPG exports in which the TIF version was much or at all better.
I render 1500 - 2000 focus bracketed shots per session more or less as described at the tail of this thread. Had a question. I will bring the RAWs onto the screen and then Export as jpgs to the file I will use for my focus stacking (Helicon). I note that the thumbs on my PL screen have a rotating white circle which spins and disappears, process moving upper left to lower right on the screen. Presumably, this would be the first stages of Preset modifications. And, the denoising is occurring in the export phase - which takes longer for each image. Question is: the preliminary Preset change with the spinning circle stops as soon as the process moves off the bottom of my screen. I have to scroll down to expose more images to get it going. Kind of a pain. Can I assume that any image which has not yet had the non-denoising Preset done at the time it is exported will have that done at the time of export?
@dxopl4 Longish posts for a simple answer - yes it is fine because I believe that to be the correct answer and also because I tested it!
I have just loaded a Bulk test of 1,000 images from HDD (so a relatively slow process).
The first phase of processing is for DxPL(Win) to read all the images and create the thumbnails and at that stage the thumbnails will not have been rendered using either the DOP, if one exists, or the initial loading preset (or so I believe).
The next stage is to go through and render all the thumbnails but selecting any image during either stage will go into a render phase for the selected image (which it always does) before offering that image for ‘Customization’.
I then exported the images as JPGs (100%) and a long, slow process started (even without any Noise reduction) because of the concurrent thumbnail rendering and the image rendering and exporting taking place at the same time (I believe).
DOPs are also being generated because the export is considered a database change, the export name is stored in the database and the DOP (which is essentially a copy of the database entry, actually entries because the details are held in more than one database table).
I cancelled the export, life is too short, I could have cancelled it sooner but …!
Waited until DxO processing activity seemed to subside. In fact I encountered this where DxPL is going through and adding the processed “tick” to the exported images and the swirl icon is still present and the thumbnail has not been rendered because I have not tried to view it before!
I then checked that the first 537 (should have been 534) had no swirls, selected them and started a new export, here is a comparison between the output files
They are not truly identical because the dates are different
Short version, cleaned up by unnecessary subordinate clauses and screenshots without additional benefit. What @BHAYT tries to say and wrap in layers with less or non-important information:
- I just ran a mass test with 1,000 images.
- DxO PL reads the images and creates the previews
- Export as JPG with 100% size. In addition to the JPGs, DOP files are also created, because the export requires the RAWs to be rendered. The applied settings are saved in the respective DOP.
I don’t see what this procedure has to do with “Work flow issues between Affinity (focus stacking) and DXO”
Apparently life is long enough to tell lengthy stories without…, no, I don’t want to judge aagin, you read the comments about your posts already often enough and are apparently critic-resistant enough.
the answer was “Yes it’s fine” but that answer is not given by a member of DxO who designed the product or can inspect the code.
While I consider that my “Yes it is fine” says it all, the snapshots and description show that I have performed due diligence and “proven” my statement to the best of my ability.
To be exact:
Open the directory with the 1,500 - 2,000 images and wait until the count reaches the number of images.
A Ctrl A (or Mac equivalent) will then select all images, if done before all have been scanned the Ctrl A will only encompass the entries read at that point!
Apply the preset to all selected images or use the default preset set up in ‘Preferences’.
Then export all the selected images, effectively what I did with my 1,000 Bulk test which had no DOPs before starting the test and the export was started as soon as the count reached 1,000.
Thank you for clarification. @BHAYT I don’t want to upset you, it’s just to make you aware of what you sometimes do when doing your really valuable testing and diving into some PL problems: You create a picture story about your diving, how you “found out the colour of a certain fish” and are hiding the answer “yellow with green spots behind the eye region” in a massive “first snorkle, then scuba and after that diving bell” story with lots of images. The longer a story is, the more satisfaction a reader is expecting as it’s consuming his / her lifetime.
@JoJu in this case I deliberately placed the summary at the beginning but what I “failed” to do was make the post even longer with my “To be exact” response, i.e. an exact script of what needs to be done.
The second “mistake” was to use the HDD I have moved all my tests data to, an old 2TB drive which is connected to the motherboard SATA but seems incredibly slow!
So I repeated the test having copied the data to an NVME, not a mega fast NVME and not connected to the motherboard, I cannot afford to lose SATA ports, but installed via a PCie board plugged into an unused Graphics card slot, when the timings improved somewhat.
In all tests the exports were going back to the same drive as the input images, but to a separate subfolder.
Now you have the description of the “snorkel” I was using and the new improved “snorkel” I then used and how much better it was for my “breathing”!
It’s not a mistake per se @BHAYT I also tend to lengthy posts as I’m writing along the flow of my thoughts, sidethoughts, before and after thoughts and often fail to cut it in small perception portions. That’s - I guess - because like you, I’m also curious about the “why this result?” instead only the “result”. I know how easy it is to leave the whole thought protocol as it is and leave th extraction of the result to the readers.
But they were no part of my process and maybe only interested in the result. I should leave the part “ask, if you want to know why” more often to them.
Manyy thanks for the comprehensive treatment of my inquiry.
I conclude the “swirl” process indicates the first portion of the Preset changes (as the thumbs change a bit, as each is completed) is being done. This process stops as soon as the swirls reach the bottom of the screen. To continue the swirl process, one must scroll down to reveal more images on screen.
Now, Exporting starts from the top left screen again with a different processing timer concluding with the check mark. This can proceed to images beyond the bottom of the screen to the last selected image. I am assuming, for images not going thru the swirl process, the Preset preliminary treatment is done at the time of export, when the de-noising is done.
@dxopl4 Summary:- don’t ignore DxPL counting but do ignore DxPL swirling, when the counting is done exporting can commence if everything else (edits etc.) is ready!
As far as I can tell during these and previous tests I have done, the process is
- Read all the images (I don’t think the “render” swirl is present during this)
- When all images have been read (and entries created in the database, I believe) the swirling begins as DxPL starts to create rendered (according to the DOP or initial preset) thumbnails which go into the cache I believe.
There is evidence from the tests I did for your post that DxPL doesn’t actually complete the rendering process as a matter or any urgency, i.e. I moved around my 1,000 images and still found some where the swirl (two lizards chasing each other) was present and the rendered thumbnail then “popped up” for the thumbnails in view.
Regardless of the state of the thumbnail the image will always be rendered for the large display and this will happen even when you just navigate away and then back.
Exporting can be started at any time and in your case it is wise to wait until all images have been located (otherwise the Ctrl A will pick up only the images that have been loaded at that point in time) and the image count stops increasing.
My test images are deliberately numbered for test purposes so that relative positioning within the directory can be seen in the image name.
Then Ctrl A to select all images and
- apply a preset to all the images (selected)
- or use the edits already contained in the DOPs
- or use the initial preset
- or select images and edit as required
and then just export all the images.
This export can be started before any swirling begins or before it stops but after the counting is completed if you are going to export all images en masse. The export process will apply the necessary edits as part of the export process, followed by the application of the chosen noise reduction (if any) to create the 1,000 - 1,500 images you require.
My tests followed the procedure I outlined above in
and that should work for you.
or you are looking at the images during the loading stage before any “rendering” has started, when the image count should be increasing.
However, exporting is not constrained by thumbnail rendering (indicated by swirling) or so I believe.
The reason for the way I tested was to create exported images after the initial “discovery”/“import” process but during the thumbnail rendering stage, then wait, check that all swirling has finished and create the exported images again!
If there was any difference at that point it would indicate I had undertaken the export process too soon. The only difference I detected was with a file timestamp and a file timestamp embedded in the metadata of the file.
Lots of good info, thanks.