Open matthewberryman opened 7 years ago
Hi Matthew. Thanks for your proposal. I remember the gm's compression feature have bad performance on png images, that's why I use pngquant instead.
Are you testing on png files in your fork? You could use gm to reduce the png file, and compare the output file with input file. Sometimes the output file is even bigger than the input!
I haven't tested out png -> png yet—in our use case I'm first converting to jpg and then adjusting the jpg quality—though you're right, not worth doing if it's badly performing.
Rather than having two separate reduce and resize paths in the code as well as config.json blocks, why not just have one list—call it "images" rather than "resizes" in the config.json, and then have one block of code that uses the in-built gm quality() call? From the gm docs: "Adjusts the jpeg|miff|png|tiff compression level. val ranges from 0 to 100 (best)".
I'd make this an optional parameter—in my test implementation in my fork, I have defaulted to 100 if the parameter wasn't set, however I believe the default should be 75 for jpgs and may be a different default for other types, so putting the two different gm call chains in an if/else block is I guess better.
This would then I believe solve the other issues https://github.com/slimfancy/image-lambda/issues/3 and https://github.com/slimfancy/image-lambda/issues/2 as they appear to be down to the other software packages you're using for reduction.
It's a fairly big change so I thought best raise this for discussion first before settling on some of the design decisions. One gotcha is that the png reduction behaviour may well differ between your existing implementation and this proposed one due to differences in the software (TBH I am only familiar with JPG compression not PNG compression as I once wrote a JPG compressor :)