It would be useful I think to add functionality that would a) process local cover images and set colour depth, resolution, quality and compression to certain levels set in authorized values at library level, before commiting new images to the database. b) process in batch images already existing in the db, according to the values set. c) store in the db settings used for each local cover image, so that it wouln't be re-processed unless new, lesser image quality settings were set and patch processing was invoked. It seems (Bug 21987 and Bug 22988) that some kind of processign is already performed but I found no related settings or documentation.
Koha currently uses GD's copyResampled to resize local cover images upon upload. Two versions of the original image are produced: * a thumbnail with a maximum width of 140 and a maximum height of 200 * a "full size" version with a maximum width of 600 and a maximum height of 800 Koha only scales down; it does not scale images up if they're already within the size limits. Also, if the width is larger than the maximum, the width adjustment is what controls the overall resizing, meaning that it's possible for the result to be taller than the maximum height.
Created attachment 147467 [details] Image before upload 1085x1597 pixels 24bit jpeg 430KB
Created attachment 147468 [details] koha processed image 600x883 pixels 24bit png 940KB
koha manages however to increase file size by 119% (430KB to 940KB) while reducing image size to 30,6% of the original, both in 24bit colour. Is that sane?
Please also check Bug 23984 - Local cover 'thumbnail' size is bigger than 'imagefile' size in biblioimages table
We noticed the same behavior from Koha. You can see Bug 33857 The patch add a script that reduce and resize oversized local cover images.
We are experiencing the same issues with our Koha. We upload high quality images of maps, but they all get reduced in quality so much that you can't make out any details. Please assist, which conf. files can we modify to make it stop or to no change the quality?
*** Bug 23984 has been marked as a duplicate of this bug. ***