Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by M.Chapman

  1. I find it can take several months (up to 6) for payment. If the sale is via an Alamy distributor then the delay often seems to be longer as the customer has to pay distributor, then distributor has to pay Alamy. If you feel the delay is excessive you could try contacting contributors@alamy.com, but they will probably just tell you they are already chasing and you just need to be patient. Mark
  2. It could be but Alamy choose not to (which is a shame). However images where the customer search only matches a single word from a phrase are supposed to appear lower down in search results, reducing (but not eliminating) unwanted views. Mark
  3. It seems Alamy needed to clarify the situation with respect to the loan to Many Thing (now called Videoloft) The effect on net profit seems the same, it still turns a £1M profit into a £1.3M loss. Presumably this lowers next year's tax bill, but I still find the large increase in dividend payout to the Directors hard to understand given the underlying flat performance and the realisation that they may have made a rather poor investment of £2.3M. Mark
  4. Glad you got it sorted. It's not vey impressive that Microsoft still seem to be struggling with colour management... Mark
  5. You my find this interesting. https://social.technet.microsoft.com/Forums/Lync/en-US/dacd4cf2-56cb-4089-8f2d-834420754a91/windows-photo-viewer-and-icc-profiles?forum=w7itproperf Mark
  6. One of the problems I saw with the Windows Photos application in Windows 7 was that it was incompatible with Version 4 ICC profiles. I had to set my monitor calibration software to generate Version 2 profiles then the rendering was correct. No idea whether Microsoft have fixed that yet. Mark
  7. If your Internet browser, and Windows Photo browser are both colour managed applications, and set to use the same (monitor) profile as LR then they should look reasonably similar. Check what profile Windows is using (Settings - Color Calibration), hopefully it's your calibrated monitor profile? Try soft proofing in LR using the same profile. If you want to make critical judgements of your own photos it's essential you have a calibrated monitor and colour managed workflow. Discerning/Professional customers should be using calibrated monitors and a colour managed viewing/editing app. Goodness knows what PU customer might be using though. Mark
  8. Thanks - Must be an artefact from jpg compression of the screenshot and the rendering in the forum posting. I've just updated my posting to use a PNG version of the composite which seems to avoid (reduce) the problem with the edges and makes the banding clearer. It's still best to look at the individual jpgs in the gallery here. Suggest downloading them and then stepping through them at 100% size in whatever image browser you use. Mark
  9. When I recently purchased a couple of my own images from Alamy (to check if they really were converting AdobeRGB to sRGB) they were supplied as jpgs with level 12 quality. The images I uploaded were at Level 10. The previews I downloaded were also at quality level 12. But, I believe the thumbnails and preview images Alamy display on screen are at a significantly lower quality level (I guess around 7). To see the effect of differing levels of jpg compression on a blue sky took a 1000 x 100 pixel crop from the blue sky in one of my RAW files and saved at jpg levels 0 to 12. Those 13 files can be found here. Stepping through them shows the progressive appearance of banding as the jpg level level is decreased. I also created a composite image by opening the 13 files in PS and tiling them vertically and taking a screenshot which is below. (Although it's better to view the file directly as the rendering in the forum posting isn't as clear (on my system anyway). The composite file is also in the gallery. Note: I tried similar tests with red and green gradients and saw similar progressive increases in banding. This suggests it's not really a "blue" issue, although that's probably were it's noticed most often because of the frequent occurrence of blue skies with subtle gradients in photos. Mark
  10. QC don’t look at the over-compressed jpgs that Alamy are using to display our image thumbnails and previews. They inspect the original jpgs we upload (which they will fail if they show obvious banding). If you want to see what’s going on take an image with nice (no banding visible) blue sky with gradient and save at a range of jpg quality levels. My guess is Alamy are using level 7 or similar. Mark
  11. It certainly makes a difference as to whether the search term matches tags, supertags, or captions of individual images (as you would expect). Whether an an individual image has been zoomed using the same search term seems to also make a difference. I didn’t spot any effect of a sale on an individual image but I imagine total sales could affect contributor rank. But that’s just my testing a while ago, and things change. Mark
  12. That's interesting - I'd never noticed that - because I only looked at the placement of my own images (Duh!!). I wonder if checking ones image spacing is another way (besides BHZ) of assessing rank? Mark
  13. Impressive images. Shame two failed QC. Downsizing to 6MP (using bilinear resample) may help with the artefacts? But the joining errors will still be visible. Mark
  14. Alamy's algorithms are complex and they change them. Making it hard (or even impossible) to get a conclusive result. Even if you do, the algorithm may change and invalidate the results. But here are several observations that still seem to hold true. 1) If an image has been zoomed previously (using the same search terms) it will rise above your other images that also meet the same search criteria that haven't been zoomed. Not sure if pseudos affect this, but the promotion of zoomed images sure makes reliable testing more complex. 2) Ever spotted the "rule of 19"? If a number of my images meet the same search criterion they will typically (but not always) appear in the search results as a chain of images with a spacing of 19. I assume this is caused by Alamy's "diversity algorithm" that spreads images from the same contributor so they don't appear as a block in search results. The spacing of 19 seems to apply to my images irrespective of whether the matching keywords are in tags or supertags or captions, although those with the best match appear earliest in the chain, and previously zoomed images tend to appear first. The position of the first image seems to be determined by rank, previous zooms and weighting applied to matching tags, supertags and caption. 3) Alamy doesn't appear to have carried out a re-rank for ages and ages. As you can perhaps tell, I spent some time investigating this in the past. But in the end, my conclusion is it was largely a waste of time. It's better to spend the time producing more images and tagging and captioning them with care . Mark
  15. Handheld twilight mode on the RX100 works really well, providing subject is stationary and you don't want too much depth of field. As the light gets lower the RX100 (in handheld twilight mode) will open lens aperture, crank up the ISO and then take a number of short exposures and combine to reduce noise. It's surprisingly effective. My Lumix G5 also has a handheld twilight mode but it's rubbish compared to the RX100. Mark
  16. I see an amended version of Alamy's 2018 accounts is going to be available within the next few days. Mark
  17. I’ve seen similar once before. I uploaded a set of images via ftp. They reported as being uploaded but then disappeared when I inspected the upload folder. Thinking I’d done something wrong I uploaded again. The new images appeared immediately, only to be joined by the others later giving me a double submission. It’s only happened once. Mark
  18. Except that measurement can help confirm whether the perceived darkening really is in your head, or due to Alamy aRGB to sRGB conversion or some other problem. Mark
  19. I'm not seeing any brightness shift on thumbnails of images I uploaded back loaded in July 2019. I'm looking specifically at my images of a Passport colour checker W2BEBF (processed from RAW with fully AdobeRGB workflow) and W2BEBH (processed from same RAW using fully sRGB workflow). Maybe you're seeing something new? Method 1 This is how I compared the rendering of the images. I opened both jpgs (as uploaded to Alamy) in PS and also got both Alamy image thumbnails on screen (in Google Chrome) at the same time on a calibrated display. Then took a screenshot of the whole display. Then opened the screenshot in PS and used the eyedropper to check the brightness of the white and black target patches. In all cases they rendered at 94% and 11% brightness respectively. Not sure if this method is flawed, but it's the way I did it. Alamy's conversion of an 8 bit AdobeRGB to sRGB and then compressing to a significantly lower quality jpg for use as thumbnails and preview images is not ideal as it's causing some blockiness in skies and slight change in the colour rendering of the AdobeRGB images. The blockiness caused by the extra jpg compression can cause some small shifts in brightness, but these seem to be + or -. Mark Update 1 - Method 2 - If I take a screenshot of the Alamy preview and open in PS, and compare with my original Adobe RGB image opened in PS, then there is a shift (1% brighter). I'll take a closer look later today as I don't trust this method (differing profile involved with screenshot which is only applied to one of the images). Update 2 - OK I did some checking on Method 2. It seems to be important to ensure that the screenshot tool embeds the correct profile (i.e. the calibrated monitor profile and NOT a Generic RGB profile) with the screenshot. I swapped to using the MacOS screenshot tool (which does embed the correct profile) and now there's a much smaller shift in brightness between the screenshots of Alamy thumbnail and preview images of my AdobeRGB image W2BEBF when compared to the original, when all are opened in PS and rendered using their embedded profiles. The white patch is the same, but the black point has shifted a bit. I think the best comparison method is to use the method described in my original posting as the same profile conversion is applied to both images as they are in the same screenshot. Here's a gallery showing screenshots of what I see (with the Method 1) together with the original jpg as uploaded to Alamy, in case you want to check if you see the same as I do. https://postimg.cc/gallery/1c8ki9e8m/. I recommend downloading the images and loading into PS if you want to check them. Mark
  20. Increase in dividends without adequate justification seems to be in the DNA too? Mark
  21. It's useful that reverse image search from Alamy result pages no longer seems to work. 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.