Re: [Thunar-dev] thunar-volman
On Fri, 12 Jan 2007 00:29:56 +0100, Benedikt Meurer <[EMAIL PROTECTED]> wrote: > > Xfburn on the other hand should provide options to start compiling an audio or > data CD/DVD, and it would be really nice to drop the Linux code from > Xfburn and do the device lookup using HAL (that would also allow to pass > the HAL UDI of the newly inserted disc). Not high priority, of course, I > just thought I should mention that. I'm currently trying to port Xfburn to libburn (libburnia.pykix.org), libburn should provide the multi-platform support (don't known its current state). For the command line options, you have filled an enhancement request, i don't forget it. I just want to have a running app before adding command line parameters that could end up changing every two commits ;) -- Jean-Francois Wauthy <[EMAIL PROTECTED]> ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
Re: [Thunar-dev] A Standard for Thumbnailers
On 1/12/07, Benedikt Meurer <[EMAIL PROTECTED]> 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. > does it also accept PPM? -e Extract the camera-generated thumbnail, not the raw image. You'll get either a JPEG or a PPM file, depending on the camera. Jens -- Jens Luedicke web: http://perldude.de/ ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
Re: [Thunar-dev] A Standard for Thumbnailers
Erlend Davidson wrote: >>> However, thunar-vfs-pixbuf-thumbnailer-1 is optimised for this purpose >>> (uses the jpg resizing trick mentioned on the xdg mailing list) and >>> takes just 0.1 seconds to convert the jpeg to a png - but I can't pipe >>> the output from dcraw into it. For this reason would it be possible to >>> add an option to thunar-vfs-pixbuf-thumbnailer-1 which enables it to >>> take the input image from stdin? >>> >> The thunar-vfs-pixbuf-thumbnailer doesn't use any special tricks, it >> just a wrapper for GdkPixbuf routines. Check the source it's really simple. > I see that now. So GdkPixbuf is faster than convert? Is it using that > DCT technique for resizing? 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. Benedikt ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
Re: [Thunar-dev] A Standard for Thumbnailers
Benedikt Meurer wrote: > Erlend Davidson wrote: > >> However, thunar-vfs-pixbuf-thumbnailer-1 is optimised for this purpose >> (uses the jpg resizing trick mentioned on the xdg mailing list) and >> takes just 0.1 seconds to convert the jpeg to a png - but I can't pipe >> the output from dcraw into it. For this reason would it be possible to >> add an option to thunar-vfs-pixbuf-thumbnailer-1 which enables it to >> take the input image from stdin? >> > > The thunar-vfs-pixbuf-thumbnailer doesn't use any special tricks, it > just a wrapper for GdkPixbuf routines. Check the source it's really simple. I see that now. So GdkPixbuf is faster than convert? Is it using that DCT technique for resizing? ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
[Thunar-dev] thunar-volman
For the brave: I've just imported an initial version of the thunar-volman, which provides automatic handling of removable drives and media for Thunar. This requires a really recent version of Thunar. It's designed to look and behave similar to gnome-volume-manager, tho of course, it's not bug-compatible. ;-) The difference (advantage) to gnome-volume-manager is that it (a) doesn't require GNOME and (b) doesn't require an additional daemon. To avoid the daemon, Thunar was extended to act as a proxy between HAL and thunar-volman, which means whenever HAL reports a new device, thunar-volman is invoked to handle it according to it's configuration. That was pretty simple, because Thunar has to monitor HAL events anyway. This is of course optional. Consider thunar-volman experimental. I've tested it with HAL on FreeBSD and so far that seems to work pretty well. One problem I noticed however: Our applications (i.e. Xfmedia, Xfburn) that would be spawned by the volume manager, don't provide the necessary command line switches (i.e. Xfmedia needs a command line switch to accept the UDI and/or the device file path of an audio CD). Xfburn on the other hand should provide options to start compiling an audio or data CD/DVD, and it would be really nice to drop the Linux code from Xfburn and do the device lookup using HAL (that would also allow to pass the HAL UDI of the newly inserted disc). Not high priority, of course, I just thought I should mention that. Otherwise, give it a go, if you think it's useful... http://svn.xfce.org/svn/goodies/thunar-volman/trunk/ HTH, Benedikt ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
Re: [Thunar-dev] A Standard for Thumbnailers
Erlend Davidson wrote: > However, thunar-vfs-pixbuf-thumbnailer-1 is optimised for this purpose > (uses the jpg resizing trick mentioned on the xdg mailing list) and > takes just 0.1 seconds to convert the jpeg to a png - but I can't pipe > the output from dcraw into it. For this reason would it be possible to > add an option to thunar-vfs-pixbuf-thumbnailer-1 which enables it to > take the input image from stdin? The thunar-vfs-pixbuf-thumbnailer doesn't use any special tricks, it just a wrapper for GdkPixbuf routines. Check the source it's really simple. > Erlend Benedikt ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
Re: [Thunar-dev] A Standard for Thumbnailers
Benedikt Meurer wrote: > Stanislav Brabec wrote: > > BTW: I fail to see the problem here. How often do people regenerate > thumbnails that +1 or 2 seconds for 40 JPEGs makes a difference? > It's important because it gives an impression of slowness and unresponsiveness. And you rarely generate them, but you import pictures from digital cameras rather often. >>> Here the I/O is definitely the limiting factor from my experience. >>> Accessing data on digital cameras is very slow with the models I've tested. >>> >> No, for digital cameras the limiting factor is the stupidity of the >> thumbnailer. >> >> Small jpeg-EXIF-embedded thumbnail is most often stored in first few >> blocks of the image. You can create thumbnail much faster than you can >> load the image. >> >> Mid-size jpeg thumbnail (typically 640x480) is typically stored in last >> few blocks of the image and you need only few additional seeks to find >> exact start point. You can again create thumbnail faster than to load >> image. >> >> You can try to compare my dcraw-thumbnailer with Nautilus jpeg >> thumbnailer to see the difference: >> http://www.penguin.cz/~utx/gnome-dcraw >> Note that this page also contain "classical" thumbnailer, which reads >> the whole file and scales it down by its own. >> > > Can we perhaps use this trick for the dcraw thumbnailer? Jens/Erlend? Well, I don't really know what the trick is... I've looked at the page (http://www.penguin.cz/~utx/gnome-dcraw) and I think it must be for an older version of dcraw, since 1. dcparse doesn't seem to output a thumbnail - just the metadata about the raw format, and 2. they seem to use "dcraw -h -w rawfile" to produce a thumbnail - that's extremely slow (3-4 seconds) for thumbnail creation. The option -e option to dcraw extracts just the thumbnail from the raw image (this was produced by the camera at the time the photo was taken). This is extremely quick: 0.013 seconds. The problem is convert taking ages to resize and change the image to png (take about a second or more). However, thunar-vfs-pixbuf-thumbnailer-1 is optimised for this purpose (uses the jpg resizing trick mentioned on the xdg mailing list) and takes just 0.1 seconds to convert the jpeg to a png - but I can't pipe the output from dcraw into it. For this reason would it be possible to add an option to thunar-vfs-pixbuf-thumbnailer-1 which enables it to take the input image from stdin? Erlend ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
Re: [Thunar-dev] A Standard for Thumbnailers
Stanislav Brabec wrote: BTW: I fail to see the problem here. How often do people regenerate thumbnails that +1 or 2 seconds for 40 JPEGs makes a difference? >>> It's important because it gives an impression of slowness and >>> unresponsiveness. And you rarely generate them, but you import pictures >>> from digital cameras rather often. >> Here the I/O is definitely the limiting factor from my experience. >> Accessing data on digital cameras is very slow with the models I've tested. > > No, for digital cameras the limiting factor is the stupidity of the > thumbnailer. > > Small jpeg-EXIF-embedded thumbnail is most often stored in first few > blocks of the image. You can create thumbnail much faster than you can > load the image. > > Mid-size jpeg thumbnail (typically 640x480) is typically stored in last > few blocks of the image and you need only few additional seeks to find > exact start point. You can again create thumbnail faster than to load > image. > > You can try to compare my dcraw-thumbnailer with Nautilus jpeg > thumbnailer to see the difference: > http://www.penguin.cz/~utx/gnome-dcraw > Note that this page also contain "classical" thumbnailer, which reads > the whole file and scales it down by its own. Can we perhaps use this trick for the dcraw thumbnailer? Jens/Erlend? Benedikt ___ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev
