IPTC is old, and yeah, it's basically about standards for press photographers. See https://iptc.org/standards/photo-metadata/
There are pros and cons, but those are usually secondary to whether say you save your raw files as DNG, etc. It's fairly uncommon to use sidecars for files where the metadata can be embedded in the file like JPEG; usually it's done for internal use. Lots of applications would just ignore a JPEG sidecar. But Mylio say can use the sidecars to send info back and forth without sending the whole file. In short, sidecars are usually used for proprietary raw files like ORF or NEF or ARW but not with DNG, or JPEG.
Generally one isn't sending raw files to people who don't know what they are. So, again, the convention is that usually the JPEG or HEIC is going to have the metadata in it. Another photographer seeing a NEF might say, "hey, where's the sidecar?"
Look inside a few. I haven't looked at any sidecars made by On1. I did use some made by Mylio, and in general anything that was specific to Mylio only it could read; other applications like Lr would just ignore it. Sort of like Maker Notes in exif; info only of use to the camera manufacturer at times and not used by anyone else. Ditto for say the adjustment info say Lr would store; most other software wouldn't know what to do with an Adobe adjustment and ignores it. But it could find and use the IPTC description or instructions.
I think that's mostly true only with Adobe since it's the big gun; DarkTable or DigiKam IIRC could read some Adobe edits. Mylio too, although not sure if that's true now. And PM can read some, like maybe just crop.
I wouldn't have JPEGs with sidecars. If I did I'd do it like RAW Power, which I believe stores them completely separately. Which, if one thinks about it, isn't really much different than storing that same data in a database.
It shouldn't affect the image. But writing a file is writing a file, so there's that. Elsewhere in this thread there's a link to how that goes awry with some raw files, as Photo Mechanic users found. I've never had problems with JPEGs, but again, any time you write a file something can go wrong, right? ;-)
The list is pretty old for some software (like 2017 for Adobe), but more recent for others like PM and Photo Supreme. I would guess that since PM doesn't do facial recognition that's why no regions. Lr does them, but again they haven't updated their list there since 2017 I guess (oddly). Is there a detailed list for each software program? I only saw the summary one I linked above.
Thanks; I didn't realize it was that official, as it were. But it certainly makes sense.
I just want to post an update regarding the BookMacster problem. . . Jerry just posted an update that allows me to save bookmarks again. REALLY fast turnaround once the issues were identified.
Try reducing the image preview size. My 100,000+ file catalog, set with a 640 preview size seems fine.
Thanks for the clarification. I wish it would have been written that simply other places I've been looking.
I don't know any DAM solution on Apple Hardware, where scrolling through large collections of thumbnails (in the ten's of thousands) is as fast as Apple Photos or Media Pro. (As a remark, that's why I'm using Capture One in sessions mode and import the developed jpegs into Apple Photos, for getting an overview of my work and distributing some of them to my idevices for showing to e.g. friends of mine. Media Pro isn't working on my OS version anymore. I'm just a hobbyist).
That's interesting that you are using C1 in sessions with a large # of photos. I've been going back and forth with C1 support asking lots of questions and the support guy there said: "There's no issue with handling large numbers of images, the only thing to make it more stable and accessible is to use the referenced workflow for catalogs (note that sessions are not a good option for so many images)."
Thanks for the perspective. I wish the would have sold it to someone else. IMHO it's a good workhorse that just needs a little TLC ... but maybe like you said the port would be more trouble than it's worth.
Along a similar lines to Picasa - if only Google had open-sourced it and given it to the community. Imagine how good it could be now.
Well, when I publish mine onto GitHub you'd be welcome to contribute. It's server-based, multi-user, fast as hell, and I'm considering putting face-recognition and other stuff like that into it eventually.
I've been using Capture One for a bout 5 years now. Started with version 7.
It looks very interestingAlong a similar lines to Picasa - if only Google had open-sourced it and given it to the community. Imagine how good it could be now.
I believe the reason they didn't was due to various non-open-source components used within the code. So perhaps the same issue applied to MediaPro.
Well, when I publish mine onto GitHub you'd be welcome to contribute. It's server-based, multi-user, fast as hell, and I'm considering putting face-recognition and other stuff like that into it eventually.
A few sneak preview screenshots... (note that I'm concentrating on the core functionality - so the UI needs a bit of polish...).
Loading…
en.wikipedia.org
The app is written in C# and .Net Core, which means the server can run on Windows, Mac or Linux (it could also run on Android, I guess). I've dockerised it and run it on my Linux NAS, but do all the development (and hence run it for debugging) on MacOS. The client-side is all browser-based, so yes, will run on any OS with a browser (it works pretty well on my phone, but the adaptive UI needs streamlining to make it really usable.
Thank you for this full explanation. I'm a software developer myself (C on Unix, specialized transactional server apps -- no web nor webapp development).The app is written in C# and .Net Core, which means the server can run on Windows, Mac or Linux (it could also run on Android, I guess). I've dockerised it and run it on my Linux NAS, but do all the development (and hence run it for debugging) on MacOS. The client-side is all browser-based, so yes, will run on any OS with a browser (it works pretty well on my phone, but the adaptive UI needs streamlining to make it really usable.
There's two types of Blazor app - Blazor Server, and Blazor WASM. The latter takes the .Net runtime, cross-compiles it into javascript, and runs that in the browser. It means you can write complete browser-based applications in C#.
My app runs in Blazor Server, though, which is more akin to normal web-app development. All of the logic runs in the back end, and it acts as a webserver. The advantage of that is that it's simple to write the server-side logic for DB management, image scanning etc. The great thing is that all your code is in C# (or mixed HTML/C#) which means no Javascript - a boon for me.
I'm currently using SQLite for the DB and data management, which seems fine - even with 500k images and 20,000 keywords indexed it seems pretty quick. SQLite is super-easy for deployment but I might extend it in future to allow connection to Postgress or MySQL (a bit like the Digikam model, where you can use its own in-built DB, or point it at your own DB for better performance and concurrency). We'll see.
The other thing I've been looking at is using an Electron container to run the app - the idea being that it would give me more options to have native interactions with the client-side OS. So for example: currently, to work locally on some photos in (say) On1 or Lightroom, you click 'export' and it downloads a zip locally. You work on the images, and then you'd sync them back to the server. If the app was hosted in Electron, you could nominate a local Pictures folder, and as soon as you pick images to work on they'd sync locally, and they could be synced back to the server in a single click. E.g., "check out, work locally, check back in" - which would be a nice workflow.
Heh. I think we're in agreement about JS.I do agree that developing in C# should be more fun than Javascript --- this is a personal point of view, so JS fans should not take offence
Yes, I suspect it'll be fine so far - it absolutely zips along for collections of 10K images, and a full-text search query returns results in around 250ms or less with 500k images. I guess my main concern is how well it'll work if you have more than > 2 users, but we'll cross that bridge once I have it working for 1 user.
Yes, of course. The idea would be that the electron container would be entirely optional; primarily you'd run the app in the browser, but there'd be appropriate hooks in place so that if you launch the app in Electron, the more native integration with the local file-system would be enabled. It would be more of an add-on/enhancement, rather than anything mandatory. There is another alternative, which is to use the native chrome filesystem API , but that's pretty experimental. Perhaps by the time I get around to writing that part, somebody will have wrapped it in a Blazor library.
For enthusiast photographers, the 95-98% use case is probably single user.Yes, I suspect it'll be fine so far - it absolutely zips along for collections of 10K images, and a full-text search query returns results in around 250ms or less with 500k images. I guess my main concern is how well it'll work if you have more than > 2 users, but we'll cross that bridge once I have it working for 1 user.
If the server part is on the same machine as the client part, then, sending a picture to an external editor could be done by the server part. The server part would copy the picture to a specific directory and start an app, pointing it to picture copy.Yes, of course. The idea would be that the electron container would be entirely optional; primarily you'd run the app in the browser, but there'd be appropriate hooks in place so that if you launch the app in Electron, the more native integration with the local file-system would be enabled. It would be more of an add-on/enhancement, rather than anything mandatory. There is another alternative, which is to use the native chrome filesystem API , but that's pretty experimental. Perhaps by the time I get around to writing that part, somebody will have wrapped it in a Blazor library.
Didn't MS jumped in much deeper when it started to use Blink, the Chromium engine ?As for the subjugation of browser technology, I think that happened the moment that Microsoft switched to use WebKit. But that's for another thread.
Yep, I agree.
Well, I'm not planning to sell this, as it would conflict with my day job - but again, that's a question for the future. Once it's on GitHub, if people want to collaborate and enhance to make it multi-user, that would be awesome.
I'm not really sure that's a sensible or likely use-case. If the server and photos are running on your laptop or PC, then you're as well to just use Lightroom/On1 etc directly over your collection. But maybe you're right...
Indeed, the day job has priority -- it is quite uncertain to make a profit by writing a new app.
If your app handles scrolling through 300K of pictures quickly, manage & search keywords and metadata, and, can start an external editor (Ps, Affinity, DXo, ON1, etc), then, it does not matter if the server and the photos are on the laptop or PC. Because it would already be a useful DAM.
