Task title: Modify the existing image.module thumbnailing process to better optimize resized PNG images

Task description: The image.module is widely used, and provides useful thumbnail and preview resizing functions.
However, when using the commonly available PHP GD toolkit to resize PNG images, the result is not well compressed, and can sometimes create filesizes larger than the original, for smaller images.
Resulting PNG derivatives are sometimes many times the weight of their JPG equivalents - with no appreciable difference in quality.

Find a way to make this work as desired - with derivative images having filesizes appropriate for web use.

Optimal solution would be to find the right way to invoke the php GD toolkit to respect the currently configurable image compression levels. The PNG spec can do this, but it's possible the PHP implementation does not.
The solution should be compatible with PHP4 (at least not break) without legacy code clutter, but is not necessarily required to actually WORK under PHP4.

If this approach is not possible, provide an alternative image compression method, such as saving the thumbnails from an original PNG as JPGs.
The image.module function image_build_derivatives() should enable you to save versions of the same image with different formats/extensions, but this feature/behavior should be configurable, and off by default.

Deliverables would include
- A patch against image.module
- Some diagnostics showing the relative filesize results on different types of PNG images (photo-heavy, vector based, indexed color) with and without patch

This will involve skills in programmatic image manipulation and file compression

Resources: http://drupal.org/node/200402

Primary contact: dman

Comments

dman’s picture

dman CreditAttribution: dman commented

Note, I'll admit this is sorta my own itch, and I'm not even sure if the image.module guys would be keen on it - But I think it's a viable, interesting, modular little research project.
Getting to play with the image toolkit for a good cause is fun - the first time around anyway.

cwgordon7’s picture

cwgordon7 CreditAttribution: cwgordon7 commented
Status: Active » Needs work

My feedback:

Find a way to make this work as desired

1) Ok, that is not a good thing to say. It says that you don't know how to do this, but you want us to figure it out. This is not a good thing: if someone comes up with a solution that is not to your liking for some reason, you won't be very happy with it. Specificity is always a good thing with regard to these tasks.

2) You're not very clear on the task, it seems very vague, like you just want some functionality but don't really care how you get it...

3)

this is sorta my own itch

That explains a lot. Yeah... I don't think it's really a very good task in its current state. Perhaps do some rewriting and try again.

-cwgordon7

dman’s picture

dman CreditAttribution: dman commented

OK. The task is to solve the problem.
Feasability study, proof of concept, execution.
I thought the format was to be like a requirements document.

Desired functionality is that smaller-dimensioned PNG previews have a smaller filesize, not a larger one. Sorry if that wasn't clear.

I suggested the two approaches that I thought of, as I'm not actually sure the first approach is do-able, but I know the second one is. Much more time on that and I'd be doing it myself, but it looked like a task with a beginning and an end. And I deliberately chose it because it's interesting as a stand-alone task.

There may be an option I haven't thought of which is even better.
Yes, I'm describing some desired functionality, but I didn't want to lock anyone into exactly what the code must look like. That's no fun for anyone.

The best-case solution is #1.
#2 is totally acceptable to me (but may annoy other folk).

If that's vague, it's partly because there are other folk with investment in image module that may have some input in this suggestion, and we may see them in this thread.
It's my own itch in that I only noticed it very recently, but haven't fixed it myself yet, and thought it was easy to describe. And fun. And a Good Thing to fix.

OK, so in that I can't edit the OP, do I juggle a few words around and repost it in its entirety here?
I'll wait on some more feedback from folk who may have opinions on what the best approach really is. dang. I thought finding the best approach was part of the job :)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

I think it's ok for there to be research in the best approach as part of the task.

But I think the concern is there have been tasks that "look" simple on the surface, but because we didn't fully understand them, students ended up getting mired in 2 weeks of Bashing Face Against Wall, and we want to try and avoid that where possible. :)

dman’s picture

dman CreditAttribution: dman commented

Fair concern. My gut feel is that option #1 may indeed be intractable, but that's just because I couldn't fix it in an hours fiddling. There may be a quick fix I hadn't found.
But #2 is certainly feasible.

Somebody said that it couldn't be done,
But he with a chuckle replied
That "maybe it couldn't," but he would be one
Who wouldn't say so till he'd tried.
So he buckled right in with the trace of a grin
On his face. If he worried he hid it.
He started to sing as he tackled the thing
That couldn't be done, and he did it.
-- Edgar A. Guest

aclight’s picture

aclight CreditAttribution: aclight commented

I actually think this sounds like a pretty cool task, with the possible banging my head against the wall exception :)

I'm more worried about whether the image.module maintainers would accept such a patch or whether they would want it changed in ways that would go out of scope of the task. So saying the deliverable is a patch against image.module could be too easy (it might not work, for example) but saying one that's RTBC could be tough if you don't have the support of the image.module folk.

I kind of ran into this with one of the other tasks I mentored. I finally just said that basically here is what the student needed to do to finish the task, and i'd mark it complete whether or not the patch was RTBC. You could probably do the same thing here, though you might not want to do so in the description--just keep it in mind if it comes up.

So I would suggest just clarifying the deliverable slightly and maybe talking to the image.module maintainers first to see what they think about the idea. If they are on board, then I'd say go for it.

dman’s picture

dman CreditAttribution: dman commented

OK, the deliverable patch must apply [DRUPAL-6-HEAD] and actually work to create its thumbnails with a file size comparable to equivalent jpegs at the default 75% compression rate.

The patch must work to the extent described here, but the Drupal Project RTBC process is not a completion requirement, as I can imagine someone having a philosophical objection to it and it being somewhat debatable for a while. Though I may just be worrying about nothing, and all will go fine.
If that weakens the proposal too much and means someone is making something that may not be used ... heck, I dunno where to go with that.

If I was to set a target, I say that 100x100 thumbnails should be under 10KB. JPEGs at 80% compression can come in at 3-5KB. PNG versions of the same things are hitting 14-20KB.
Obviously just shifting to JPGs can win.
I know that PNGs are deliberately lossless, but I thought there is a compression feature for them. If looking for the answer there lads to head-banging, I've given the fallback option so there's no roadblock.

aclight’s picture

aclight CreditAttribution: aclight commented
Status: Needs work » Reviewed & tested by the community

Ok, it sounds like you've thought about this enough and have provided a pretty good "way out" if the student gets stuck, and I do like the idea of the task, so I'd say go for it.

TrevorG’s picture

TrevorG CreditAttribution: TrevorG commented

I can verify that this is an issue as described, but from what I can see, we are willing to compromise and allow png original to jpg resized? Respectfully, when we're dealing with computer generated content, in particular logos with no photo area, png is a superior format to be using. jpg also has a notable problem with all reds, something png or gif do not have. If possible, I would like to see better implementation of scaling with png. I can optimize a file to be less in photoshop using png-8 128 dithered than I can with jpg and it is higher visual quality. Thanks to any that can work on this, in the mean time however, I have to use jpg as I need my site to go live.

dman’s picture

dman CreditAttribution: dman commented

Indeed.
Which is why I stressed that the choice must be optional.
Whether it's acceptable is an admin decision.
It is certainly a sub-optimal trade-off fo logos etc.

I too can re-scale better PNGs (using Fireworks) than the toolkit does at the moment, but I have been unable to find the right options using PHP to do that. I lack the ImageMagick-fu do fix it, but was hoping someone else could.
Thus, the two-part challenge.

zoo33’s picture

zoo33 CreditAttribution: zoo33 commented

Just a note: implementing #1 would probably involve changes to image.gd.inc which is part of core (and image.imagemagick.inc, which is part of Image). That's a good thing IMO, since other modules like imagecache would benefit from a solution like this.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

Just a quick reminder that the last date that students can claim tasks is Jan 22 (6 days from now). So try and get this taskified sooner than later, if you want someone to work on it.