Release Pandora Image Viewer


Is there any chance of making it show the zoom level in a text overlay briefly after each change in zoom?

An adjustment of the startup script to remember the last selected folder would also be nice. :)

- Neelix
 
1. That would be good.

2. There is the ls -lt command that can be used via Terminal.

3. Its OK now.

Btw. what about the issue that is shown in my .out that I recently posted? (the one where it contains a "too many args" error).
That issue should already have been solved in the version currently on the repo. It is caused by the dirname containing square brackets - in the version currently on the repo there should be no more problem with spaces, brackets, square brackets etc in filenames.

In the next version, the support for huge JPEGs will be improved further. For example, you'll be able to view (and fit to screen) the full-resolution version of this 29,566 × 14,321 pixels, 91MB JPEG file... at least to a zoom level of 1/4, it does not have enough memory to load the 1/2 zoom level, let alone the 1:1 one, but instead of crashing or getting stuck, it will now degrade gracefully and just show you zooms based on the best zoom level it can load.
I can confirm that the "too many args" issue has been fixed. I just had to delete its appdata folder and then run it in order to have the run script inside it be updated.
 
It would also be nice if PIV could support animated GIFs and PNGs. I also think that it could use a simplified dialog box where it just shows the directory structure and then uses ls to list the filenames of the pictures either un-sorted or sorted by date which is then parsed to show the pictures.
 
Animation: not going to do that.

The dialog box is just what you get with zenity, I'm not going to change anything in that. Different sort orders could be a possibility but for now I'm just using the order which the shell uses to expand "directory/*".

In the next update it will remember the last chosen directory.

Zoom level overlay: can be done, but how do you want to call the zoom levels? Internally the logic is either "fit to screen", "fit to screen x2", x4, x8 etc, or "4:1", "2:1", "1:1", "1:2", "1:4" etc if you start from the "1" button. Do those labels make sense or should I use something else?

I'm also adding rotation (of the lossless type) for JPEG files (not for other file formats at the moment, that could be done too but it would be very slow). It's currently actually rotating the image in the file and then re-loading it, which is kind of slow and stupid, but it works.

I'm also considering to add an EXIF info text overlay, and a button to "mark" files so you can then do actions on them like copy them to some other directory.
 
So, I guess that means that showing the recent image first followed by the older ones won't be possible for a while then?
 
So, I guess that means that showing the recent image first followed by the older ones won't be possible for a while then?
Everything is possible, but what would be the clean way to implement that in a zenity script? Parsing the output of ls is not a good idea, it will go wrong when you have filenames with spaces etc. And how do I even get the dialog to return its sort order?
 
I was able to deal with spaces in some scripts I made, I'm actually a little busy with something else, but when I find a little time I can be of help
 
- a way to share a picture easily (as mentioned before).

I know it's not something you want to do but thumbnails in mosaic format would be great to navigate (if you have hundreds of pics on the card). Maybe it's something other people can implement based on your original script. 
An easy way to have both of these (if you just want to send the pictures for viewing only) would be to save them as a PDF file. They would look the same on any device and you would only need to send one file. Much easier and faster than messing with tons of individual pictures.

Looks good by the way _wb_ B)
 
Last edited by a moderator:
An easy way to have both of these (if you just want to send the pictures for viewing only) would be to save them as a PDF file.
That's not what I meant.. i don't want to share the mosaic. The mosaic is for viewing pictures in small format before deciding which one to display.
 
I'm not going to add the mosaic/thumbnail thing in the near future. The reason is that it is quite a bit of work to do it right: if I want to follow the standard and use the thumbnail cache, it means it has to reuse existing thumbs and create new ones when needed. Also an interface needs to be added to navigate the thumbnail mosaic. At the moment the program doesn't even know which files are actually images and which are not - it just skips the files that fail to load. So it doesn't even know how many images there really are.

For the picture sharing feature: you'll be able to select pictures by pressing ENTER. When you quit, it'll ask what you want to do with the selected files: it gives you a menu of possible actions. The actions I currently have are "Copy the files to some directory", "Put the files in a .zip file", and "Show a list of the filenames". It is easy to add more actions - in fact you can do it by adding a shell script to appdata and adding one line to a file, so if you know what you're doing, you can customize it.

The on-screen-display of current zoomlevel and Exif information has been implemented.

I think it's time for a temporary feature freeze now so I can release an update.
 
I'm also adding rotation (of the lossless type) for JPEG files (not for other file formats at the moment, that could be done too but it would be very slow). It's currently actually rotating the image in the file and then re-loading it, which is kind of slow and stupid, but it works.
I don't think this to be a good idea. If I want to view my pictures I usually don't want the viewer to rewrite my files without notice (here: by rotating them). This will be worse if the date is changed by saving the rotated file.


On the other hand a quick browsing through the files just to rotate all pictures to the right alignment is a task much wanted.


The difference is viewing/showing pictures in oppostion to managing pictures. I just wonder if I am the only one who is paranoid about writing/deleting files on/from the camera's card prior to archiving it.
 
I understand your worries, but I think it is practical to be able to do the rotation with one button press without having to do an explicit "Save". I make sure to keep all Exif tags (including the timestamp) intact and to do the rotation losslessly - so if you rotate 4 times, you should get the exact same file you started with.

If you're really paranoid about it, it's probably best to just set your card to "read-only" before you put it in your Pandora :)

I currently have not implemented a "view rotation" feature yet. I might add that later. I will have to do it in software though - apparently the hardware rotation and hardware scaler cannot be used together.
 
_wb_: Almost certainly stupid question, but have you seen tjTransform/TJXOP_ROT90/TJXOP_ROT270?
I just call jpegtran to do the rotation (that's why it only works for JPEG files), and I guess it uses that behind the scenes.

I could call ImageMagick's convert to do the rotation for other files, but that would mean that I need to include ImageMagick, which I rather don't - it's rather big and slow, and it doesn't do lossless rotation (except of course for lossless file formats).

To implement the "view rotation" feature, I could use those transforms to reload a jpeg file with rotation, but it would be more efficient to just implement a rotated blit of the unrotated surface I already have in memory. Especially because that technique would also work for non-jpeg files.
 
If you're really paranoid about it, it's probably best to just set your card to "read-only" before you put it in your Pandora :)
Are you sure that SZ respect the read-only flag of the SD ? The last time I tried (months ago) it was still writing in it
 
An easy way to have both of these (if you just want to send the pictures for viewing only) would be to save them as a PDF file.
That's not what I meant.. i don't want to share the mosaic. The mosaic is for viewing pictures in small format before deciding which one to display.
Why would this stop you from viewing the mosaic without sending?

__wb__ didn't seem to want to mess around and to slow his program down with lots of little additions. I thought that this would be an easier way of doing both :mellow:
 
I don't think this to be a good idea. If I want to view my pictures I usually don't want the viewer to rewrite my files without notice (here: by rotating them). This will be worse if the date is changed by saving the rotated file.
On the other hand a quick browsing through the files just to rotate all pictures to the right alignment is a task much wanted.


The difference is viewing/showing pictures in oppostion to managing pictures. I just wonder if I am the only one who is paranoid about writing/deleting files on/from the camera's card prior to archiving it.
You're not the only one.

I also don't want anything to be altered in the actual file unless I actively  save the changes. It's a matter of principle really, not paranoia. Unless the user chooses to save the changes, it should only be applied in memory or to a temporary file. Never to the original file!
 
Ugh. Can't you just not press the button then? I like to have a one-button persistent rotate. I hate having to rotate and then press CTRL-S to save each time, often forgetting to do so and wondering why the next time I'm viewing the pictures, some of them are rotated the wrong way.

If you want to, I can make it configurable so that the buttons optionally don't do anything at all, so that if you accidentally press them, nothing happens.

By the way, does anyone feel like making an icon (64x64 or so will do, can be higher res too if you want) for PIV? The current one is a bit, uh, minimalistic - which is nice in a way, but if all icons would be like that, things would look a bit spartan.
 
I suggest:

If the file already has an exif orientation tag:

 -- Rotate image accordingly

If the file does not have an orientation tag:

 -- Allow user to rotate by pressing a button.

 -- If user has changed image orientation by the time the image stops being displayed

 --  -- If the image is of a type which can take an exif tag

 --  --  --  If the image is on a writeable filesystem

 --  --  --  -- Write a tag according to the user-set orientation of the image
 
Back
Top