Zum Hauptinhalt gehen

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

Process Recipes - OUTPUT NAMING

Kommentare

11 Kommentare

  • SFA
    [quote="msbc" wrote:
    Problems/confusion with file naming when I process an image. I have OUTPUT NAMING Format set to "Image Name" and Format is TIFF. The PROCESS SUMMARY shows the Filename as XXXX.tif - XXXX being the RAW image file name. But the file created is actually "XXXX 1.tif" and if I process the image a second time its "XXXX 2.tif" etc, etc.

    Two issues here:
    1. The file name in the process summary is different from the actual file name - "XXXX.tif" vs "XXXX 1.tif"
    2. There a space in the file name which I don't want.

    Is this a bug or do I need to specify a different Format to not have filenames with a space in them? I'd be happy with "XXXX-1.tif", "XXXX-2.tif" etc.


    That would usually occur if the target folder already has a file with the name you wish to use.

    C1 will not overwrite it - just add a suffix number as appropriate.

    Does that explain what is happening in your case?


    Grant
    0
  • John Doe
    What if you add a counter token to the output naming format?
    0
  • HansB
    It also happens when you have an xmp file with that name in the folder you are exporting to.
    For example when using xmp sidecars in combination with 'Edit with' in your session's image folder.

    It's just to prevent overwriting, the same way as Mac OS X's own file handling when installing apps.
    But I don't know a way to change the standard to something else, like '_'or '-'.

    When processing, you can change the output name and add time/date tokens or manually add some text.



    Regards,
    Hans
    0
  • Mark Connell
    [quote="HansB" wrote:
    It also happens when you have an xmp file with that name in the folder you are exporting to.


    Yep, that would be the cause here. I use Lightroom for cataloging so all my RAWs have an XMP.
    [quote="HansB" wrote:
    It's just to prevent overwriting, the same way as Mac OS X's own file handling when installing apps.


    Well, I see what it may have been meant for but how can a file with a .tif extension possibly overwrite a file with a .xmp extension? That seems like a bug. If I process the same image multiple times then I would expect this behaviour to ensure I get multiple tif's.

    I can't work out what other token I could use - the counter won't really work as it applies to the recipe, not each file. So, I could end up with:
    file1-1.tif
    file1-2.tif
    file2-3.tif
    file3-4.tif
    file3-5.tif
    etc

    What I'd like is
    file1-1.tif
    file1-2.tif
    file2-1.tif
    file3-1.tif
    file3-2.tif
    0
  • HansB
    I never used xmp sidecars, but maybe it's because of this:

    Any image file CO can handle may have an xmp sidecar.
    So assuming there is a raw named 'image.cr2', the sidecar will be 'image.xmp'.
    Now we add a 'image.tif'. The xmp sidecar would again be 'image.xmp'.
    Two different sidecars with identical names are simply impossible.


    Regards,
    Hans
    0
  • Mark Connell
    Hans,

    TIF files don't have XMP sidecars - all metadata is written in the TIF.
    0
  • HansB
    OK. I didn't know. It was a 'maybe'.


    Regards,
    Hans
    0
  • Permanently deleted user
    [quote="msbc" wrote:
    Hans,

    TIF files don't have XMP sidecars - all metadata is written in the TIF.


    I'm not that sure. I have plenty of Tiff's that I created, for instance through scanning, and with which xmp sidecars are associated, though I didn't ask for anything.
    0
  • peter Frings
    Sidecar files can also be present, even when that image file can store metadata. Sidecar files also contain processing settings.

    So, you simply don't want to create an unmatched pair of an image- and a sidecar file; programs will associate the info in the sidecar with that image and that would be wrong.

    To prevent conflicts with the files with sidecars already present in that directory you could add an appendix to the file name (e.g., image1-edit or image1-c1). That also makes it easy to find those files amongst all the others.


    My biggest gripe with the "xxx 1" format is that they also use it for variants; you can't distinguish between an image that was written twice, or 2 variants (e.g., color and BW).

    Cheers,
    Peter.
    0
  • Mark Connell
    [quote="tenmangu81" wrote:
    [quote="msbc" wrote:
    Hans,

    TIF files don't have XMP sidecars - all metadata is written in the TIF.


    I'm not that sure. I have plenty of Tiff's that I created, for instance through scanning, and with which xmp sidecars are associated, though I didn't ask for anything.



    That may be - but C1 doesn't create a XMP when it writes a TIF.

    I understand the need to add a suffix to the file name, what I want to avoid is the space before the numeral.
    0
  • SFA
    [quote="msbc" wrote:
    [quote="tenmangu81" wrote:
    [quote="msbc" wrote:
    Hans,

    TIF files don't have XMP sidecars - all metadata is written in the TIF.


    I'm not that sure. I have plenty of Tiff's that I created, for instance through scanning, and with which xmp sidecars are associated, though I didn't ask for anything.



    That may be - but C1 doesn't create a XMP when it writes a TIF.

    I understand the need to add a suffix to the file name, what I want to avoid is the space before the numeral.



    As this seems to be the result of in internal automation of the process I doubt there is a control setting available - I certainly don't recall seeing one when passing through.

    If you want to suggest the possibility of Phase offering such a control option (if one does not exist) your best course of action would be to create a Support Case with "Enhancement Request" in the title and describe how you would like it to be handled.

    I suspect there is a reason for the space deployment but there seems to be no purpose in speculating here if that is the case.


    HTH.


    Grant
    0

Post ist für Kommentare geschlossen.