Images Renamed according to their content using Mirosoft vision api

[Sahil-958]

Changes Made:

• Renamed filenames in the repository to make them more descriptive.

Purpose: The purpose of this pull request is to improve the readability and usability of the repository by providing more descriptive filenames. This will make it easier for users to understand the content of each image without needing to open them.

Details:

• Used a custom script (renamer.sh) to rename the files based on their content.
• Ensured that the new filenames accurately reflect the content of the images.
• Checked for any potential conflicts or issues with the renaming process.
• Added logs and responses from the vision api for better reviewing

Benefits:

• Enhances user experience by providing clearer filenames.
• Facilitates easier navigation and search within the repository.
• Improves the overall organization and clarity of the project.
• Improves Usage of scripts (e.g remote_wall.sh) to download wallpapers by their name

Caveats:

• While efforts have been made to ensure accuracy in renaming files, there may be instances where the new filenames do not fully capture the content.
• Here is an Concrete Example: Renaming [debian_logo.png] to [a blue swirly spiral on a dark background.png] ; in a sense it is correct but not as concise as old name.

Additional Notes:

• Any feedback or suggestions for further improvements are welcome.
• I didn't used any space replacement flag I can edit this pr to have name like: a_name_separated_with_underscore instead of a name separated with spaces
• I already hosted them on repo walls_superset with underscores as i thought this is an opinionated change, but then i thought this would split the efforts into two places so doing a pr now.

[dharmx]

Hello!

First of all. A HUGE thanks for this PR. This will be of great help. Extra

I didn't used any space replacement flag I can edit this pr to have name like: a_name_separated_with_underscore instead of a name separated with spaces

Yes, using either kebab-casing or, snake_casing would be better IMO.

Sincerely, dharmx

[dharmx]

While efforts have been made to ensure accuracy in renaming files, there may be instances where the new filenames do not fully capture the content.

A nice little editable ListBox[CheckBox, Label[FromFilename], InputBox[ToFilename]] should do the trick i.e. we can edit the ones we do not like and THEN bulk rename them.

[Sahil-958]

A nice little editable ListBox[CheckBox, Label[FromFilename], InputBox[ToFilename]] should do the trick i.e. we can edit the ones we do not like and THEN bulk rename them.

Hey, I want to confirm whether you're suggesting implementing the functionality described in your previous message within the renamer.sh script, or if this is related to a separate process. If it's related to the renamer.sh script, I could think of the following:

1. Retrieve all suggested names using the Vision API.
2. Prompt the user to decide whether the script should update the name or keep the new one.
3. Based on the user's input, either skip or rename the image accordingly.

If this aligns with your expectations, I've devised two potential approaches:

1. Interactive Flag Approach: Introducing a special interactive flag within the script. This flag would trigger a prompt for each image processed, allowing users to decide whether to skip or rename it.

2. Delegating Renaming to a Function: An alternative approach involves delegating the renaming process to a designated function. This function would operate based on log files, where entries starting with "Y" would be renamed, while others would be skipped. Before calling this function, we could open a preferred user editor to allow for any necessary adjustments to the log file.

Caveats:

While implementing these approaches, it's essential to consider the following:

• The interactive nature of the process may slow down the renaming procedure, especially for a large number of images.
• As a maintainer of this repo, you'll need to run the script and choose the names that resonate the most with the images. This would require setting up the Microsoft Azure Vision API and some time as we have to send a significant amount of data (approximately 3.5 GB) to the Vision API for renaming.

Or you can check out the logs.txt and extract the lines for which renaming needs to be reverted, and i will do a commit reverting those file names.

Please let me know if either of these approaches resonates with you, or if you have any further preferences or suggestions.

Looking forward to your response!

[dharmx]

Hey, I want to confirm whether you're suggesting implementing the functionality described in your previous message within the renamer.sh script, or if this is related to a separate process. If it's related to the renamer.sh script.

Yes, this was just a suggestion for your renamer.sh script. I took a brief look at it and thought this addition would be nice. As for your approaches, delegating to an renaming function seems to cover the previous approach as well. Although, both seems nice to have

The interactive nature of the process may slow down the renaming procedure, especially for a large number of images.

That is to be expected. But, you have already done a fair amount of work for me. I just need to be a bit disciplined with naming the images in the newer commits.

As a maintainer of this repo, you'll need to run the script and choose the names that resonate the most with the images. This would require setting up the Microsoft Azure Vision API and some time as we have to send a significant amount of data (approximately 3.5 GB) to the Vision API for renaming.

Not anymore!

Or you can check out the logs.txt and extract the lines for which renaming needs to be reverted, and i will do a commit reverting those file names.

I did actually skimmed through it. If you go here you will actually see that I have reviewed them. But, now I have copied it locally and reviewing them (which will take quite a while).

[Sahil-958]

Thank you for confirming the implementation plan. I'll incorporate both the function and interactive approaches in future updates. Take your time with the review process. Just to note, I don't plan to introduce updates to the script very soon, but I'll definitely include these enhancements in the future. I'm also considering changing the overall structure of the script to make it easier to incorporate newer changes more easily, such as handling logs and other aspects. If you have any additional suggestions or requests, feel free to share them.

[Sahil-958]

Hey @dharmx,

Hope you're well.

I wanted to give you an update on the bulk review feature. It's now implemented, allowing users to review and edit the mv commands in a file opened in their preferred text editor (set by the EDITOR environment variable). However, I believe there's room for further refinement.

Regarding the interactive flag approach, I've hit a snag. Given the concurrent image processing and terminal logs, prompting users for input could lead to confusion. Here is an example of what would happend:

❯ ./test.sh 
Enter your input: Enter your input: Enter your input: Enter your input: Enter your input: 1
You entered: 1
2
You entered: 2
3
You entered: 3
4
You entered: 4
5
You entered: 5

here is the testing script:

#!/bin/bash

# Define a function
my_function() {
    read -p "Enter your input: " input </dev/tty
    echo "You entered: $input"
}

# Run the function 5 times in the background
for ((i=1; i<=5; i++)); do
    my_function &
done

# Wait for all background jobs to complete
wait

Thus, implementing the interactive flag might compromise parallel processing efficiency. I'm considering restricting it to single file mode for now. Moreover, I don't want to bog you down with these comments, but I was just too excited about my first PR!

Additionally, I'm available to assist with reviewing the logs.txt file if needed. Just let me know if you require any help, or if the review is nearly complete.

[dharmx]

Hello again.

Sorry, for the late replies. I have been busy with entrances.

Regarding the interactive flag approach, I've hit a snag. Given the concurrent image processing and terminal logs, prompting users for input could lead to confusion.

Yes, definitely. Although, I kind of thought that you were implementing something like a excludelist. Apologies, if there was any confusion.

I wanted to give you an update on the bulk review feature. It's now implemented, allowing users to review and edit the mv commands in a file opened in their preferred text editor (set by the EDITOR environment variable). However, I believe there's room for further refinement.

That is perfect!

[dharmx]

For now I am merging this. I'll review and rename them when I have time.