Posted by jason@blaze on October 28, 2010 at 2:24pm
7 followers
| Project: | ImageCache Actions |
| Version: | 7.x-1.x-dev |
| Component: | Canvas Actions Module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I've recently upgraded to 6.x-1.7 and noticed that my images were much bigger then they used to be. After a bit of investigation, I noticed that my JPGs still had a JPG extension, but they were actually PNGs (verified by opening the image in Firefox, says "myfile.JPG (PNG Image, 400x200 pixels"). To fix my problem, I've added a Change Format action to JPG, and this seems to fix the issue, but I didn't have to do this previously.
Not sure if this is an ImageCache Actions or an ImageAPI issue, so sorry if this is in the wrong queue or if it has already been opened.
Comments
#1
Yes imagecache_actions does magically change the file format to PNG, but not the extension (that would break things) if we ask it to with the "change" action.
But only if asked.
Though there may have been some silent switch left in the pipeline that needs documenting.
What are the actions you are performing where this was required?
#2
Sorry, I didn't notice you'd mentioned it was 'define canvas' causing the issue.
Hm
#3
I faced this same issue with a site I was building. The visitors complained of the long time it takes to see photos and I set about investigating. I figured that it was saving PNG's from JPG's making the files at least ten times larger.
I did some debugging and code searching and found the problem. This happens if you have selected 'Resize Canvas Under Image...' in 'Define Canvas' action page. It creates a new temporary PNG image and works with that.
I have attached a patch that fixed this issue for me. I have not tested it very widely but it worked on the site I was building quite well.
#4
Gosh yes.
That does look like a bug - and a fix for it!
Good catch hussainweb !
It's not the same issue that we are looking for a fix for - but it is certainly relevant.
Our issue is that the filename extension is false if we switch formats.
#5
This is now in 7.x-1.x dev and 6.x-2.x dev
#6
Automatically closed -- issue fixed for 2 weeks with no activity.
#7
And what does it happen if the under color is set to "transparent" ???
#8
It seems that the module has been rebuild. The problem is back that a conversion to png results in big files and a .jpg extension.
#9
As far as I'm concerned I think the problems we have here are:
"Silent" Change of format
If an effect adds transparency to an image and the user wants to save that, it should force the output to a format that supports transparency. It is perfectly normal to use transparency during the processing but finish with an image without transparency. So
an effect doing this automatically as a by-effect is a bug in my opinion.
This part will be solved in this module.
Extension not changed
This is how image styles work and cannot be changed by this module that only adds additional effects. I would like to see this solved in Drupal core as well, but don't think it will be that easy as it will be difficult to get forth and back from image name to name of the processed image without actually applying the effects. So it won't be possible to theme the link without applying the efect unless we add some change notificating hooks/callbacks like the "dimensions callback in hook_image_effect_info.
Note that all modern browsers are capable of handling these cases and thus there is no real need for this other that user confusion or local image handling tools (that don't have the mime-type header but operate on the extension).
So this part will not be solve by this module. Feel free to post an issue in Drupal core (or back link if already existing) for this part of the problem.
#10
Agreed, it's an issue I'm unhappy about, but can't see a way through without major refactoring of image derivative building at core.
Either
* every call to a cached image has to run the processes in the background to detect if the file format/extension should change as a result of one of our processes and rewrite the resulting URL accordingly = major inefficiency for an edge case = silly.
* we make a semaphore/note that when rebuilding the URL the filepath is different = significant work in core for an edge case + busy-work = bad idea
* or ??
* or at least sort out less huge file sizes for remade PNGs and live with the incorrect file extension.
Current situation has a false file extension, but browsers deal with it. It feels dirty, but I can't solve it.
I still want to believe that PNG encoding probably has a flag that will not explode jpeg file sizes to 10 x like it currently does, but I've not been able to find that flag in the current GD toolkit.
If someone can suggest how to add a compression parameter to PNGs, that would be hugely helpful. But the false extension thing would need to be solved by a significant rewrite/elternative to core image derivative path rewriting that doesn't seem like a good use of time.
Aside : although MUCH of the original work for imagecache actions was directed towards emulating transparency on jpegs, even the work done here ran into the filesize issue. Eventually we did some rude hacks and used *flash* embeds to replace the expensive transparent overlays. I fought against it for a while but my design partner proved it just fecking worked better and smaller than anything I could invent.
Covered here http://drupal.org/node/267393 ( see "Clutter" )
#11
PNG compression is e.g. explained here: Imagemagick
GD can do this as well but uses 2 separate parameters for that (quality and filter, should read compression and filter). I seem to recall that 95 gave me best results in an earlier project, but the first visitor to hit the image might notice some delay. Anyway, you won't really save on file size with these settings.
What did help me more was reducing the color depth which allows for much higher compression ratio's. But this would be a separate effect and I am not sure that GD can do this, perhaps imagetruecolortopalette can.
#12
I removed the "silent change format" from the "Image mask" effect. I could not find it on other canvas actions though. perhaps that was different on earlier versions.
So if you are relying on the transparency being available in your end result, add a separate "Change file format" effect to your style.
#13
Automatically closed -- issue fixed for 2 weeks with no activity.