Jump to content

M.Chapman

Verified
  • Content Count

    2,790
  • Joined

  • Last visited

Everything posted by M.Chapman

  1. Yes it was. But unfortunately when Google drive provides the low res previews it converts both images to sRGB before you view them in your colour managed browser. Which is why I mentioned the images need to be downloaded to make a true comparison. I apologise for the confusion. It's my fault, I should have found an image hosting site that provides "un-adulterated" image previews to make it easier to make a comparison without needing to download. I'll see if I can find a suitable hosting site. If I do I'll update the links. Maybe Dropbox works? Mark
  2. They shouldn't look identical. If you're viewing in PS make sure you have the following colour management settings. >Edit>Color settings.... >Color management policies... Set RGB to Preserve Embedded Profiles. Profile mismatches - Ask when opening Reopen the TIFF files and then, if asked what to do about the profile mismatch to your working space - select "Use embedded profile" You should see a noticeable differences in the distribution of the colours, and there should be some intense colours in the AdobeRGB version that appear slightly more muted in the sRGB version. The degree of extra vividness you see in the AdobeRGB version will give some insight into how much extra (beyond sRGB) your monitor can display. It's not a perfect test, but gives an insight. If the same test is done with ordinary photos the difference will be less noticeable, because most photos aren't full of colours that are at the extremes (unlike the Granger chart which does). Mark
  3. Michael, Thanks, you've led me further into understanding what's going on with my histogram and those colour sampler numbers. I find that histogram and RGB colour sample values are based on the RGB values in the image data before the colour profile is applied and so can't be used to measure the differences we may (or may not) see on screen after the profile has been applied. To see this in action try the following. Create a blank image in PS with R=64, G=128, B=192 in AbobeRGB colour space. Add 1% gaussian noise (Filter>Noise>Add Noise) so you can see the RGB lines on the histogram. You'll see they are nicely spaced at 64, 128, 192, and the colour sampling tool shows values that are R=64, G=128, B=192 with a bit of noise. So at this stage, everything is as expected. This image was created in AdobeRGB colour space and is being displayed using an AdobeRGB profile. Now assign (don't convert) to an sRGB profile instead. (Edit>Assign Profile..). Watch what happens to the colour shown on screen, it changes significantly - but the histogram and RGB colour sample values do not change as they are based on the underlying data before the profile is applied. ie. the histogram and colour samples don't indicate what's on screen. They are based on the RGB values before any profile is applied Undo the last step (to go back to an AdobeRGB profile), and now convert the image to sRGB (Edit>Convert Profile...). Watch again what happens to the colour shown on screen (it barely changes this time) - but the histogram and colour sample values change significantly (especially the red). Conversion to sRGB is a more "legitimate" step as that's what happens when saving an sRGB image whilst working in AdobeRGB colour space. But what this indicates is, if the required image format is sRGB (Alamy always end up there), but editing is being performed in AdobeRGB, the histograms and RGB values shown in PS can't be relied upon. In fact, careful adjustments to the histogram to ensure a tonal range from 0-255 are a waste of time in AdobeRGB as they will be messed up by the conversion to sRGB. It's simple to test this. Take an image with some nice rich colours. Working in AdobeRGB in PS adjust your histogram to give close to 0-255. Save as sRGB jpg ready for Alamy. Now open the jpg file in PS and look at the histogram. It may be badly clipped. Here's an example. Working in AdobeRGB - nice histogram. But after conversion to sRGB - significant clipping of the red channel OK. So surely there's a simple solution? Turn on Soft Proofing for sRGB before making adjustments to the histogram? But no, that doesn't work either. The histogram doesn't change when soft proofing is turned on. Mmmmm..... OK how about the sRGB images exported directly from LR. Same problem, clipped reds. But I find soft Proofing works in LR. If sRGB is set as the target profile, the histogram changes and it's clear that clipping will occur so corrective action can be taken. I wonder why soft proofing in PS doesn't work the same way?? IMO the bottom line is; If using PS and wanting to submit optimised images to Alamy, then adjustments have to be made whilst working in sRGB mode and sRGB images have to be submitted directly to Alamy.... If working in LR then be sure to turn soft proofing on and set sRGB as the target profile to check everything's OK before exporting as an sRGB jpg. Submitting AdobeRGB images to Alamy doesn't solve the problem. The clipping will still occur when they convert the image to sRGB (I've checked this happens). I've no idea if these comments/problems with the histogram apply to other image editors. Mark
  4. Yes indeed. I find it strange that Alamy convert 8 bit jpgs submitted as AdobeRGB to sRGB. Two steps that loose quality. Conversion from AdobeRGB to sRGB looses some colour info and doing the conversion on an 8 bit image risks introducing banding. Only way around this (partially anyway) is to submit sRGB created from 16 bit source so Alamy don't have to do any conversion. Mark
  5. They (Google Drive) must be converting (presumably to sRGB) before they create the preview pngs. If they simply stripped the profile then the Passport chart images would look quite different to each other. If an AdobeRGB image is incorrectly rendered as sRGB it looks quite "dull" (compared to an sRGB image correctly rendered as sRGB) Mark
  6. Another oddity I really don't understand..... If I follow my own instructions... Another option is to create you own comparison images using a RAW image file that you think is demanding and should benefit from the increased gamut of AdobeRGB. Open the RAW file in LR and export an AdobeRGB and sRGB version. Then open both in PS (do not convert the profile) and toggle between them. On my monitor (which is not wide gamut) the difference between sRGB and AdobeRGB is quite subtle, to my eyes anyway. Although the difference in the images is very subtle, the histograms are quite different..... The sRGB image (bottom) has the full luminance range. But the AdobeRGB version doesn't. It's one of the reasons I ended up standardising on sRGB for my workflow, so that the end result was predictable and should match what my Alamy and my other customers receive. Maybe I should have turned on soft proofing and keep swapping to AdobeRGB or sRGB before adjusting the histogram and exporting? All too complicated for me. So I stick with sRGB, simples... Mark
  7. Checking the source code. Google drive appears to be "serving up" a png file without colour profile for the previews. So using the Google Drive preview images as rendered by your browser is not a valid way to compare those sRGB and AdobeRGB Passport or Granger chart images. They have to be downloaded. Is it any wonder folks get confused by colour management. (Me included!!) Mark
  8. I suspect the browser comparison is probably just showing how well (or not?) Google convert AdobeRGB to sRGB to create the preview image? Is there a way to prove that's what's happening? I think the valid test is to download the images and view in PS or other colour managed application. Another option is to create you own comparison images using a RAW image file that you think is demanding and should benefit from the increased gamut of AdobeRGB. Open the RAW file in LR and export an AdobeRGB and sRGB version. Then open both in PS (do not convert the profile) and toggle between them. On my monitor (which is not wide gamut) the difference between sRGB and AdobeRGB is quite subtle, to my eyes anyway. Mark
  9. I just updated the links on the Granger to 16 bit TIFF versions. Did you download them? If I view in my browser, the Granger charts look pretty much identical too, but I think Google drive is preparing an sRGB preview. The true difference should be visible if you download the TIFFs and then open. Mark
  10. I also agree with MDM. But offer the following comments. 1. Agree the gamut is wider in modern displays, but so are the contrast ratios. So the question is how much difference can those with "wide gamut" displays see between correctly tagged and rendered sRGB and AdobeRGB versions of exactly the same image? Try downloading and then opening these images in the the colour managed app of your choice, and toggle between them on your wide gamut display. Passport colour chart - AdobeRGB Passport colour chart - sRGB OK the range of colours here in this real life example is limited, so try these Granger charts which include all the available colours in each colour space. Granger chart - AdobeRGB Granger chart - sRGB You will probably see a difference in the Granger charts, but these charts include colours that don't occur in nature (but may in man-made surfaces). 2. Agree that conversion should ideally be from 16 bit. Therefore, because Alamy will convert 8 bit AdobeRGB jpegs to sRGB I'd argue it's absolutely best to submit as sRGB so you can do the conversion from a 16 bit source and Alamy don't have to do the conversion from AdobeRGB to sRGB on 8 bit data, which will cause some banding. 3. Agree. The problem I had was not the data processing overhead (there isn't one). The problem I had was the inconsistency of the rendering and histograms if I worked in AdobeRGB in PS and then saved as sRGB. Try the following test. Load a colourful RAW image into PS and carefully adjust the histogram to give full tonal range (as Alamy request). Now save as an sRGB jpg. Now open the sRGB jpg and inspect the histogram, I find it's now badly clipped, contrary to what Alamy request. Even soft proofing doesn't seem to fix this problem for me. Maybe I'm doing something wrong? So, in the end I went for simple consistency of both the colour rendering (WYSYWIG) and histograms by working in sRGB throughout. I'm not throwing any data away as I still have the RAW files and the sidecar develop settings will allow me to recreate in another colour space if I need. 4. The first sentence matches my current needs. The hurt came with the inconsistencies mentioned above when I worked in AdobeRGB and then discovered Alamy actually want and sell sRGB. Working in sRGB throughout I can be confident that the image Alamy sell to customer matches the image I edited in PS. 5. Agree. Shame Alamy seem to have gone with sRGB.... Mark
  11. I think it's possibly due to a "glitch" in the image database that can occur when images are deleted. After Alamy "repaired" my image data, the number of images in my collection became consistent (between AIM, forum and various search filters), and I could download my CSV data again. Mark
  12. For images submitted to Alamy it doesn't matter because they convert everything to sRGB and then (contrary to best practice) strip the profile. I work in sRGB because it provides me with a consistent viewing and editing experience and simplified my workflow, and the libraries I submit to take sRGB. I do however keep my RAW files so I can always go back and recover any colour information the conversion to sRGB may have lost. I don't do much printing. You may find this interesting https://hubpages.com/art/SRGB-AdobeRGB-and-ProPhotoRGB-colour-spaces, there are links to some sRGB, AdobeRGB and ProPhotoRGB test images towards the end. The biggest differences (on screen) IMO occur when images encoded with one profile (e.g. sRGB) are rendered using the wrong profile (e.g. AdobeRGB). This can make viewers believe the differences between sRGB and AdobeRGB are more significant than they are. Mark
  13. I see there's a comparison of the features in Capture One Express versions versus the full version here. It shows sessions aren't supported in the Express Versions. Mark
  14. Why are you storing your model release details on a database that is accessible to a team? If there's not a good justification for this, doesn't it run the risk of unnecessary "sharing" of personal data? Mark
  15. Must depend on the camera manufacturer too 😞. I just tried it on a variety of my RAW files. Canon G10 (fixed zoom lens) - Seems to work Canon G15 (fixed zoom lens) - Can't disable distortion correction in LR Classic Lumix G5 and G7 - Can't disable distortion with any of my Lumix lenses in LR classic, unless I use ExiftoolGUI.exe to set the "DistortionCorrection" tag in the RAW file to OFF. Panasonic/Lumix doesn't appear in LR's list of lenses I can select a manual correction profile for either. It's as if the "built in" distortion correction happens very early in the RAW decoding process in LR for some cameras/lenses. But DxO allows me to turn distortion correction on and off at will. It can really save some wide angle shots if corner softness is a problem. (As can using ExifToolGUI). ISTR there's a section on distortion correction, vignetting and CA removal flags in the Adobe DNG file spec. Yes I've read that too. Mark
  16. I got the same email too. But I have just upgraded my Free Sony Express version, so I wasn't surprised. Mark
  17. I'm not sure the Sony Express version of Capture supports Sessions, if it does I couldn't find it. I'd probably make more use of Capture One Sony if I could simply navigate to a RAW image, open it, make adjustments, and export. No catalogues, no sessions. Simples... Mark
  18. The distortion correction applied on modern lenses can be quite extreme. Here's a wide angle RX100 Mk3 shot with and without distortion correction. You can see where all those pixels might go.... Images were produced from Sony RAW files in DxO Optics Pro 9. Mark
  19. It all depends on the maths used to "linearise" the distortion. Pixel positions can either be remapped by shifting affected pixel values outwards (away from the image centre), in which case the original image size is retained but image quality at the edges is reduced as data is "spread out". In the other case affected pixels values are shifted inwards (towards the centre). In this case image quality is retained (and possibly enhanced were image data is squeezed together). But the image will require cropping and so the pixel dimensions of the image are reduced. I find it can be useful to turn off distortion correction on wide angle lens shots of subjects without straight lines as it improves corner sharpness. I can do this in LR or PS by altering the image metadata (using EXIFToolGUI.exe) before opening the image. Other packages (e.g. DXO) allow automatic lens distortion correction to be turned on an off, but not Adobe. Mark
  20. Distortion correction has to be a suspect? Suggest checking whether the same reduction occurs at wide end long end of the zoom lens, or only applies to one lens? Mark
  21. Looks like you've found some very useful images to digitise and upload to the archive. Mark
  22. M.Chapman

    Archive search

    Customers can search by date taken using the custom date field. But if you want that to work for your images you will have to change the "Date taken" (and enter a date in format DD-MMM-YYYY) in AIM to the date when the original image was taken, and not the date the slide or print was recently digitised. Partial dates (e.g. just YYYY) don't seem to work (which is a shame as the exact date of the slide or print is usually not known). Mark
  23. Not sure I understand your question, but a full description of licence types and restrictions on buyers is here in the buyer's contract. https://www.alamy.com/terms/uk.aspx Clause 3.1.11 - which applies to all licence types says the following. The Image(s)/Footage may not be sublicensed, resold or otherwise made available for use or distribution separately or detached from a product or web page. For example, the Image(s)/Footage may be used as an integral part of a web page design, but may not be made available for downloading separately or in a format designed or intended for permanent storage or re-use by website users. Similarly, your customers may be provided with copies of the Image(s)/Footage as an integral part of work product, but may not be provided with the Image(s)/Footage or permitted to use the Image(s)/Footage separately. Mark
  24. If the image that sold was also zoomed, then I see it appear higher relative to my other images of the same subject (caption and tag differences aside). But if it’s just a sale, I haven’t noticed any improvement in position, indeed some of my sold images appear last. But it’s not something I’ve looked at closely, and Alamy can, and do, change the weightings the search algorithm applies to each factor from time to time. 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.