I'd appreciate a rules-based file-renamer within Screenshot Captor.
-lanux128 (2019-10-05, 01:09:56)
Would it be enough, or easier, to harness a command-line file renamer like BRC (brother of the better-known Bulk Rename Utility (BRU)) or Rename Master?
-rjbull
Could I suggest, before getting lost in the weeds regarding what sort of file renamer might be the best approach, that some consideration be given to whether there is a real need for this file renaming functionality to be added-in to SC in the first place?Presumably, the idea of
changing the image file's name is "because we've always done that" or maybe there's a desire to have it show pertinent metadata that one might wish to be reflected in the image name, for easier searching, or something.
You don't actually need to change the file's original name to do that. You just need to add/associate the metadata to the image, somehow. One way to do that is, if the images are in .jpg, then add the metadata as (say) EXIF data, and you could then use a sophisticated image management tool (e.g., Picasa) to index, catalogue and search that data. (Works brilliantly). Filenames could largely become irrelevant.
However, if you're capturing images using SC (ScreenshotCaptor) and prefer having .png files, then life can become very easy
- if you're also using CHS (ClipboardHelp & Spell). You can use it as an excellent image capture management tool, and save your captured image file(s) in a path such as (for example):
...\Clipboard Help+Spell\Database\Files\2019\10\17_603x276_DF0CFDD5.png - with all sorts of metadata associated:
e.g., including:
* Size/resolution: | 603x276 (20.69kb)
* Notes: Any notes, text, URL links, or (say)references to other files (limit 9,999 characters, I think).
Using CHS and its tagging and especially its
Virtua Folders feature, you can then categorize sort, classify, search and order that meta-data (and the images it relates to) pretty much any which way you want.
...This is why I keep banging on about CHS (ClipboardHelp & Spell) as being an ideal image capture management tool, if users (and its author) only but realised it. The user can forget about worrying about image filenames or what directory the ruddy image is stored in or where it is.
It really does seem rather like a no-brainer, to me: If CHS is running, then every screenshot image that goes to Clipboard also is saved to the CHS image database folder [NB: together with any post-capture SC(ScreenshotCaptor} artefacts added at time of capture, if SC was being used to make the screenshot], from where the user can, at their leisure, view that image saved - just scroll through the images flagged in the CHS Grid display and view the image (with zooming) in the CHS Memo display. The user can at that point also trigger a separate image viewer (e.g., Irfanview) from the view button in the CHS Memo display, which will have previously been associated with images in the CHS settings. Any half-decent image viewer will also have a built-in image management tool and metadata editing tool. The latter would typically be an EXIF editor - e.g., Irfanview is very good in both regards.
If the user then wants to operate on (edit/change) that image, then they can invoke the third-party image editing tool (e.g., SC is very good) from the edit button in the CHS Memo display and which would have been associated with image editing in the CHS settings. (NB: This would require that SC or other image editor be installed first, of course.)
Done this way, the user:
- can forget about the image file (if/when needed, it's path and name are given in the Text tab in the CHS Memo display), and
- can forget about the viewer/editor applications (they are seamlessly integrated into CHS settings), and
- concentrate on the task at hand - namely the functionality that is required (e.g., image view and/or edit) regarding any particular screen capture or clip or other image selected in CHS.
All the above boils down to making the whole process of image capture management more effective/efficient. It's a useful time-saving approach, simply because it automates the integration of image application functionality. The user typically doesn't generally capture an image because they want to capture it per se, but because they want to do something with the image - or its file - once it has been captured.
When seeking to improve a frequently-used and manually intensive process, the rule of thumb is generally to automate wherever possible/feasible and cost-effective to do so.
(As usually described in most/any Work Study practitioner's handbook.)
-IainB