I have a library that is noticing a visible reduction in image and thumbnail quality after upgrading from 18.11.03 to 18.11.05. This could be a regression from bug 21987. They have a lot of scanned black and white covers. The largest text in the thumbnails used to be readable, but after the upgrade, it is not. Their scanning process has not changed, so the original image that they upload should be of the same quality as before. Old, good image: http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagenumber=4332 http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagenumber=4332&thumbnail=1 New, not so good, image: http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagenumber=4463 http://bibliotek.dis-danmark.dk:8080/cgi-bin/koha/catalogue/image.pl?imagenumber=4463&thumbnail=1 Did we reduce the quality a bit too much?
(In reply to Magnus Enger from comment #0) > so the original image that they upload should be of the same quality as before. They are not: 4332 is 300.54 KB (307,750 bytes) 4463 is 12.49 KB (12,785 bytes)
(In reply to Jonathan Druart from comment #1) > (In reply to Magnus Enger from comment #0) > > so the original image that they upload should be of the same quality as before. > > They are not: > 4332 is 300.54 KB (307,750 bytes) > 4463 is 12.49 KB (12,785 bytes) But Koha does not store the original image as uploaded, only a scaled down version (as long as the image is larger than the max size of the full image). So the 12.49 KB size of 4463 is the result of increased data loss after the patch for bug 21987 was introduced. I think the problem might be that the original images they upload are not set as "True color" when they should be. I'll ask them to investigate that.
For what it's worth, we uploaded a cover image JPEG with the following attributes (per Windows built-in file properties): 2433 x 2234 pixels 72 dpi 24 bit depth Resolution unit 2 Color representation sRGB Koha converted this a PNG w/ just the 2 following attributes: 600 x 551 pixels 8 bit depth When I ran the latter thru an online metadata viewer, I got the following: "WARNING: No color-space metadata and no embedded color profile: Windows and Mac web browsers treat colors randomly."
100% this is caused by 21987 - we have people complaining about this as well. The workaround is, I believe, to make sure that the covers that are uploading are in true color, but doing that defeats the purpose of adding 21987 in the first place. I think we should undo 21987 and look closely at how we are storing images in Koha, generally. My controversial opinion is that it would probably be nicer to store them in the filesystem rather than the database. Cheers, Liz
Created attachment 92018 [details] [review] Bug 22988: Always set trueColor for the fullsize image
I do not have the time right now to test this patch but I think it could fix the problem.
Sorry Jonathan, my customer says the patch did not fix the problem. I will try and look into this some more.
Setting to FQA since the problem was not solved.
I will need a step-by-step plan to recreate, as well as an image (or at least a link). While waiting for a correct fix it seems that we should consider a revert of the original patch to prevent the problem to propagate.
(In reply to Jonathan Druart from comment #9) > I will need a step-by-step plan to recreate, as well as an image (or at > least a link). > > While waiting for a correct fix it seems that we should consider a revert of > the original patch to prevent the problem to propagate. If it's doable we should consider that - leaving it that way another release woud not be good.
(In reply to Katrin Fischer from comment #10) > If it's doable we should consider that - leaving it that way another release > woud not be good. Agreed.
Bug 21987 reverted as per above requests whilst we work on a longer term resolution here.
Revert action recorded as bug 23963