Benedikt Meurer wrote: > Erlend Davidson wrote: > >>> Checking my own source again... you should be able to store the >>> thumbnail as JPEG. thunar_vfs_thumb_factory_generate_thumbnail() will >>> also accept JPEGs and convert them to PNGs internally. >>> >> Ok, I've tested this - it doesn't work. Thinking about it this makes sense: >> thunar invokes the raw-thumbnailer, saying "produce a thumbnail of ifile >> called ofile". ofile is a png image, or at least an image with a png >> extension. But if the thumbnailer gives a .png file in which the format >> is actually jpg/ppm then pixbuf will get confused. >> > > GdkPixbuf does content sniffing, so it'll properly detect the JPEG/PNM > content. Also note that the extension of the ofile is not .png. > > >> Also, the >> raw-thumbnailer script won't get the chance to resize the image - so >> it'll be on the order 3000x2000 pixels! >> > > Uhm, that's HUGE. Better scale that down in a separate process to avoid > growing Thunar's heap. And then we're back to the orignal problem - manipulation I do with 'convert' is very slow. The options are probably to: 1. write a version of dcraw that outputs small png thumbnails instead of huge jpeg ones 2. have a small program like thunar-vfs-pixbuf-thumbnailer-1 that can take input from stdin (as thunar-vfs-pixbuf-thumbnailer-1 is at least 10x as fast as convert).
The latter would be more useful I think - a kind of faster drop-in replacement for convert that only does thumbnails, although am I correct in saying pipes (|) are relatively slow? _______________________________________________ Thunar-dev mailing list [email protected] http://foo-projects.org/mailman/listinfo/thunar-dev
