sxiv - Simple image viewer written in C

ber_t · 2011-02-26 21:44:56

Version 0.7 is out.

New:

- Thumbnail support
- Sort directory entries when using -r
- Do not center big images

The last two minor changes are for you, Ledti.

sironitomas · 2011-02-27 01:03:14

ber_t wrote:

Version 0.7 is out.
New:
- Thumbnail support
- Sort directory entries when using -r
- Do not center big images
The last two minor changes are for you, Ledti.

Trying version 0.7. Seems that everything is working fine.
A command line option to start in presentation mode (with interval as argument), would be great.

Your work is very appreciated.

Regards!

Ledti · 2011-02-27 07:23:21

ber_t wrote:

Version 0.7 is out.
New:
- Thumbnail support
- Sort directory entries when using -r
- Do not center big images
The last two minor changes are for you, Ledti.

Whoa! Thanks for implementing those. I didn't expect a response for a while.

I actually have two final suggestions, one of which I noticed earlier; the first is another enhancement to the recursive flag which would make it work when opening an image directly:

$ ls /path/to/
001.jpg 002.jpg 003.jpg 004.jpg 005.jpg

$ sxiv -r /path/to/003.jpg

^ Which would order all five images and focus on 003.jpg. This would make -r play nice with file managers and mimeo/mimeopen.

The second suggestion is more of a personal preference: I think the PageUp/PageDown keys would be more relevant than Backspace/Space for viewing images as PageUp/PageDown are generally right next to the arrow keys (panning).

ber_t · 2011-02-27 13:04:09

ber_t wrote:

Dieter@be wrote:
ber_t wrote:
I'll add this to the todo list and will look into it.
or better: update the EXIF data that defines the rotation.
assume sxiv supports exif
Using the EXIF tag seems to be the only reasonable way. There's no easy possibility to tell Imlib2 what quality to use when writing a file, so it would be a really bad idea to use it's functionality to write files. I also looked into jpegtran, but it didn't work very well for lots of my test images.
So I'll have a look at libexif. Maybe I'll use it to automatically rotate/flip images based on the current tag and to update the tag whenever a jpeg file is rotated.

It's definitely not coming. Depending on libexif is strcitly against the suckless approach, as libexif itself depends on glibc.

sironitomas wrote:

A command line option to start in presentation mode (with interval as argument), would be great.

Right now there's no slideshow support and I'm not really planning to add it.

Ledti wrote:

I actually have two final suggestions, one of which I noticed earlier; the first is another enhancement to the recursive flag which would make it work when opening an image directly:
$ ls /path/to/
001.jpg 002.jpg 003.jpg 004.jpg 005.jpg

$ sxiv -r /path/to/003.jpg
^ Which would order all five images and focus on 003.jpg. This would make -r play nice with file managers and mimeo/mimeopen.

The -r flag behaves in a standard-like way, it recursively reads directories given on the command line. The thing you're asking for seems a bit awkward, other users would not expect such behaviour.

Ledti wrote:

The second suggestion is more of a personal preference: I think the PageUp/PageDown keys would be more relevant than Backspace/Space for viewing images as PageUp/PageDown are generally right next to the arrow keys (panning).

It should be relatively easy to change sxiv's keyboard mappings, please have a look at on_keypress() in main.c...

milomouse · 2011-02-27 13:16:10

i actually like the default keybindings. it's like i already knew how to do everything first try. fantastic program; can't believe i haven't tried this before. almost ready to replace gliv. much appreciation, ber_t.

tzervo · 2011-02-28 21:25:23

ber_t wrote:

It's definitely not coming. Depending on libexif is strcitly against the suckless approach, as libexif itself depends on glibc.

Pity, it could be so convenient... but you're right. I will probably use convert (imagemagick) for that. Once more, cheers for the excellent app.

sironitomas · 2011-03-08 16:04:21

I have noticed sxiv is faster. Have you coded any performance improvements?
If not, it might be my processor running faster due to a possible microcode update.

Thanks!

Army · 2011-03-08 17:46:38

Might be cause of the update from libjpeg to libjpeg-turbo. Do you use [testing]?

sironitomas · 2011-03-08 18:53:30

Army wrote:

Might be cause of the update from libjpeg to libjpeg-turbo. Do you use [testing]?

No, I'm using the stable repo, but now you've mentioned it, I'll try libjpeg-turbo from [testing].

EDIT
It turns out I am actually using libjpeg-turbo. Checking in my pacman log, it replaced libjpeg a few days ago. That day, the package must have been moved from [testing] to [extra]. Thanks for the info!

Last edited by sironitomas (2011-03-08 19:00:04)

Army · 2011-03-08 20:42:57

Oh it's already in [extra]?!?! I thought there were several problems with it ... strange.

Something else:
Just now I tried to modify a perl script called xkcd (http://aur.archlinux.org/packages.php?ID=45049) to use sxiv. I managed to get it to work (I have no idea how perl works), but I get this error message

sxiv: warning: could not open file: http://imgs.xkcd.com/comics/server_attention_span.png
sxiv: no valid image filename given, aborting

Seems like sxiv cannot open files from the internet. It works fine with feh.

This isn't supposed to be a "pleeeeeeease include this feature", I only wanted to ask if it's possible without making sxiv bloated. I think having sxiv as a picture viewer would be pretty cool. Of course it can always be solved by something like

wget -O /tmp/pic http://imgs.xkcd.com/comics/server_attention_span.png
sxiv /tmp/pic

in case it's not being implemented, so no hard feelings then

Stebalien · 2011-03-08 20:54:02

Adding the ability to read from stdin would be even better. This would require no http/networking libraries and would allow for the following:

wget -O - http://imgs.xkcd.com/comics/server_attention_span.png | sxiv

ber_t · 2011-03-08 22:29:13

Stebalien wrote:

Adding the ability to read from stdin would be even better. This would require no http/networking libraries and would allow for the following:
wget -O - http://imgs.xkcd.com/comics/server_attention_span.png | sxiv

Imlib2 does not support opening an image from memory. I could use a fifo, but some image loaders used by imlib need to seek and would therefore fail when used on a fifo.
So the only real possibility for this would be writing the file to disk and then loading it with imlib, which I doubt you really want me to do.
And I also do not consider adding http support, because I think a little two-liner like the one Army posted is the best way to go -- it follows the unix philosophy! And as Army also already mentioned: this would be bloat. It's exactly one of the things that I didn't like about feh and that pushed me to write sxiv in the first place.

Army · 2011-03-09 01:50:17

ber_t wrote:

And I also do not consider adding http support, because I think a little two-liner like the one Army posted is the best way to go -- it follows the unix philosophy! And as Army also already mentioned: this would be bloat. It's exactly one of the things that I didn't like about feh and that pushed me to write sxiv in the first place.

Ok, since I already pointed it out by myself, I agree!

There's something else I ran into the other day:

I opened a png file with transparency. Sxiv's default background is grey, it switches to black at fullscreen. Now, my transparent png file has something black and something black with 20% opacity, hence grey. Watching it with the grey background is ok, as long as the grey colors aren't the same. The black color is perfectly visible. Now switching to fullscreen with the black background, there's nothing I can see.

Of course it's not an every day situation that one opens files with transparency. But I think for an image viewer it's better to NOT support transparency. Is it possible to always make the background of an image white, so in case the image is transparent we get a white background? That doesn't mean the main color of sxiv's background has to be always white, that's not what I mean.

To make sure you understand what I want, I'd recommend 3 layers: bottom: grey/black background of sxiv, middle: white layer with the size of the image, top: the image.

Once again, sxiv should stay unbloated / bloat-free, if imlib doesn't support this or something like that, forget it, since >99% of all images aren't transparent.

Kein Stress!

ber_t · 2011-03-09 10:38:11

Army wrote:

To make sure you understand what I want, I'd recommend 3 layers: bottom: grey/black background of sxiv, middle: white layer with the size of the image, top: the image.

I did exactly this, changes can be found in the current head.

Now I'm waiting for the first guy showing up here and claiming, that a checker-board would be even better. Dann wird's wohl stressig...

Army · 2011-03-09 10:49:28

Ok, tested it and it's perfectly fine for me, merci beaucoup (now every language I speak is covered )

Last edited by Army (2011-03-09 10:49:47)

sironitomas · 2011-03-10 19:30:24

Hey, I think you might want to add a checker-board texture for the alpha channel!

Just kidding . It works well the way it is!

Saludos

JohannesSM64 · 2011-03-11 17:52:47

Nice viewer, replaced feh for me too.

sironitomas · 2011-03-12 06:42:35

How hard would be to implement a live seek of folder files when the option -r is given?

For example: I'm transfering lots of photos (i.e. with nfs) to a folder called photos, and in the meantime I execute:

sxiv -rt ~/photos

Would be great if the "just copied" photos could be seen by sxiv without restarting it.

Regards!

PS: For some reason, I have the feeling that my request is somehow going against Arch and Unix philosophy. Am I wrong?

Last edited by sironitomas (2011-03-12 06:50:15)

gorilla · 2011-03-12 13:23:02

sironitomas wrote:

How hard would be to implement a live seek of folder files when the option -r is given?
For example: I'm transfering lots of photos (i.e. with nfs) to a folder called photos, and in the meantime I execute:
sxiv -rt ~/photos
Would be great if the "just copied" photos could be seen by sxiv without restarting it.
Regards!
PS: For some reason, I have the feeling that my request is somehow going against Arch and Unix philosophy. Am I wrong?

Well, where is the problem with just restarting it after all your images are copied? It's just one keystroke in your terminal...

In my opinion a live-search is neither nessesary nor does it suck-less...

ber_t · 2011-03-12 13:27:58

sironitomas wrote:

How hard would be to implement a live seek of folder files when the option -r is given?
...
PS: For some reason, I have the feeling that my request is somehow going against Arch and Unix philosophy. Am I wrong?

It's only against the suckless approach of sxiv. A "live seek" is definitely not coming, maybe I will make the 'r' (reload) key mapping work in thumbnail mode to reread the directory contents. But such a feature would make the thumbnail mode much more complex and is only equivalent to restarting sxiv. And because I'm writing my diploma thesis right now, I don't have the time to implement it in the forseeable future.

EDIT: gorilla already made the same points in less time.

Last edited by ber_t (2011-03-12 13:32:02)

dlz · 2011-04-04 07:20:32

i really like sxiv. for me it replaces feh. but i had to change the source code, otherwise it was unuseable for me.

the scenario:
a directory containng 70 jpg files each with 12 megapixel and 1,5 to 2 megabytes in size.
command i use: sxiv *.jpg

the problem:
this takes more than half a minute before the first image shows up.
if the directory contains only 1 image, then there is no waiting time.

the reason:
sxiv-0.7/main.c:main calls function sxiv-0.7/main.c:check_append to determine if the file is loadable by imlib
this is done by calling sxiv-0.7/image.c:img_check
but there each file is loaded by imlib just to check if this causes an error.
imlib_load_image is too slow.

the fast solution:
in sxiv-0.7/main.c:check_append change "img_check(filename)" to "1 == 1"
so no img_check is called at all.

i think there is no reason to check if a file is loadable before it is loaded for display.

for the above mentioned scenario the thumbnail mode is also unuseable slow. but i see no way to solve this.

JackH79 · 2011-04-04 10:23:53

Hey, fantastic viewer. I think it's going to replace some of my other picture viewers (I've never found one that does everything I want ;-) ). So, thanks heaps for that, ber_t. Well appreciated.

PS: Do you actually have a preferred way to pronounce it? Es-ex-i-vee is a bit of a tongue twister. I'm trying to decide on either 'skiff' or 'skive', but maybe it makes more sense when pronounced German? Cheers

ber_t · 2011-04-04 18:53:17

dlz wrote:

the fast solution:
in sxiv-0.7/main.c:check_append change "img_check(filename)" to "1 == 1"
so no img_check is called at all.
i think there is no reason to check if a file is loadable before it is loaded for display.

I used this to remove all non-image files from the filelist at startup. The images were only loaded, no heavy rendering took place. But I was aware of the speed penalties for large images introduced by this.
You kind-of convinced me to remove this check. In the current head, the files are only checked for read access. Non-image files get displayed by a grey replacement icon.
Let us see, if others complain because they prefer it the old way -- the new behaviour is not so nice, when sxiv is used with the -r switch on a directory structure containing lots of non-images files.

EDIT: What's strange: I just tested the version from head against a prior version, to see how big the speed improvement is, and there is no improvement at all. It doesn't matter how many files I used or how big these files were. Seems like the imlib_load_image function doesn't actually load the whole image into memory.
dlz, could you please give some details about the hardware you run sxiv on?

JackH79 wrote:

PS: Do you actually have a preferred way to pronounce it? Es-ex-i-vee is a bit of a tongue twister. I'm trying to decide on either 'skiff' or 'skive', but maybe it makes more sense when pronounced German? Cheers

I'm pronouncing it es-ex-i-vee. Even in German, there's no nice way to pronounce it .I didn't find a nicer name, I prefered xee, but it is already taken by some mac app.

Last edited by ber_t (2011-04-04 19:46:18)

dlz · 2011-04-04 20:11:42

ber_t wrote:

EDIT: What's strange: I just tested the version from head against a prior version, to see how big the speed improvement is, and there is no improvement at all. It doesn't matter how many files I used or how big these files were. Seems like the imlib_load_image function doesn't actually load the whole image into memory.
dlz, could you please give some details about the hardware you run sxiv on?

i'm sorry. you are right!
i have tested my problem on different image sets, but there are all from the same provider.
now i tested 100 jpg images in directory from a 10 megapixel camera. and indeed the non-modifyed sxiv works fast.
i discovered that imlib has a problem with large jpg that are interlaced.
so. no need to edit your code.
it's kind of a special thing with rare interlaced jpgs.

sorry.

ber_t · 2011-04-04 22:50:44

I used strace to get an idea how much data imlib_load_image reads, when used like in img_check, and it seems it only reads a small amount of 4k-byte-blocks per image. So the speed penalty is really small, considering the huge amount of files each X-app has to read at startup.

I've reversed the change; next time I will look more deeply into an issue before changing the code...

dlz, thanks for giving feedback, especially as you seem to have registered to the forums only to report it.

Arch Linux

#76 2011-02-26 21:44:56

Re: sxiv - Simple image viewer written in C

#77 2011-02-27 01:03:14

Re: sxiv - Simple image viewer written in C

#78 2011-02-27 07:23:21

Re: sxiv - Simple image viewer written in C

#79 2011-02-27 13:04:09

Re: sxiv - Simple image viewer written in C

#80 2011-02-27 13:16:10

Re: sxiv - Simple image viewer written in C

#81 2011-02-28 21:25:23

Re: sxiv - Simple image viewer written in C

#82 2011-03-08 16:04:21

Re: sxiv - Simple image viewer written in C

#83 2011-03-08 17:46:38

Re: sxiv - Simple image viewer written in C

#84 2011-03-08 18:53:30

Re: sxiv - Simple image viewer written in C

#85 2011-03-08 20:42:57

Re: sxiv - Simple image viewer written in C

#86 2011-03-08 20:54:02

Re: sxiv - Simple image viewer written in C

#87 2011-03-08 22:29:13

Re: sxiv - Simple image viewer written in C

#88 2011-03-09 01:50:17

Re: sxiv - Simple image viewer written in C

#89 2011-03-09 10:38:11

Re: sxiv - Simple image viewer written in C

#90 2011-03-09 10:49:28

Re: sxiv - Simple image viewer written in C

#91 2011-03-10 19:30:24

Re: sxiv - Simple image viewer written in C

#92 2011-03-11 17:52:47

Re: sxiv - Simple image viewer written in C

#93 2011-03-12 06:42:35

Re: sxiv - Simple image viewer written in C

#94 2011-03-12 13:23:02

Re: sxiv - Simple image viewer written in C

#95 2011-03-12 13:27:58

Re: sxiv - Simple image viewer written in C

#96 2011-04-04 07:20:32

Re: sxiv - Simple image viewer written in C

#97 2011-04-04 10:23:53

Re: sxiv - Simple image viewer written in C

#98 2011-04-04 18:53:17

Re: sxiv - Simple image viewer written in C

#99 2011-04-04 20:11:42

Re: sxiv - Simple image viewer written in C

#100 2011-04-04 22:50:44

Re: sxiv - Simple image viewer written in C

Board footer