could you give more details on how I can reproduce this error? I would be interested to verify this behavior in my environment (Mac/Win LR5.4, using requestJpegThumbnail in Library module only).
I have had other problems with requestJpegThumbnail. For example, on Windows LR 5.4, requestJpegThumbnail would regularly not call the callback at all, even though the same code worked well on Mac, where the callback would always be called. I then found out I had to leave out the second (Y) parameter to requestJpegThumbnail in Windows (i.e. just pass X parameters and nil for Y), and now it works well on Windows - the callback gets called. So, it's a workaround, but does not exactly create confidence in this method. I have had other problems and have also stopped using it from the Develop module (on Mac it was fine, on Windows it had problems).
1st - make a test copy of your catalog, or set aside your previews anyway..
Then just make a test plugin which goes through all photos in the catalog and calls requestJpegThumbnail - then visit your photos and check coloration.
Of course, if all previews are up to date, none will be created by this method, in which case there won't be a problem, but in cases when a preview is created, there may sometimes be a problem. Dunno if it will always happen or only sometimes.
PS - I don't recall having issues with callback not being called in Windows. If it weren't for the problems I've already had which make it prohibitive, I'd consider further. It would be great indeed if there was a work-around - it would be a very useful method for me, if reliable.
Do you know what colorspace the jpegs are supposed to be? they're untagged, and I have some pretty crazy notes about how I thought they were sRGB, but then that wasn't right............
Ok, thanks, will try later.
> Then just make a test plugin which goes through all photos in the catalog and calls requestJpegThumbnail - then visit your photos and check coloration.
Are there any changes in particular I need to make to the photos in order to observe the effect?
Do you start this from Library or Develop module? (I only use Library so far and haven't observed this effect yet.)
> Of course, if all previews are up to date, none will be created by this method, in which case there won't be a problem, but in cases when a preview is created, there may sometimes be a problem. Dunno if it will always happen or only sometimes.
So, this problem is more likely to occur with newly created previews?
> PS - I don't recall having issues with callback not being called in Windows. If it weren't for the problems I've already had which make it prohibitive, I'd consider further. It would be great indeed if there was a work-around - it would be a very useful method for me, if reliable.
Well, to be more exact, I was using the Windows version of Lightroom under Parallels on a Mac, so you can never be sure if the use of Parallels does not introduce additional artifacts in the handling of this. I did however not happen on a lot of pictures, if the preview was already generated it would work, if one would have to be generated, it would more often than not, not call the callback. It also seemed to happen more often with older file formats such as .CRW. In any way, since I found the workaround I did not dig in further obviously.
> Do you know what colorspace the jpegs are supposed to be? they're untagged, and I have some pretty crazy notes about how I thought they were sRGB, but then that wasn't right............
According to Adobe Photoshop Lightroom 4 * Color management ,
The Library module stores all previews in the AdobeRGB color space. These previews are also used when printing in draft mode. Unless you choose differently in the Soft Proofing panel, the Develop module displays photos in the ProPhotoRGB color space.
[This still is not 100% clear for me, as it speaks about "Previews" (i.e. our jpeg thumbs that we request) in Library module, but in the Develop module mentions only the colorspace for "photos", not for previews.]
Nevertheless, the previews in Library module indeed seem to be AdobeRGB. If you examine returnValue.preview from requestJpegThumbnail to your log (i.e.
local returnValue = selectedPhoto:requestJpegThumbnail( requestX, requestY, jpegThumbnailCallback )
), you can get (what I understand to be) a list of currently available previews, and it also contains the information
colorProfile = "AdobeRGB",
I tried, but couldn't reproduce your problem so far.
I did the following:
- copy LR catalog and LR previews catalog and then used that catalog
- start my test plugin which would select all photos which had development adjustments
- for about 250 of these photos, the plugin then called requestJpegThumbnail
- I requested jpegs of full size, because in my impression this makes it more likely that they will need to be re-generated (I think LR usually doesn't have previews of that size)
- The callback I left empty, just let it provide a debug message to make sure it was called correctly.
- I then looked through the 250 pics in LR, and did not see any (obvious) discoloration.
This was both on Windows (Win7, LR 5.4, under Parallels 9) and Mac (Mavericks, LR 5.3.)
Do you have any other ideas how to reproduce this? It would be good to know that one does not destroy the user's catalog when using this function...
You mentioned ICC profiles, anything in that context which might be relevant?
Alternatively, can you provide a photo where this happens and the respective thumbnail request?
Hmm - I thought I had replied previously but now I'm not seeing it here.
Anyway, since last post I've done 2 things:
1. Created a preview test plugin.
2. I reproduced the problem "#1" in Lr5.4 / Windows 7, which occurs when creating new 1:1 ("final"-quality) previews.
Here is the plugin to try, and a test:
* install plugin of course.
* select a folder with more (raw) thumbs than will fit on the screen, but less than 1000.
* be in library module
* exit Lightroom
* delete all your previews (rename if you want to restore after testing).
* open Lightroom (all thumbs should be gray).
* in plugin manager, click 'Main UI' button (you can close plugin manager now).
* set a photo number (using the edit field) for a photo which is NOT in view (if on Mac, you must tab out of the field too).
* click "Final" button.
* wait until preview completely built (plugin UI will tell you) - it should take at least a few and probably several seconds.
* click "Go" button.
* view at 1:1 (still library module) - if like me, color is noticeably over-saturated.
* make a minor clarity adjustment using quick dev.
* if color changes significantly (e.g. back to normal saturation), then you've reproduced the bug. If not, then maybe you're not having it (or the instructions were wrong, or you didn't follow them..).
Regarding icc profiles of normal Lr previews - they can be sRGB, AdobeRGB, or ProPhoto (I've seen all of those), maybe others I've never seen.
But the ones you get from requestJpegThumbnail have NO icc profile embedded.
My problem "#2" is - I could not get color to look consistently right (after saving data in a jpeg file) regardless of which profile I assigned, nor via any conversions I tried! - I'm talking about image data returned by requestJpegThumbnail only!! If previews read straight from disk, with profile applied as designated in database, color is always spot-on perfect. (see Previews.lua in Framework/Catalog folder of test plugin).
many thanks for your efforts. Unfortunately, the error doesn't occur here, or at least I can't reproduce it.
I followed your instructions (deleted the whole previews directory, could see that previews were gray/not existing anymore, also in database), but encounter no discolorations. Neither on Windows (Windows 7 under Parallels) nor under OSX 10.9. I also fiddled with some options (Catalog settings-> preview sizes, preview quality, activating auto tone correction etc), thinking that maybe you must have some different database properties, but still no change.
Maybe somebody else can confirm this elusive bug on his machine?
I also looked into the question of the colorspace of the requestJpegThumbnail image data a few days ago, and my impression was that it was an untagged (i.e. containing no information about embedded color space) sRGB image. But, it may not always be sRGB, I just looked at 1 or 2 examples.
Since I do not need 1:1 previews from requestJpegThumbnail, I am considering to work around potential problems with requestJpegThumbnail by only requesting thumbnails which already exist in the previews database (i.e. by querying the pyramidLevel table). My impression is that level 5 or 6 previews are usually available, but need to look more into this.
I'll try to send a prototype in a little while, maybe we can find out more then. Again, thanks for looking into this.
Thanks and you're welcome..
As I thought I had typed into another post here (but I guess never posted it): if you have a plugin which relies on requestJpegThumbnail, then I'd be happy to test it for any ill effects. I have completely boycotted request-jpeg-thumbnail because I won't release a plugin which does not work reliably on my machine, even if it might work reliably on others.
But also: if you don't need to assure Lr rebuilds a preview if not up to date, you can read current previews yourself (see Previews.lua module mentioned in previous post). I've been doing that since Lr3 with no problems whatsoever - previews are perfect, color is perfect, never aborted or timed out (unless preview not available), doesn't matter which module you're in........
Another thing I'm no longer sure if I mentioned (call it problem #3 I guess): if you are retrieving a preview for a photo (via call to requestJpegThumbnail), and user changes selected photo(s), it'll abort your preview request in favor of the user action, and your call will time out - which means you need a retry mechanism if you want to go that route, and be willing to endure some long lags.. Another possibility is a "hybrid" approach: check first, directly, using sqlite (and/or looking at jpeg data in previews file) - like in Previews.lua module, if adequate preview is not available, then and only then (if not available and needed..) resort to requestJpegThumbnail - i.e. only use it to force-build the preview.
Reminder: problem "#4" ( I guess ) - requestJpegThumbnail, when invoked in develop module will sometimes return properly sized and formatted jpeg file, with all blank data (zeros). Some assurance that user is and stays in library module is required for robustness, or a check for said blank data.
I was able to reproduce the problem following Rob's steps (I increased Clarity by 1 step and then decreased it) (Windows 7 64, LR 5.4). Here are before and after screenshots -- if you save these to your computer and use your favorite viewer (e.g. Irfanview) to flip back and forth, you can see a noticeable change in saturation.
I know this is very old thread but I can't make that method work at all,
local req_jpeg = photo:requestJpegThumbnail(700, 700, function(success, error)
log('callback exec') -- this is logged
log(success) -- this is always nil log(error) -- never comes this far end)
Can anyone light any light on this matter?
LR I'm using is: 6.7