Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Export with the same name

Implemented

Comments

9 comments

  • Ian Leslie

    I agree this feature is needed. Many people here want to be able to create their output and be able to tweak a few things and re-create it and iterate a few times like that. Forcing people to remember to delete the previous iteration's files is annoying. I know many people do consider their output to be sacred and want to prevent accidental deletion so we would need there to be a way to preserve that behaviour.

    My personal preference would be for this to be a preference setting rather than a popup dialog. Those confirmation dialogs are refereed to as "stopping the proceedings with idiocy" and their presence in software usually means the authors did not sufficiently consider the user's workflow. Typically they mask either insufficient undo support (if an action can easily be undone then why bother people with confirmation dialogs?) or (in this case) improper consideration of the user's workflow. The vast majority of users fall into one of two groups: one group of users always want to overwrite their output files and another never wants to. Hence a preference will satisfy the majority of users without interrupting the user experience with confirmation dialog boxes.

    3
  • Mike Katz

    I agree, it's the most irritating and unnecessary omission in a great product as opposed to Lightroom, which works this way!

    2
  • OddS.

    Ian:

    My personal preference would be for this to be a preference setting rather than a popup dialog

    Why not just a three way preference settinging?

    Processing allowed to overwrite existing file(s): [No (default), Yes, Ask]

    Select Ask if you want the popup, else select Yes to activate without the popup.

     

     

     

     

     

     

    1
  • Class A

    I have suggested export overwriting as a feature request in the past. There are many ways to avoid unwanted overrides so I don't see any excuse for not implementing the ability to overwite existing files. The current need to delete files manually has a very real detrimental effect on productivity.

    1
  • Jakob Boie Sørensen

    Thank you everyone for your feedback and elaboration. I will forward the request for an overwrite option internally.


    Best regards,

    Jakob, Capture One

    1
  • BeO
    Top Commenter

    Three way is perfect (I wouldn't want an additional dialog either).

    Preference or process recipe setting?

    0
  • BeO
    Top Commenter

    I like the idea to be able to overwrite, just want to mention that I need the ability to automatically create a new file actually more, as I often out process an image and open automatically with a viewer app, e.g. firefox, make further adjustments and then output again and want to compare both, without the need to manually rename the first file and load again into the viewer app. So if we can only have one behavior then the current behavior suits my personal needs the most.

    0
  • Permanently deleted user

    If variants are exported we need all of them and should be numbered, but if same image is exported I rarely want both. 
    I would like to have preferences like this:

    EXPORT behaviour if file exists: (bold option is default)
    - if variant = overwrite, rename, ask 
    - if same image = overwrite, rename, ask 
    (where dialog have thick box "do not ask next time"). 

    Output naming should reflect variant number in editor.
    Now is wrong: Variant 1 of image is exported as "Name.jpg", variant 2 is exported as "Name 1.jpg", 
    *Proper way*: Variant 1 should be exported as "Name_1.jpg", variant 2 as "Name_2,jpg", not to confuse user and also to being able to delete those numbers easier. "space number" (in "Name 1") is harder to bulk rename and to spot with mouse than number with underscore. 

    In fact: naming should be user selectable. I use descriptive names with dashes (shoot-name-number.raw) where underscores are reserved for camera maker part of name (e.g. _K1_9146.DNG for my camera). Someone else will want another scheme. Why not give flexibility. I would like to have also letter V, to describe it is "internal" variant (when one creates variants in editor like BW/color) vs variant of same file exported more tan once. 

    - If variant add: "_V#" or "_variant #" where copy of same file would have other naming scheme, like "_version #". 

    * Output naming scheme allows to configure exactly what I said above: I have >>"image name"_V"Variant position"<<. hich is fine, but not flexible, since it stay permanent for every export. It should be engaged only when two or more variant re there for same filename. I do not want 1200 wedding images have "_V2" in output name, just to seek which one also have _V2 and those two exclude from "bulk rename". Fiddly. Also there is not option for version, talked before.

    Also naming is permanent, it should be per recipe. Different recipe needs different naming scheme. I want original names in output files, but to customer I send files numbered from 0001 to whatever, so they can pick easy. Also not to question why there is gap between numbers. 

    In naming scheme is all sort of things. Why not also for BW image or any allow renaming variant and use this in output name scheme. Often I do color and BW variants of same images. It would be great to differentiate those. Now I need to color code one and export in 2 separate tasks and change naming scheme (or much easyer use Bulk Rename tool). 

    0
  • Jakub Zablocki

    +1 on the request

     

    0

Post is closed for comments.