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 #3 and #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 :)
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 #3 and #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 :)