Improving a workflow.

[richardy2]

I have just come across your wonderful little bit of software. The best part about it that does not seem to be mentioned is that it produces a usable image to asses from incorrectly exposed images that can too dark to assess in most viewers without moving to an editor. This allows rapid sorting of potentially recoverable images without constantly moving over to an editor. However it would be so much better still if having found a recoverable image, that could be passed on to editing software from within the program. This would require a setting to provide an address for the default editing software and a hot key, say E, to pass it on to that editor. If you could add that, and possibly a hot-key to close your program, say Esc, it would be perfection for me, and I think many others as well.

[markyip]

Please check the latesr v2.3 release

[markyip]

Glad to hear it works, and thank you so much for the valuable feedback!
​As for the installation size, the main culprit is the semantic search function, which uses a local image recognition model to allow users to search for images by their content. I originally created this for a sister project, but a 'lite' version without semantic search is in the pipeline and should be ready in a couple of days.
​Regarding performance, we are continually working to improve the overall quality of the app. Right now, we are focusing on optimizing load times for the gallery thumbnails and are trying to utilize the GPU for RAW image decoding. Compared to our current library, this should offer significantly better performance. Unfortunately, that feature is a bit stuck in development hell at the moment because it isn't rendering colors correctly yet, so we’re still troubleshooting that.

[richardy2]

The major problem with software of this type is that individual requirements can vary so greatly. The FastRawViiewer I mentioned does much of what I want it to do but, as with your software, really lends itself mainly to sorting large numbers of pictures and does not lend itself to single, or low numbers, of images such as seen attached to emails. However programs designed for those instances rarely view the true RAW image, just the thumbnail within the file. The subjects I'm usually viewing are usually natural history object above and below water which AI apps have trouble identifying at the best of times so an AI search for a specific one is unlikely to be accurate enough. Exif information including GPS position and keywords would be very useful, and a position on a map exceptional. Such a program does not yet exist, which is why I keep looking at many in the hope that I may get nearer to my ideal. I look forward to looking at your 'lite' version.

[markyip]

We actually already have EXIF keyword search built-in, so you can filter by ISO, focal length, and aperture. GPS searching is there too, but right now I have it limited to mapping to the closest city (so you can search "Tokyo" or "London"). Adding an actual map to show the exact coordinates is do-able and something I can look into!
​As for the AI detection, I totally get the frustration. My main use case is for airshows, and most generic models just cannot identify specific plane types. I'm actually working on a sister project right now to fix exactly that. It uses a pre-trained model for aircraft types you'd typically see at an airshow, allowing you to search and automatically sort your photos into folders by model. I've also included the training script, so in theory, you could train the model to recognize whatever specific niche you're interested in!

[richardy2]

I wish you luck with your aircraft types,. However you probably have a better chance with those than I do with approximately 670 species of spider alone, add 270 bees, and you already have a task, especially as many have not been photographed never mind enough different angles to train an AI model. Then move on to 7,000 flies 4000 beetles and so on and I've not mentioned underwater yet and I have seen 8000 quoted as the number of species there, and these figures are just for the UK!! The task is near to impossible and you might have a market for the result so small as to be totally impractical. The other problem is that every option will tend to grow. If you are looking into maps, are you looking at a map per pictures or one grand map per file, and having got all the dots on a map, can you click on one and go back to the picture. There is so much that could be done but so little that is actually practical.

[markyip]

I like the 'map-per-image' model because a global map filter would accidentally hide photos lacking GPS data. However, the global map is a cool way to show a journey.
What if we compromise with a mini-map on the image details view? It would show where the current photo was taken and drop pins for other photos nearby. Clicking a pin would let you jump straight to that image. Thoughts?

[richardy2]

An excellent compromise :-)

[markyip]

POC is feasible and now I need to figuring out the UI/UX for overlapping map images. If multiple photos are taken from the same spot, I’m planning to cluster them under a single pin that opens up into a gallery when clicked

[richardy2]

That is perfectly usable. However I'm hoping this does not slow things down, in fact hopefully, when added to a version without AI it will run much faster than the full 2.3 version. While not requesting items specifically for me, I use the mouse for primary navigation. A double click on an image file opens the browser. Left and right buttons back and forward, zoom with wheel and exit with a double left click. A long right click could open a submenu to access, for example, the location map. If it is of any interest you could also look at a gallery from my web page, and you will see the underwater pictures have a map button to display where the dive site was. https://www.richardy.co.uk/CarnaOct24/index.html You will notice this can be zoomed in and out of, and dragged around to help work out where it is.

[markyip]

https://github.com/markyip/LocateIt

Long story short, the map integration turned out to be way harder than expected, and the performance and UI/UX just weren't up to par. Because of that, I actually split it off into a separate project. This one doesn't just cluster images with embedded geotags—it also lets users easily add GPS coordinates to the EXIF data of both RAW and JPEG files. Please try it and give me some feedback

[richardy2]

I'm not surprised you found the task hard. Modifying the template to get the maps on the website was not easy (my son did it for me, I just pointed out where the problems were). Unfortunately this project is moving away from the initial idea so that, although it sounds good, I'm not sure that I would use it. There are a few points that come to mind as I think things through. The initial idea of the maps was to quickly see where an image was taken while sorting through them. However your solution has at least two problems. The first is that although writing the GPS coordinates into RAW files sounds useful, RAW files should theoretically never be altered as they should be the original source you can always go back to and not put at risk of corruption. The ways this is got around are usually, to write a sidecar file for each image, or create a new DNG or JPG file including the coordinates. So whichever approach is used, your viewer should be able to access these alternatives in addition to the RAW file, for those occasions when the camera has been able to include them at the point of capture (though the sidecar file is the least important). The second problem is the size and speed of the app. Where I would find the app most useful is not to add coordinates (so code to do this would just take up space for no purpose) but to see where individual pictures are taken, not the entire collection in a random a group sent to me by a third party. So the complexity of putting the whole group on the same map is also not needed and would just be bloat taking up space and slowing things down. I appreciate that I could use Lightroom to do this but I don't want to go that way as it would be using a sledgehammer to crack a nut, and I don't want to become trapped in the Adobe system. However I don't know of an alternative image viewer that will do it, the closest just provide the coordinates within a list of EXIF data that can then be copied and pasted into Google Earth which is rather time consuming.

[markyip]

Good point on RAW data editing; I'll check how Adobe and others manage it. Regarding the app size, I distilled a lite version by stripping out the image rendering packages, reducing it to just 33MB
https://github.com/markyip/LocateIt/releases/tag/v1.1.0

[richardy2]

You are taking my size comment too far, although you perhaps are just trying to check that module works. The first problem is that I don't have Python. Going back many, many years I used to play around programming in FORTH along with Basic and some Z80 machine code when a large hard drive was 40MB (The whole POS system for my business with several thousand client records fitted on a Seagate ST35IA/X drive which was 44MB), so it amuses me to see your stripped lite version is 'only' 33MB. How times change, Now I have a son who puts together Supercomputers and thinks a £5M budget is extremely tight!
Still, onto the task in hand perhaps a clearer idea of the vision I have. Currently I use https://www.bandisoft.com/honeyview/ which does most of what I want. It will display coordinates within the EXIF data but it would be even better with a map, at the touch of a key,

[markyip]

I actually have a version that slims it down to 16MB 😜 As for the in-app map, I could integrate one, but with a catch: it would be non-interactive—so no smooth zooming or dragging. That's the best we can do without significantly bloating the app.

[richardy2]

The size does not matter that much, I was just amused how our perception of size has changed over the years, and that what was enough to run a business with is now a cut down version of one component of an application. Speed is more important and there is no comparison when a 300baud modem is compared with fibre broadband.
As for the task in hand, I'm not sure it is going to work. The map in your unpronounceable example would be fine but if the point was on the west coast of Scotland, away from habitation, the same area of coverage would give no clue as to where it was so the ability to zoom out is important. It also needs to be part of an image viewer such as the Honeyview, as the need to leave the viewer and open it in a browser would be little different than simply copying the coordinates and opening in Google earth or a similar map. and finally, of course the images need coordinates within the image, not in sidecar files.
Then of course there is the question of how many people would actually use it if it was there.