[Typo3-dev] RFE: Remove profile data from images

[Jose Antonio Guerra]

Hi Martin				

There's a way of using IM to fix those images. Here's the commandline to get ImageMagick removing that metadata:

  convert <srcImg>+profile IPTC <dstImg>

This switch works correctly on IM 5, not in 4.2.9 .  

It would be a nice idea to integrate the switch on the TYPO3-IM workflow, so all the processed images have all the metadata removed. That's less kilobytes and getting rid of the MSIE bug...

BTW, the bug is still alive on MSIE 6

In our case, we have a little bash script to "clean" all the images on the TYPO3 dirs when we detect that there's a buggy image.  But, as you can imagine, this solution is quite far from perfect.

- Jose Antonio Guerra (balderiano)

-----------------------
This thread is located in the archive at this URL:
http://typo3.org/documentation/mailing-lists/dev-list-archive/thread/59487/
					
> Karsten Dambekalns wrote:
> > Hi,
> >
> > I'd like to propose a small enhancement to TYPO3's image handling
> > "chain of command".
> >
> > I today had to fight images not showing on MSIE under
> > Windows. Pfff. It turned out that the problem was caused by MSIE
> > choking on XML data embedded into a profile block of the JPEG files
> > (Photoshop 7 on MacOS X does this).
> >
> > Running all images through
> >  jpegtran -copy none
> > fixed the problem.
> >
> > Would it be a lot of work to add a switch to TYPO3 that makes it
> > remove all profile information when transforming images for display?
> 
> We had this idea already on the list, though the proposed solution was
> to use Imagemagick or GD2 to do the job (cannot remember right now).
> 
> Anyway, nobody with programming skills thought it was worth the hassle ;-)
> 
> Besides when would you apply the removal? While the image comes into
> upload? Certainly not, as it would change the image. When it comes into
> the temp directory? Fine, but you don't want to have ALL images
> duplicated in the temp directory. Sidenote: IMHO storing the images all
> in one dir. isn't such a good ideas as some filesystems have performance
> penalties with very large dirs.
> 
> Masi
> 
> _______________________________________________
> Typo3-dev mailing list
> Typo3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
>