sxiv - Simple image viewer written in C

drtebi · 2015-01-05 12:09:51

ber_t,

I didn't realize that you are the actual developer of sxiv (although I had the suspicion). Fantastic job.

There is one thing I would like to get some help with though. I have a high-resolution screen (an old IBM T221 with 3840x2400 pixels), and although sxiv runs perfectly fine with it, I cannot figure out how to get the font of the image info on the bottom to a bigger size.

I read the documentation and used xlsfonts, but I just cannot figure it out...

Could you give me a clue on how to e.g. make it four times as large?

ber_t · 2015-01-05 13:22:04

@drtebi: You could change the BAR_FONT in config.h to something like "-*-fixed-medium-r-*-*-20-*-*-*-*-100-*-*". Alternatively, use xfontsel (package xorg-xfontsel) to look for a font of your liking and use the font selection string from the top as the BAR_FONT.

drtebi · 2015-01-07 13:28:19

ber_t wrote:

@drtebi: You could change the BAR_FONT in config.h to something like "-*-fixed-medium-r-*-*-20-*-*-*-*-100-*-*". Alternatively, use xfontsel (package xorg-xfontsel) to look for a font of your liking and use the font selection string from the top as the BAR_FONT.

That's a lot better, thank you. I would try other fonts, but I just have a hard time "picturing" them--the output of xlsfonts doesn't help much without an idea of what the fonts actually look like.

karol · 2015-01-07 14:09:03

Try xfontsel.

robertpeston · 2015-01-08 13:08:12

That change sounds good. I found the performance to be better when the thumbs were held in memory though.

I'm definitely having issues where thumbnails are not cached. All files larger than thumbnails and I've paged through the directory to display them all. I'm confused as to why this might be.

ber_t · 2015-01-09 08:01:11

robertpeston wrote:

I'm definitely having issues where thumbnails are not cached. All files larger than thumbnails and I've paged through the directory to display them all. I'm confused as to why this might be.

Please try to reproduce this reliably, then post the following information, preferably as a new ticket in the Github issue tracker:

- sxiv version
- thumb_sizes array from config.h if changed
- upload one image that was not cached and is larger than the biggest size in thumb_sizes
- do not use -q, paste sxiv's output if not empty

likytau · 2015-01-16 23:33:43

Hi, I recently encountered a hard-to-reproduce bug with the image rotate (not view rotate) functionality interacting with symlinks to images,
amounting to a) rotation 'apparently' doesn't work (it does, but sxiv absolutely refuses to refresh the image for some reason -- looking at symlink target rather than specified path?), and b) symlink is destroyed -- the symlink is replaced with the rotated image, rather than the symlink target.

Haven't filed this on the bug tracker yet due to aforementioned difficulty with reproducing the exact conditions, but it did have a simple and logical fix that you may want to add to your key-handler script:
in the rotate() function, before the 'case $(file [...]` line, add a line 'file=$(realpath "$file")' to ensure you always operate on resolved paths, not paths to symlinks.

the tag_add and tag_del functions (and any other functions that directly modify files) may also benefit from this, if you use them. You can transform the whole list of files (as needed for these functions) using 'tr \\n \\0 | xargs -0 realpath > "$TMPFILE"`

realpath is part of coreutils, so it should be completely fine to depend on it.

EDIT:

On a completely different subject, I'm looking into implementing literal thumbnail zooming -- eg. your max thumbnail size is 200, but you can zoom beyond this, up to 300% zoom or 4 thumbnails fitting in the window, whichever comes first. The implementation will end up at https://github.com/0ion9/sxiv when it's done.. Right now I'm having difficulty figuring out a suitably 'suckless' way for this to work, so any discussion or suggestions would be appreciated.

(technical thoughts follow)

All of the references to thumb_sizes are in thumbs.c, fortunately. Each level of thumbs appears to have an image individually cached (even though for levels lower than the max, these are just shrunken crops of the max size thumbnail). Keeping this in mind, it would be silly to cache the upscaled versions. Instead, zoom would need to be a separate variable that the zoom actions would effect when the thumbnail size index is already at max. tns_render would then use this zoom factor, particularly on lines 457,458 (layout thumbs in a grid), similarly on 472,473, and 475 to modify the actual drawn size of the image. Not sure what to do with tns->dim assignment in tns_zoom(). Maybe this can be assigned directly and tns_render() can be left alone? I find the fact that the border width plus some compulsory padding is included in tns->dim a little confusing.

EDIT2:

I have a rather hacky proof of concept: diff here. It simply blows up thumbnails 2x when the maximum thumb size is reached (defined in MAGIC_BREAKPOINT as 192, as this is my maximum thumb size, --> results in 384x384 thumbnails)

EDIT3:

Currently considering something like this for the configuration:

 /* zoom levels usable when zooming >= max thumbnail size */
 static const float thumbnail_zoom_levels[] = {
  100.0, 200.0, 300.0, 400.0, 500.0, 600.0
 };
 
 /* pixelize if thumbnail zoom >= this value */
 static const float THUMBNAIL_PIXELIZE_AT = 300.0;

possibly removing the latter setting and just hardcoding it at 201%.

Last edited by likytau (2015-01-17 03:17:18)

likytau · 2015-01-17 05:33:51

There is now a working, non-hacky implementation of thumbnail zooming at
https://github.com/0ion9/sxiv/commit/5e … e7b4924fc7

The commit message describes how it works pretty clearly:

Allow zooming thumbnails beyond max size.
When size reaches the maximum set in thumb_sizes, further zoom operations blow up the thumbnail
according to the `thumbnail_zoom_levels` array.
If the thumbnail zoom level exceeds THUMBNAIL_PIXELIZE_AT (default value 201),
thumbnail is rendered without antialiasing; lower levels are rendered with antialiasing.
An example of how it works:
Suppose you have these settings:
  thumb_sizes[] = { 80, 144, 192 };
  thumbnail_zoom_levels[] = { 100, 200, 300, 400};
  THUMBNAIL_PIXELIZE_AT = 201;
Then you can view thumbnails at:
80px, 144px, 192px, 384px, 576px, 768px
At 384px, antialiasing will be enabled (200% zoom < 201);
At 576px and 768px, antialiasing will be disabled.

Remaining issues:
* Cosmetically, I would prefer to reduce the amount of ((tns->w * zoom) / 100) type calculations in the code.
* Perhaps I should incorporate thumbnail-zooming into the tns_zoom() border-width calculation for greater visual consistency.
Currently the border width is the same for max(thumb_sizes) and 'zoomed-in thumbnail' levels. If someone reports an issue with this I might change it; otherwise, I'm not personally bothered by it.
* With a particularly small window, it is possible for the zoomed thumbnail to be larger than the window. This should probably be prevented (just don't allow the zoom if it would make thumbnails larger than the window) (EDIT: fixed.)

Surprisingly easy modification to do, much easier than I expected.

Last edited by likytau (2015-01-17 06:18:05)

ber_t · 2015-01-18 10:39:19

I've made sxiv pass the real paths of the files to the key handler, as sxiv already retrieves and uses them for other operations, too. This should fix your issue, likytau.

Regarding the thumbnail zooming: Why don't you simply use bigger thumbnail sizes?

likytau · 2015-01-18 11:26:10

ber_t wrote:

I've made sxiv pass the real paths of the files to the key handler, as sxiv already retrieves and uses them for other operations, too. This should fix your issue, likytau.
Regarding the thumbnail zooming: Why don't you simply use bigger thumbnail sizes?

That's a very helpful change, thanks -- I had to get the real paths for many operations to work correctly in my own keyhandler script, not only ones that modify the image file.

As for the thumbnail size change.. raising thumbnail size to 768 would bring average thumbnail size to 85k/thumb*, putting maximum size of ~/.cache/sxiv at ~37GB (total potential thumbnailees == ~1 million). My current cache has an estimated cap of 9GB, so that's roughly a 4x increase.

The current thumbnail size was also designed to montage well (192x192 * 4 * 4 -> 768x768, fits into most screens easily), but I guess I can change my montage setup to resize them.

I guess that's acceptable (leaves 98GB of my main 'partition' available), I'll do it.

* checked on a set of 1267 images, 679 of which got a thumb generated (the others used the image itself as the thumb)

EDIT: On a different topic, there is a patch here that people might find interesting. It frees up keys 0-9 for keyhandler usage by making Escape into a .. prefix key for entering prefixes. So, for example, if you want to go 100 images forward, you would enter 'Escape 1 0 0 n'. Note that this means you cannot use Escape as a normal keybinding, either in config.h or in your keyhandler script.
(ignore the Button2/ Button3 bit -- I should have put that in a separate commit, it just makes it so that button2 does the same thing as button3 in thumbnail view: toggle mark on the clicked image.)

Last edited by likytau (2015-01-20 02:01:37)

likytau · 2015-02-20 06:39:02

Hi, today I made a very simple patch. It alters the titlebar display in Image mode to only show the basename() of the current file, rather than the path passed to sxiv.
As I comment in the commit log:

Mostly, this info seems to just take up space without being useful.
Note that you can still see aforementioned path listed at the bottom of the screen in thumbnail mode if you actually need it.

Bert, feel free to grab this if you want. I -think- it's generally desirable behaviour, but you would know better than me.

sekret · 2015-03-29 08:38:58

How can I pass an image from STDIN to sxiv? I think this isn't possible, am I right?

Why am I asking?

Right now I'm forced to use feh

qrencode "$(xsel -o)" -o - | feh -Z --force-aliasing -

but I'd rather use sxiv for this!

karol · 2015-03-29 10:58:21

You can use

sxiv <options> "$(<other command> <options>)"

or

find -name "*.gif" | sxiv -i -

Last edited by karol (2015-03-29 11:02:52)

likytau · 2015-03-29 13:56:04

karol wrote:

You can use

sxiv <options> "$(<other command> <options>)"

or

find -name "*.gif" | sxiv -i -

Actually, if you read their post carefully, they literally want to pass an image -- not a path to an image, but actual image data -- on stdin to sxiv.

AFAIK sxiv does not support this.
(although personally I would say it's trivial to work around:

qrencode "$(xsel -o)" -o /tmp/qren-$$.png; sxiv /tmp/qren-$$.png

# or define a shell function that does this for you.

)

sxiv - appears to be equivalent to sxiv -i IFF no image paths are passed as arguments. I use it all the time. (with -i you can do both -- the paths from stdin is prepended to the list of paths from the commandline. This is fairly useless AFAICS, though.)

Last edited by likytau (2015-03-29 14:02:25)

sekret · 2015-03-30 07:49:30

@karol, like likytau said, those don't work unfortunately.

@likytau: Yes this workaround is easily done, that's right, but if I could do it right, I'd prefer to do it with stdin. Since sxiv doesn't seem to support it, I'll use the workaround, of course!

But now I saw, that sxiv doesn't allow me to disable anti-aliasing and "Fit image to window" with a switch (or whatever e.g. the -i in "sxiv -i" is called ...)

Smells like a feature request!

I know sxiv originally was intended to only get included what's absolutely necessary. Reading from stdin isn't! So I'm ok with this workaround, of course! But without the switches ... very uncomfortable! I know, hitting "Wa" is no biggie ... Aren't we all lazy?!

likytau · 2015-03-30 09:59:14

sekret wrote:

@likytau: Yes this workaround is easily done, that's right, but if I could do it right, I'd prefer to do it with stdin. Since sxiv doesn't seem to support it, I'll use the workaround, of course!

It should not be a notable concern, really.. tmpfs is normally really fast, so this is just a cosmetic wart.

But now I saw, that sxiv doesn't allow me to disable anti-aliasing
and "Fit image to window" with a switch (or whatever e.g. the -i in "sxiv -i" is called ...)

Are you aware you can configure the default setting for those in config.h?

I know, hitting "Wa" is no biggie ... Aren't we all lazy?!

You could always get xdotool to hit Wa for you (autodetect sxiv window, then send keys to it), if configuring no-aa and fit-image-to-window in config.h is not suitable.

Depending on your use case, you might also consider an adaptation of this patch useful: it provides a third AA setting, 'auto', which compares the zoom level against a threshold and enables AA if below the threshold, disables it otherwise.
Setting it to, say, 100, would mean zoomed-in (100%+) always gets no AA, while zoomed-out (<100%) always gets AA. My personal experience is that for most usages, I do not need to change this setting -- it just does what I want automatically.

Last edited by likytau (2015-03-30 10:04:27)

sekret · 2015-03-31 16:40:58

I know they are configurable in config.h, but usually I want sxiv to use anti-aliasing.

Thanks for the link to this patch, I'll check it out!

Unia · 2015-05-23 21:15:18

For those interested, I have just updated my Pango patch for sxiv:

https://github.com/Unia/sxiv/commit/2a3 … 5d0b86b87d

You can either grab it from ^ and apply it manually, or just clone my repo and build it from there.

doggone · 2015-05-24 06:48:37

Unia wrote:

For those interested, I have just updated my Pango patch for sxiv:
https://github.com/Unia/sxiv/commit/2a3 … 5d0b86b87d
You can either grab it from ^ and apply it manually, or just clone my repo and build it from there.

Great, thank you!

One bug I've noticed: when a picture is at less than 100% zoom, the text on the right gets cut off a little bit.

<100%
http://a.pomf.se/krqvak.png

100%
http://a.pomf.se/yaspkx.png

Unia · 2015-05-24 14:17:37

Hmm, I hadn't noticed that. It's on my list! (which is kind of long at the moment, so it might be a while before I get around to fixing it)

hobarrera · 2015-05-27 07:37:12

Is the pango patch planned to be merged upstream? Or will we have to apply and track manually?

Unia · 2015-05-27 10:25:38

You'll have to apply and track manually.

oneesama · 2015-07-03 05:10:44

I would like to load images from http like feh does:

feh http://i.imgur.com/9G42FCo.jpg

Is that possible with some bash hacking?

Last edited by oneesama (2015-07-03 05:12:17)

chickenPie4tea · 2015-07-03 09:04:20

anyone using a script with sxiv so that you could press a keybinding and the image being viewed would be uploaded to http://imageshack.com/ or some other online photo site?

progandy · 2015-07-03 09:36:01

chickenPie4tea wrote:

anyone using a script with sxiv so that you could press a keybinding and the image being viewed would be uploaded to http://imageshack.com/ or some other online photo site?

There is an example keyhandler script. Take that and add a key combination, that runs an uploader for e.g. imgur (AUR), clbin (AUR) or minus (https://pypi.python.org/pypi/minus/). The result can be displayed with e.g. dunst (dunstify/notify-send), dmenu, or Xdialog or zenity, you can even react to user input if you include some possible actions, e.g. copy to clipboard, in your GUI (not with notify-send, but with dunstify and everything else)

Arch Linux

#451 2015-01-05 12:09:51

Re: sxiv - Simple image viewer written in C

#452 2015-01-05 13:22:04

Re: sxiv - Simple image viewer written in C

#453 2015-01-07 13:28:19

Re: sxiv - Simple image viewer written in C

#454 2015-01-07 14:09:03

Re: sxiv - Simple image viewer written in C

#455 2015-01-08 13:08:12

Re: sxiv - Simple image viewer written in C

#456 2015-01-09 08:01:11

Re: sxiv - Simple image viewer written in C

#457 2015-01-16 23:33:43

Re: sxiv - Simple image viewer written in C

#458 2015-01-17 05:33:51

Re: sxiv - Simple image viewer written in C

#459 2015-01-18 10:39:19

Re: sxiv - Simple image viewer written in C

#460 2015-01-18 11:26:10

Re: sxiv - Simple image viewer written in C

#461 2015-02-20 06:39:02

Re: sxiv - Simple image viewer written in C

#462 2015-03-29 08:38:58

Re: sxiv - Simple image viewer written in C

#463 2015-03-29 10:58:21

Re: sxiv - Simple image viewer written in C

#464 2015-03-29 13:56:04

Re: sxiv - Simple image viewer written in C

#465 2015-03-30 07:49:30

Re: sxiv - Simple image viewer written in C

#466 2015-03-30 09:59:14

Re: sxiv - Simple image viewer written in C

#467 2015-03-31 16:40:58

Re: sxiv - Simple image viewer written in C

#468 2015-05-23 21:15:18

Re: sxiv - Simple image viewer written in C

#469 2015-05-24 06:48:37

Re: sxiv - Simple image viewer written in C

#470 2015-05-24 14:17:37

Re: sxiv - Simple image viewer written in C

#471 2015-05-27 07:37:12

Re: sxiv - Simple image viewer written in C

#472 2015-05-27 10:25:38

Re: sxiv - Simple image viewer written in C

#473 2015-07-03 05:10:44

Re: sxiv - Simple image viewer written in C

#474 2015-07-03 09:04:20

Re: sxiv - Simple image viewer written in C

#475 2015-07-03 09:36:01

Re: sxiv - Simple image viewer written in C

Board footer