Bug 22988 - Visible reduction in image quality
Summary: Visible reduction in image quality
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on: 23963
Blocks: 23984
  Show dependency treegraph
 
Reported: 2019-05-25 21:25 UTC by Magnus Enger
Modified: 2020-10-23 12:35 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 22988: Always set trueColor for the fullsize image (1.97 KB, patch)
2019-08-05 16:52 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2019-05-25 21:25:05 UTC
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?
Comment 1 Jonathan Druart 2019-05-29 22:14:43 UTC
(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)
Comment 2 Magnus Enger 2019-05-31 08:39:30 UTC
(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.
Comment 3 Cab Vinton 2019-07-05 15:10:00 UTC
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."
Comment 4 Liz Rea 2019-07-16 13:59:35 UTC
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
Comment 5 Jonathan Druart 2019-08-05 16:52:57 UTC
Created attachment 92018 [details] [review]
Bug 22988: Always set trueColor for the fullsize image
Comment 6 Jonathan Druart 2019-08-05 16:53:40 UTC
I do not have the time right now to test this patch but I think it could fix the problem.
Comment 7 Magnus Enger 2019-08-08 07:08:44 UTC
Sorry Jonathan, my customer says the patch did not fix the problem. I will try and look into this some more.
Comment 8 Magnus Enger 2019-10-03 09:39:20 UTC
Setting to FQA since the problem was not solved.
Comment 9 Jonathan Druart 2019-10-14 13:16:51 UTC
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.
Comment 10 Katrin Fischer 2019-11-02 20:31:21 UTC
(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.
Comment 11 Magnus Enger 2019-11-04 08:07:18 UTC
(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.
Comment 12 Martin Renvoize 2019-11-04 13:28:54 UTC
Bug 21987 reverted as per above requests whilst we work on a longer term resolution here.
Comment 13 Martin Renvoize 2019-11-04 13:29:23 UTC
Revert action recorded as bug 23963