TheJoeFin
Read every image in folder recursive with option to cancel
https://github.com/TheJoeFin/Text-Grab/blob/603af9629ee3519f578c7a13f9dc75e88c80a932/Text-Grab/Views/EditTextWindow.xaml.cs#L1204
I commented on my closed issue and not familiar with github so I'm not sure if it will notify you. Will comment it here too as it's somewhat related:
Have just tested the new update and it's great. The only thing that would make the folder scan even better is the ability to 'right click' in the area of the located text and have the option to: 'open the file', and 'open file location' (open the folder) while selecting that particular file so you don't have to navigate to it. (it's quite difficult to find the file name if the image contains a whole lot of text which many screenshots do)
Not sure if that would be doable, I guess it would just need to find the nearest filename above the clicking point along with it's origin folder (stored at the top) (you'd probably have to change the filename format so it's unique and easy to find) maybe an xml structure
Also I am scanning a folder with 15k pictures so it did take a while but I noticed the scan used barely any CPU, if it's possible to increase/decrease the CPU usage when performing the OCR that would be amazing although not sure if Microsoft will give that option
Awesome feature! Thinking of further automation, could there be a way to implement folder scan via CLI, so it could be added to a folder's context menu, and auto generate a (folder).txt output? Instead of manually having to open the editor, clicking scan folder buried in a sub-menu, input the folder and then saving the output.
As mentioned with the bulk OCR, would love the ability to generate a txt file for each image in a folder so it's way easier to find the image in question as the current giant text dump (even though it's useful for certain tasks) is hard to navigate and find the corresponding photo. It means I can find an image using windows explorer search. Also curious what changed in the latest release with this feature as I couldn't quite tell, is it faster?
@astandarduser responding to your comment in reverse order. The changes to the directory scanning did not improve speed (yet, working on parallelizing the work, but it is being unexpectedly strange). Mostly more tolerant to bad files, paths, etc.
For your comment about generating a text file for each image file, that would be possible, and I can look into it. I would not want that to be the default behavior for directory scanning. So I am curious where do you expected to be able to initiate this directory scanning, and how should users be able to choose different options?
@astandarduser responding to your comment in reverse order.
The changes to the directory scanning did not improve speed (yet, working on parallelizing the work, but it is being unexpectedly strange). Mostly more tolerant to bad files, paths, etc.
For your comment about generating a text file for each image file, that would be possible, and I can look into it. I would not want that to be the default behavior for directory scanning. So I am curious where do you expected to be able to initiate this directory scanning, and how should users be able to choose different options?
That's great, it would be neat to have it in a right click menu in explorer that expands to either the default, or generate txt files. Otherwise just in the same place