Enhancement: Add an option to have index as prefix to the filename

[rc-gr]

Currently, files will be named as <prompt>_1.jpg, <prompt>_2.jpg, etc. While it might be helpful if I'm looking up the first part of prompts, it's less so when I wish to view them chronologically (by default) for something like looking through multiple saved results of spamming a specific prompt. Sorting by date doesn't help because of the asynchronous nature of retrieving the images.

As such, with this option enabled, I could have the files named as something like 00001_<prompt>.jpg, 00255_<prompt>.jpg, etc. The padding is there to ensure that it would appear as how the items are ordered in the collection when it gets sorted by name.

As for the name of the option, --prefix_index <pad length> would be my suggestion.

[Richard-Weiss]

@rc-gr Sounds pretty useful.
I'm looking into adding a configuration file in general.
I think having the creation date as the first part in ISO format could also be useful.
I'm not really into command args though, would a config file like an .ini or .cfg work for you too? You could just set a whole format string and I could show some examples and such in the config file.

[Richard-Weiss]

@rc-gr I've looked into different format and I'll add a TOML with a bunch of settings. I could probably create a function that parses any args into a similar construct, but I think a TOML would be more user friendly.

[rc-gr]

I'm not really into command args though, would a config file like an .ini or .cfg work for you too?

Agreed. While I'm okay with either way, I can see the elegance of putting the setting in a config file, or TOML.

I think having the creation date as the first part in ISO format could also be useful.

+1. It has its robustness and it saves me from having to increment the index for however many each run (as per my comment here). One caveat I can think of, however, is that it would not work for collections whose items have been manually organized, either by manually moving and combining items between collections, or by the Manage feature in a specific collection in the Edge browser.

[Richard-Weiss]

@rc-gr I meant the actual creation date of the image itself. It requires another API call but it should be possible to fetch that information.

[rc-gr]

@rc-gr I meant the actual creation date of the image itself. It requires another API call but it should be possible to fetch that information.

Gotcha. And again, I'm not averse to going with this as it has its benefits.

But to clarify...Suppose I have a collection of 3 images, A, B and C, where chronologically in terms of creation date descending, A > B > C, and would be arranged as A, B, C by default upon saving them in the order they were generated. As mentioned in my previous comment, I could reorder them so they would appear as eg. B, A, C in the collection. But if we adopted the ISO format, we'd lose out on respecting this arrangement filename-wise.

In this case, after processing, it would work out to be something like 00001_B.jpg, 00002_A.jpg and 00003_C.jpg. Whereas date-wise, it might end up like 202311092300_A.jpg, 202311091200_B.jpg and 202311090700_C.jpg.

[Richard-Weiss]

@rc-gr I think I'm starting to get what you mean.
You mean I should include the index in the item array of the collection response, right? I meant that the naming could be something like this: 2023-11-08T1736Z_0001_Prompt.jpg 2023-10-07T1253Z_0002_Prompt.jpg 2023-11-08T1842Z_0003_Prompt.jpg In the end it's dynamic anyways. I'll just include different values that users can include for the file name and the user can build their own format string. Basically something like this:

    file_name_substitute_dict = {
        'date': datetime.datetime.isoformat(datetime.datetime.now()),
        'index': '1',
        'prompt': 'Nice image',
        'sep': '_'
    }
    t = string.Template('$date$sep$index$sep$prompt.jpg')
    s = t.safe_substitute(file_name_substitute_dict)

The date is just a placeholder and I would add padding etc. But the template would be supplied by the config file.

[Richard-Weiss]

@rc-gr I'm pretty much done with this feature. I just want to de-duplicate the code in the download_and_save_image function and test the overall feature, but it looks pretty good thus far.

[Richard-Weiss]

Closed by 3c59afa