Jump to content

M.Chapman

Verified
  • Content Count

    2,790
  • Joined

  • Last visited

Everything posted by M.Chapman

  1. I use filenames of the form YYYY-MM-DD plus short caption. Images are stored in folders by Year taken, with Subfolders for month taken. I do some limited local keywording of images that have sold, and where, and of shots of family members. Search in MacOS and Smart folders does the rest allowing me to quickly make collections of images that have sold or of family etc. It works for my entire image collection that goes back to 1980. If I was starting all over again, I'd almost probably do it differently and would probably use a DAM and would definitely make more use of tags and keywords. But... the simple system I use has survived numerous incarnations of Windows, Linux and a swap to MacOS. Images can be moved between devices easily and accessed in a consistent way on my backup server too. I know Adobe have said the LR catalog will still work if the subscription stops being paid. But what happens to all the develop settings stored in there? The develop module is presumably crippled? Can the develop settings still be exported to xmp files? I'm just wary about making LR the heart of my workflow and image library when I have to keep paying a monthly fee to be able to continue using it. As I've said before, if Adobe allowed me to keep using the latest version I have (only after paying at least 2 year's subscriptions for example) it would be different. I didn't mean to suggest PS adjustment layers are overly complex. What I meant is using them is not quite as easy as LR which builds in the ability to turn adjustments on and off or refine them automatically (no need to create layers). I run BreezeBrowser on my Mac using Parallels VM (it also runs in Crossover but not as well). It's not an ideal solution, but BreezeBrowser is still the fastest and best image review and culling software I've found to date. I'm still looking for a native Mac alternative. LR (*on my computer) is just too slow. (*As you know I'm considering an upgrade on that shortly, which could make me change my mind). Mark
  2. A big difference with LR versus PS is the editing is non-destructive in LR. It's possible to achieve similar in PS by using adjustment layers, but it's more complex. I use both LR and PS because they each have their strengths. I don't LR use for culling - I much prefer BreezeBrowser for culling as it's so much faster (no need to import and I can do instant 4x side by side views at 100%) and then I'll (*temporarily) import only the remaining images into LR if I need to do any kind of batch processing. *I've never really got on with the LR catalog because it doesn't automatically track any renaming or moving of image files done in other apps (e.g. finder/file explorer). But if you can live with doing those operations within LR you'll have less problems. I think it's a "Marmite" thing. Some love the LR catalog and all the benefits it brings for DAM. But others, like me, dislike the constraints it imposes, including increasing the reliance on the Adobe subscription). A great thing that's has happened with recent releases of LR/PS is the unification of some of the stuff that goes on behind the scenes. For example, develop presets are now common across both packages. The latest revision of PS ACR also uses develop panels that are more similar to those in LR. This makes swapping between LR and PS much easier. Mark
  3. Lots of Apple announcements here https://www.apple.com/apple-events/june-2020/ Scub to the last section for info on the new Mac processors and demos of LR and PS already running on them. Backwards compatibility is also claimed to be very good. I imagine there will be some issues, but the signs are good. You’ll also be able to run iPad OS apps on a Mac. This processor change could bring significant performance benefits. Mark
  4. Well spotted, I hadn't needed to use it yet, but I'd have struggled to find it too. I see double clicking on the "bubble level" icon will auto-straighten. So I think all the previous functionality is there. Guided distortion/perspective correction is there too, but it's also a bit hidden (rightmost icon inside the Geometry tab). It helps if you've used LR before as the new ACR for PS is much closer to the develop module in LR. Initially confusing, but I prefer the increased uniformity between the two. I also think ACR PS adjustments are now faster and more interactive. Mark
  5. Is it significantly worse than offering the same image at very different price points on different sites? (as allowed by Alamy) RM and RF defines the (rapproximate*) terms of the licence on offer from a given vendor for a given price. The customer whether they want to pay a certain amount of money for the licence terms on offer. If there's a different licence available at a different price elsewhere, then they are welcome to buy that instead if that licence better suits their needs. *With the emergence of the "hybrid" RM/RF terms that sometimes appear on Alamy's licence (multiple use, in perpetuity etc.), could one argue that Alamy sometimes sells RM images as RF anyway? Or have I misunderstood? Mark
  6. That's got to be incorrect. Have Alamy confused themselves over the definition of "exclusive" (as used in the contributor contract, AIM, and in setting commission rates which basically means this image is currently only available for licensing from Alamy), with offering an exclusive use of image to only one client/application? Mark
  7. It's a tag that carries more weight (more importance) in search results. You might find this useful https://www.youtube.com/watch?v=_DeGewd73uw Mark
  8. I've consolidated my suite of test images and made them all available here. Apologies for the rudimentary html, but I needed to be sure the images being "served up" are not being altered by host site (converted to sRGB etc) so didn't want to use an image hosting site. The images can be downloaded by Right-click>Save As... if you need to inspect more closely. Mark
  9. Found the earlier thread where LR was struggling to open folders. Not sure if this is related to your problem or not, but there is a fix at the end. Mark
  10. No problems here (I just updated). ACR for PS has changed to be more like LR and seems more responsive. Didn’t someone else have a similar problem (files not recognised) a couple of weeks ago on the forum? Not sure how they fixed it. Mark
  11. I had a play with DisplayCAL and ArgyllCMS last night with my i1Pro and HP23xi display. Pretty impressive stuff. What it really bought home to me was the importance of specifying the right display technology before starting a calibration and profiling. The difference in measured white point between telling the DisplayCAL my display uses WhiteLED or RGB LED backlight is quite noticeable. I had to do some digging to find out which my display uses (Its spec just says LED backlight). DisplayCAL has excellent help on this. The end result I got with DisplayCAL was very similar to the result from i1 Profiler software. But DisplayCAL seems to have more analysis options. Mark
  12. Excellent link thanks. This led me to these which give very good descriptions of exactly how profiles and colour spaces interact and the use of LAB to convert between them. https://imagescience.com.au/fundamentals-of-digital/02-colour-management-theory https://imagescience.com.au/fundamentals-of-digital/03-colour-management-practise-part-1 Mark
  13. There's a nice simple one here too where the colours are side by side so easier to spot subtle differences. https://cameratico.com/tools/web-browser-color-management-test/ Although what's not obvious (if you have a sRGB display and correct colour management) is that the coloured bars have 2 sections (upper and lower). Mark
  14. I've checked the latest various Browsers running on Mac Mojave using the test page here with the following results, using a wide gamut (AdobeRGB) monitor profile Opera 68.0 (Image 1 = 2 = 3 and Image 4 duller = PASS) Chrome 83.0.4103.106 (Image 1 = 2 = 3 and Image 4 duller = PASS) Edge/Chromium 83.0.478.54 (Image 1 = 2 = 3 and Image 4 duller = PASS) Safari 13.1 (Image 1 = 2 = 3 and Image 4 duller = PASS) Firefox 77.0.1 (Image 1=2=4, and Image 2 brighter = FAIL) So it looks like the main browsers (apart from Firefox which currently has a bug) running on Macs are correctly rendering images files which don't have a profile (e.g. Alamy images) as sRGB, on wide gamut monitors (in line with W3C standards). This is good news. Mark
  15. Yes the article is a bit confusing in that respect. The article describes how to turn on colour management for untagged files in Firefox. This is now broken in FF so the author inserted the second paragraph at the top saying there's a bug. Therefore, at the moment, the method he describes in the following paragraphs doesn't fix the bug mentioned in the second paragraph... There's a long thread about this on DPReview forum. Firefox 77 broke color management. It seems FF have recognised there's a bug, but it's unclear when it will be fixed. Mark
  16. Can those reporting results (good or bad) confirm if they are using a wide gamut monitors. Mark
  17. The latest version of Firefox (Version 77.0.1) has introduced a bug. It's displaying images that have no profile (e.g. Alamy jpgs) incorrectly on wide-gamut monitors. They appear oversaturated. This topic is mentioned here Firefox 77.0.1 is decoding the image data that has no profile as if it was encoded using the monitor's gamut, instead of sRGB. (Untagged images should be decoded as sRGB see Section 3.2 here). I don't know if any other browsers do this. This article (3rd paragraph of section 5.1) suggest other browsers may do this too, but I've not found any yet. To help find out I put together a simple test page here. If your system is working correctly, the first 3 images should look the same and the 4th should look duller. Mark
  18. You are correct, but if you state in Alamy Image Manager that you have a release, then you need to keep a fully completed and signed release on file as you may be asked for it. Mark
  19. I'll do some Googling to see if anything comes up. This has to be a widespread challenge/opportunity? Mark
  20. But then conversion of AdobeRGB to sRGB is hardly good colour management either.... not to mention shipping without a profile... I also found this on Adobe's website which gives details on Profile Assignment and Profile Conversion. https://helpx.adobe.com/uk/photoshop/using/working-with-color-profiles.html Mark
  21. I'm really not sure how to take that. If you're not enjoying the thread I started, why read it? Mark
  22. Another useful post Harry. I'd found the example images previously (he uses a similar technique to the one I used to create my test images) but hadn't read the article. I note the article is from 2016 so I wonder what's changed since? Certainly colour managed browsers that can render sRGB and AdobeRGB (and I assume P3 too) seem to be pretty standard now. The author addresses one aspect which is how to display a wide gamut image on an sRGB display. This is done by conversion of the image data to sRGB (with no control over the method - perceptual, absolute etc.) or by detecting the display in use and serving up the a pre-converted (to sRGB) version of the image. The vast majority of folks, even on a wide gamut display wouldn't notice the difference between those two options, providing as perceptual or relative colorimetric conversion is used. It also mentions the treatment of untagged images - i.e. treat as sRGB What it doesn't cover is the issue you raised earlier. Alamy have a massive library untagged sRGB images. What happens if the market starts to demand wide gamut images or display them on wide gamut displays? We know that if an untagged Alamy image is currently displayed on a wide gamut monitor it will be rendered in sRGB [apart from Firefox 77.0.1see this thread]. So what does this mean in terms of colour accuracy? If the image was submitted by the contributor to Alamy as sRGB, then the user will see a good reproduction of what was uploaded. The image will not contain the more intense colours that AdobeRGB or P3 gamuts, or their monitor is is capable of displaying. But then, nor did the original sRGB image that was uploaded, so that's OK. If the image was uploaded to Alamy as AdobeRGB, then the original may well have included some of the more intense colours that AdobeRGB can render. But, when Alamy convert the image to sRGB, this extra information will have been lost and those colours will have been "clipped". (The exact way in which the colours in the image are "adjusted" will depend on whether Alamy uses perceptual, relative colorimetric etc. conversion. This could be important... See later...). When the sRGB image, without profile, is shipped to the customer how it will be rendered is up to them and how they "treat" the image. But the "wide gamut" colour information has already been discarded at Alamy, before they receive the image. If they load the image into a web-page "as is" (untagged) then it will be displayed as sRGB. If they convert to the image to AdobeRGB the colours in the image will not change (nor will the appearance of the image apart from potentially some banding). In both these cases the image will appear less intense than the one uploaded by the contributor if the original image contained colours that were outside sRGB colour space. If they assign an AdobeRGB or P3 tag to the image, the colours in the image will be boosted. This will give a "richer" rendering of landscape images that some folks might prefer, but could give problems with other types of image (intense clipped colour areas, poor skin tones etc.) I wonder if there's any software that can attempt to "renconstruct" those lost colours? A bit like some of the sophisticated shadow and highlight recovery tools? If the original AdobeRGB to sRGB conversion method was known (presumably Alamy have only used one of them) is there some way of intelligently boosting the colours to give the "impression" of a wide-gamut image? For example - suppose this process was carried out at Alamy. Open the sRGB image, convert to AdobeRGB (to provide free space for extra colours). Apply small (intelligent?) boost to colours but excluding skin tones, and resave with AdobeRGB profile? Alamy would also allow new submissions to be made in AdobeRGB or P3 colour space and would not convert to sRGB (unless the customer selected an sRGB image) and they would ship with the profile attached. They would also provide an easy way for contributors to upload replacement genuine wide gamut version of their existing images without needing to re-keyword and caption etc.. QC would still occur n these replacement images on a sampled basis. Mark (just musing)
  23. I'm sorry I think you are still misunderstanding what assigning and converting (in the software) actually do. The colour numbers are the values in the file, before the profile is applied. Applying a profile leaves the colour numbers unchanged, but may change what appears on screen. Converting changes the colour numbers, but when the new profile is applied the colours on screen shouldn't change. Mark
  24. That's interesting. Something's wrong there then. Maybe, although your document doesn't have the profile embedded, it still has a profile tag? I can send you an image from Alamy if you like to try that which has no profile or tag. Mark
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.