Stacking photos

I use DxO together with Mylio. If I send raw photos to DxO to edit them there, I have to export a jpg file back to the original folder to make the edits visible in Mylio. Wouldn`t it be nice to have a stacking feature like in photo supreme or Imatch? This would give a better view in Mylio. In Imatch I can choose to set the jpg on top of the stack.

Could this be a great feature? Or do you have other smart tips on how to organize several versions of a photo?

1 Like

This is actually already a limited stacking feature available in Mylio that may help you if you name the files carefully.

If you save the DxO files in the exact same folder as the Original, with the exact same filename and “_display” (no quotes) appended, it will stack it into an existing Mylio photo.

Ex: If you have a file named DSC1234.CR2, perform your edits in DxO and save a jpeg as DSC1234_display.jpg to the exact same folder.

Thanks for your answer. When I send a raw photo named DSC1234.CR2 to DxO, make the edits and export as a jpg, the name is DSC1234_DxO.jpg. Then the jpg show up next to (not on top like it should) the CR2 in Mylio. Is this wrong way?

Yes, it has to be exactly DSC1234_display.jpg for it to stack. The literal suffix of “_display” (in lower case) is important - it can’t be something else like “_DxO” unfortunately - otherwise it won’t stack.

Thank you! I will try it out:)

Very good! But is this still a raw photo in Mylio? What happens if I go back to DxO and make some more edits to the same photo? Can I export the new edits and it will show up in Mylio?

There will still be a RAW photo (and even a RAW+JPG if your camera takes both) in Mylio that will continue to sync to all of your other devices, in addition to the new _display.jpg file. If you open the picture and go into the Edit pane, and switch between viewing the “Before” and “After”, you can view the original RAW vs. the updated _display image.

If you make additional edits in DxO and keep saving it as _display, Mylio should keep picking those changes up.

What you can’t do however is to edit the _display image further in Mylio, it will ask you to either discard the display image, or duplicate it to a new image.

This jpg-display-file, is it visible somewhere? Or is it not possible to unstack them in Mylio if we want?

Just an FYI: When you export from DxO in the export dialogue you can change the default _DXO suffix to _display and it will become the default for that export option.

When you have an individual image selected, you can temporarily switch between viewing the Display image vs. the Original by going into the Edit pane end clicking on the Before and After image.

You can’t however view them separately as ‘unstacked’ - Mylio will show the Display image everywhere else.

interessting details :slight_smile:
but I think a real stacking option is the better way.

I’m also very interessted on it - and I use also DXO :wink:

Greetings Uwe

Just an FYI, I’ve gotten the “_display” stacking to work nicely with CaptureOne Pro as well. Works just like DXO, you just need a process recipe spec’d to append “_display” to the file name and put it in the “image location” and you’re done.

Thank you for the details about how to configure Capture One to export _display images back to Mylio. I’m experimenting with both Mylio and Capture One at the same time.

Adam, you may know this but just in case … with C1, make sure you use it in Sessions mode. Works nicely (e.g., no “import” process into a C1 catalog necessary). To me, Mylio as a “catalog of Sessions” would be ideal.

The limitation I see with C1(Sessions) <–> Mylio at the moment is that Mylio doesn’t sync the “sidecar” files that C1 creates (in the “captureOne” folder it auto-generates ) to other Mylio destinations. For example the *.cop (preview) and *.cos (settings) files in particular would help if they synced . If it did, they you could see the C1 edits on a second machines and continue to edit an image started earlier on a different machine. Example, I do initial edits on a laptop in C1 then walk to my desktop and I could continue there in C1 and then save the “_display” file.

Note: I don’t think Mylko would have to sync all c1 sidecar files to make it all work. https://support.captureone.com/hc/en-us/articles/360002862137-Session-Sidecar-files

That said, if you do all your C1 editing on one machine, then it works pretty well.

Another option if Mylio would recognize it in the future, would be to save C1 files as “.EIP” files . These contain the raw and all the edits in one package. macOS (I’m not sure about Windows) can actually preview them natively too. So if Mylio recognized EIP as a kind of raw, then Mylio could possibly get the preview from the EIP the way macOS does and present it without the need for a “_display” file.

Regards,
PG

_display.jpg feature in indeed an excellent feature to render edited file. Mylio will take that file when exporting images for sharing.

One limitation of C1 I found is that it is unable to overwrite files in export phase. So if I make any adjustments and export again, C1 will create _display_1.jpg, _display_2.jpg etc and Mylio will not pick them up.

I created a support ticket with C1 and they admitted there is no way to setup export recipe to overwrite files. They created a feature request. Maybe they will address it quicker if they see more demand for it.

On the other side, it would be great if Mylio would have some sort of support for multiple variants of the same photo. Lightroom supports variants, Capture One support variants, so it would be nice if Mylio supported them too (multiple versions of the same photos with different rendering/crops/…).

I hadn’t gotten far enough to create a second _display file but you make a great point about C1 being unable to overwrite files on export. I think the _display functionality is sort of a bandaid at this moment in time and while not ideal, it helps.

I think what would be best is if Mylio tried to look for the .cop file in the /Captureone/Cache/Proxies folder and leverage it as the preview rather creating it’s own preview from the raw. If you use Sessions, each time you “open with” a raw image in Mylio (selecting C1 as editor), the C1 Session looks at the directory for the file in question and automatically generates previews for every image in its folder (C1 creates that /CaptureOne/ folder and its children if they don’t exist). Thus, the C1 aware previews are already there for the taking , so-to-speak.

As far as I can tell, (and I could be wrong, wouldn’t be the first time :slight_smile: ) Mylio would have to do two things to make C1 work a ton better with Mylio:

  1. Sync the /CaptureOne folder contents and C1 side car files (.cop, .comask etc). This would allow a user to move from one computer to another and continue editing in C1.
  2. Look for the .cop file (preview file) and if found, use it for the Mylio thumbnail/preview generation instead of the raw.

I think that’s it. That would eliminate the need for _display.jpg proxies.

Yes, like you said, I’d also add better support for variants. DXO has those too, DXO calls them “virtual copies”.

Regards,
PG

1 Like

Great suggestion! It is also lot more integrated with CaptureOne as every photo would be automatically rendered with C1, edited or not, and one does not need to worry about manual sync (export)…

I’ve asked several times for an option to overwrite existing files in process recipes but so far have been told that they don’t want to do it because it’s “destructive”.

It seems like a long shot to think Mylio would support .cop files directly but one can dream! In the meantime, I’ve adjusted my “burn a jpeg copy” process recipe to use _display files in the original’s folder.

1 Like

I got the same response initially. Then I told them of use case with Mylio and that I not expect to change existing default behavior, but to have a checkbox where I can explicitly select to overwrite existing files in the output directory.

I agree that .cop solution would be better and more seamless.

Sorry for reopening this thread. I am moving to Mylio from Lightroom where stacking was quite easy. As from what I understood, the jpg-file will need to be named XXX_display.
Is that still the case? And if so - ist there any possibility to mass process a library to identify the files with the same name and to add “_display” to their name?

Thank you for sharing your thoughts.