Building MMview, a universal file viewer
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
@slavvo67: Coming back to your request for displaying image size: Though I don't think that this information should be part of the on-the-fly view I agree that it should be made available somehow as an on-demand view (F1).
I checked the possibilities and summarized them in below chart. I can't see a 100% perfect solution but I'll try to address your request in future updates.
exiv2
MMview uses exiv2 for scaling images. So far nobody reported that scaling fails. I therefore assume that exiv2 is present in all current Puppies. It also means that according to above chart scaling is possible for images of type BMP, GIF, JPEG, PNG and TIFF. SVG is scalable by design and doesn't require exiv2.
Displaying image sizes is possible for the listed formats.
file
MMview uses file for the Properties dialog. For formats BMP, GIF, ICO, PCX and PNG image sizes are already displayed when the user pushes the Properties button or Ctrl+P.
Allegedly newer versions of file can also display JPEG size (haven't tested)
identify
identify is part of the ImageMagick suite, not commonly preinstalled in Puppy, therefore I can't rely on it in MMview (though, of course, if installed it can be used via the CommandBox )
xprop
Looks like a winner but is more a work around.
Among many other data xprop can display the requested minimum window size, which is identical with the image size if the window displays just the image without any window decoration or border.
Just for fun I integrated a function into MMview which
- creates a new window for the displayed image
- calls xprop to read the image size (not actual window size!)
- closes the window
Works well and so fast that the user may notice only a flicker, and for small images not even that.
Still I find this solution odd and don't intend to keep it. The only formats for which such work around would be needed are ANI, SVG and XPM. Shouldn't be too hard to doubleclick and get the required information from the default viewer.
I checked the possibilities and summarized them in below chart. I can't see a 100% perfect solution but I'll try to address your request in future updates.
Code: Select all
Ability to display image size
Format exiv2 file identify xprop
ANI - - - ok
BMP ok ok ok ok
GIF ok ok ok ok
ICO - ok - ok
JPEG ok - ok ok
PCX - ok ok ok
PNG ok ok ok ok
SVG - - ok ok
TIFF ok - ok ok
XPM - - ok ok
MMview uses exiv2 for scaling images. So far nobody reported that scaling fails. I therefore assume that exiv2 is present in all current Puppies. It also means that according to above chart scaling is possible for images of type BMP, GIF, JPEG, PNG and TIFF. SVG is scalable by design and doesn't require exiv2.
Displaying image sizes is possible for the listed formats.
file
MMview uses file for the Properties dialog. For formats BMP, GIF, ICO, PCX and PNG image sizes are already displayed when the user pushes the Properties button or Ctrl+P.
Allegedly newer versions of file can also display JPEG size (haven't tested)
identify
identify is part of the ImageMagick suite, not commonly preinstalled in Puppy, therefore I can't rely on it in MMview (though, of course, if installed it can be used via the CommandBox )
xprop
Looks like a winner but is more a work around.
Among many other data xprop can display the requested minimum window size, which is identical with the image size if the window displays just the image without any window decoration or border.
Just for fun I integrated a function into MMview which
- creates a new window for the displayed image
- calls xprop to read the image size (not actual window size!)
- closes the window
Works well and so fast that the user may notice only a flicker, and for small images not even that.
Still I find this solution odd and don't intend to keep it. The only formats for which such work around would be needed are ANI, SVG and XPM. Shouldn't be too hard to doubleclick and get the required information from the default viewer.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Are you saying that you can see JPG sizes in the Properties display? I can't. How does the output look?slavvo67 wrote:I realized you have an icon on the top right for view file properties. That gives me the info I need
RAW formats
For fun I fed MMview some digicam RAW images. I didn't expect to see anything but to my surprise some camera maker's formats can be displayed. Of course the main image is not viewable but the embedded thumbnails are. How many thumbnails are contained and how big they are depends on the maker. "Thumbnail" can be a gross understatement. In case of an iPhone test image the size was 852 x 640.
Another good news: Though RAW files are huge, seldom less than 10MB and sometimes as big as a Puppy distro, scrolling through the file list is smooth. Obviously gtkdialog stops reading the file when it finds the thumbnail
Adobe's DNG format is used by many makers but there seem to be variations that explain the mixed results in my small test.
"Not yet supported" in below list means that MMview can't view the thumbnail directly. I will have to extract it first and then create a symlink. Shouldn't be too difficult. If anyone has tested other formats I would appreciate feedback.
Code: Select all
MMview support for thumbnail display of some Camera maker's RAW formats
Already supported
.DNG Apple (iPhone); Leica
.ERF Epson
.3FR Hasselblad
.MEF Mamiya
.NEF Nikon
Not yet supported but planned
.CR2 Canon
.DNG Canon
.RAF FujiFilm
.MRW Minolta
.ORF Olympus
.RW2 Panasonic
.PEF Pentax
.SRW Samsung
.ARW Sony
Probably impossible
.MDC Minolta
.X3F Sigma
.DNG Google (Pixel 2 XL). Gtkdialog crashed
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Recently I've received some digicam JPGs, each about 3.5M with a resolution of 3456 x 4608 px.
Scrolling through these pictures in MMview was *very* slow. Each picture needed 3sec before it was displayed. That's unacceptable.
I then switched preferences to "Fit images to viewer size" - and the pictures were rendered in less than a second. I never anticipated such a huge difference. I always thought that scaled images would result in slower, not faster rendering. After all GTK has to calculate the new dimension and also MMview has to go through a couple of routines to determine size of viewer pane and scaling factor. Anyway, despite all these additional procedures scaled down pictures display faster.
For comparison I viewed the pictures with Viewnior to see if I can see the same effect. To my surprise in Viewnior the pictures always loaded slowly, scaled or not.
First idea that came to mind: Make "Fit images to viewer size" the default.
On a second thought I figured that the current "Original size" mode isn't of much use anyway, so I decided to scrap this option in the next update. This still leaves 3 different display options, which I think is sufficient and covers all useful display modes.
Scrolling through these pictures in MMview was *very* slow. Each picture needed 3sec before it was displayed. That's unacceptable.
I then switched preferences to "Fit images to viewer size" - and the pictures were rendered in less than a second. I never anticipated such a huge difference. I always thought that scaled images would result in slower, not faster rendering. After all GTK has to calculate the new dimension and also MMview has to go through a couple of routines to determine size of viewer pane and scaling factor. Anyway, despite all these additional procedures scaled down pictures display faster.
For comparison I viewed the pictures with Viewnior to see if I can see the same effect. To my surprise in Viewnior the pictures always loaded slowly, scaled or not.
First idea that came to mind: Make "Fit images to viewer size" the default.
On a second thought I figured that the current "Original size" mode isn't of much use anyway, so I decided to scrap this option in the next update. This still leaves 3 different display options, which I think is sufficient and covers all useful display modes.
Offtopic.MochiMoppel wrote:I then switched preferences to "Fit images to viewer size" - and the pictures were rendered in less than a second. I never anticipated such a huge difference. I always thought that scaled images would result in slower, not faster rendering. After all GTK has to calculate the new dimension and also MMview has to go through a couple of routines to determine size of viewer pane and scaling factor. Anyway, despite all these additional procedures scaled down pictures display faster.
My reasoning on scaling images down is a far less quantity of pixels to process and send to the display, that might be a reason why it is faster compared to 10x, 20x, 30x, or 40x the quantity of pixels to display.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Your guess is a good as mine, but all pixels of the original image have to be processed and blocks of original pixels have to be converted into 1 pixel for the scaled image, that's a lot of processing. The number of pixels eventually to be displayed (in the viewer pane) is the same.anewuser wrote:My reasoning on scaling images down is a far less quantity of pixels to process and send to the display
I didn't notice a difference for PNG files and for uncompressed formats as BMP it's also no issue as they always are rendered very fast despite their huge file size. So it could well be related to the JPEG compression algorithm.
Anyway, it's interesting but, as you already noted, a bit off topic. Shouldn't be our concern. Important lesson is that scaling doesn't slow the display.
BTW: Next update will include support for Photoshop, RAW and some other image formats. Also included will be support for Exif and other metadata.
Viewer runs in 64bit with 32-bit lib support
G'day MochiMoppel,
Thanks for this interesting and useful addition to Puppy's small utilities. It worked nicely as a pinboard script.
I turned your (August?) script into a pet then an sfs then an sfs based on links to the sfs files on my data partition. This is the form of added app I now prefer for all my Pups (I combine all these sfs into one so setting up a new Pup with my applications is as easy as possible).
I found your MMView will run in a 64-bit Pup - with its 32-bit compatibility libs also loaded (screenshot). I don't know if MMView would run without the 32bit libs included but these libs are already in my all-applications sfs for my 64bit Pup Frugals.
I've attached my (non-links) sfs for anyone to try - who's brave enough .
Looking forward to your next update of mm_view.
David S.
Thanks for this interesting and useful addition to Puppy's small utilities. It worked nicely as a pinboard script.
I turned your (August?) script into a pet then an sfs then an sfs based on links to the sfs files on my data partition. This is the form of added app I now prefer for all my Pups (I combine all these sfs into one so setting up a new Pup with my applications is as easy as possible).
I found your MMView will run in a 64-bit Pup - with its 32-bit compatibility libs also loaded (screenshot). I don't know if MMView would run without the 32bit libs included but these libs are already in my all-applications sfs for my 64bit Pup Frugals.
I've attached my (non-links) sfs for anyone to try - who's brave enough .
Looking forward to your next update of mm_view.
David S.
- Attachments
-
- mmviewer.sfs.gz
- rename to mmviewer.sfs and test in a frugal, AFTER you've backed-up its savefile! Then look in the FileManager Menu.
- (20 KiB) Downloaded 211 times
-
- mm_viewer-64slacko-sfslinksversion.jpg
- mmview running from pinboard icon in a 64bit Slacko; icon is linked to sfs stored on data partition
- (117.79 KiB) Downloaded 543 times
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Update 2018-09-20 (see also initial post)
This update adds more functionality to view and manage digicam photos:
Support for metadata (Exif,IPTC,XMP, Exif comments, GPS geolocation data)
Many more file formats, including camera maker specific RAW formats. I believe that with this update all real life image formats are now supported by MMview.
New or improved buttons make operations easier (I hope).
Metadata
When an image file contains metadata like Exif, it is mentioned in the text above the image. A typical text might read
In this case pushing F1 or the new info button will display an "EXIF SUMMARY", a short list of most important Exif values in human readable form, and a usually long list of "EXIF METADATA" , a list of Exif keys and maker notes. Also included may be "IPTC METADATA" , usually used by photo managing applications for adding tags and key words, and "XMP METADATA", a format preferred by some applications, e.g. Adobe Photoshop.
"Comments" would indicate that the file contains an Exif comment. Comments are typically added by the user. MMview allows to add comments via the Commandbox (editing metadata is interesting stuff but I don't want to go into details here. Would be a topic of its own).
"GPS" geolocation data are present when the user has enabled this function in his/her GPS capable smartphone or camera. These data can then be translated into URLs for sites like Google Maps and help to pinpoint the exact location where a photo was taken.
New file formats
.psd (Adobe Photoshop)
MMview displays the preview image embedded in Photoshop files
.ppm, .pgm, .pbm (Portable Pixmap, Portable Greymap, Portable Bitmap).
All part of the Netpbm toolkit. Gtkdialog can't read such files natively so MMview shows a JPEG copy. Note: PPM did not work when tested with Dpup Stretch 7.5. PGM and PBM were fine. Seems that newer versions of ffmpeg have problems with PPM.
.webp (Google's WebP format)
One of the most amazing formats. Much better compression and retained quality than JPEG. See my comparison here. Because of the small file sizes it produces it is ideal for document archiving and is also increasingly used in Japanese ComicBook archives. The catch: ffmpeg can convert them into JPEGs but in my tests avconv could not, so MMview's support is restricted to Puppies with installed ffmpeg.
.dng, .cr2, .mef, .nef, .pef, .erf, .orf, .arw, .mrw, .srw, .rw2, .raf, .3fr
These are all camera specific RAW formats and probably cover most of the popular camera models and makers. All RAW files have preview files embedded, mostly in JPEG format. MMview extracts and displays these previews. Since (undisplayable) main picture and (displayed) preview image usually have different dimensions, no dimension is given in the header text to avoid confusion.
Buttons
An "Additional Info" button is added as an alternative for F1. This also makes it easy to switch between "Instant View" and "Additional Info View".
A new "Toggle Instant View" button deactivates Instant View. This can be useful to speed up scrolling, particularly when "heavy" images or directories make scrolling sluggish. Also useful when only "Additional Info" or "Properties" is of interest and the file content is not needed to display.
This function is also accessible via Menu - View - Disable Instant View Mode.
The "Line Wrapping" button now displays the current status. With most GTK themes is is difficult to see if a button is pushed ("sunken") or not, in this case if line wrapping is on or off. The button icon now changes depending on status, making this destinction much clearer.
Other changes
"Fit images to viewer size" is now the default mode. The previous default, which showed all images in their original size, has been abolished (see here)
This update adds more functionality to view and manage digicam photos:
Support for metadata (Exif,IPTC,XMP, Exif comments, GPS geolocation data)
Many more file formats, including camera maker specific RAW formats. I believe that with this update all real life image formats are now supported by MMview.
New or improved buttons make operations easier (I hope).
Metadata
When an image file contains metadata like Exif, it is mentioned in the text above the image. A typical text might read
- 36% of 1360x1020 Metadata:Exif,Comment,GPS
In this case pushing F1 or the new info button will display an "EXIF SUMMARY", a short list of most important Exif values in human readable form, and a usually long list of "EXIF METADATA" , a list of Exif keys and maker notes. Also included may be "IPTC METADATA" , usually used by photo managing applications for adding tags and key words, and "XMP METADATA", a format preferred by some applications, e.g. Adobe Photoshop.
"Comments" would indicate that the file contains an Exif comment. Comments are typically added by the user. MMview allows to add comments via the Commandbox (editing metadata is interesting stuff but I don't want to go into details here. Would be a topic of its own).
"GPS" geolocation data are present when the user has enabled this function in his/her GPS capable smartphone or camera. These data can then be translated into URLs for sites like Google Maps and help to pinpoint the exact location where a photo was taken.
New file formats
.psd (Adobe Photoshop)
MMview displays the preview image embedded in Photoshop files
.ppm, .pgm, .pbm (Portable Pixmap, Portable Greymap, Portable Bitmap).
All part of the Netpbm toolkit. Gtkdialog can't read such files natively so MMview shows a JPEG copy. Note: PPM did not work when tested with Dpup Stretch 7.5. PGM and PBM were fine. Seems that newer versions of ffmpeg have problems with PPM.
.webp (Google's WebP format)
One of the most amazing formats. Much better compression and retained quality than JPEG. See my comparison here. Because of the small file sizes it produces it is ideal for document archiving and is also increasingly used in Japanese ComicBook archives. The catch: ffmpeg can convert them into JPEGs but in my tests avconv could not, so MMview's support is restricted to Puppies with installed ffmpeg.
.dng, .cr2, .mef, .nef, .pef, .erf, .orf, .arw, .mrw, .srw, .rw2, .raf, .3fr
These are all camera specific RAW formats and probably cover most of the popular camera models and makers. All RAW files have preview files embedded, mostly in JPEG format. MMview extracts and displays these previews. Since (undisplayable) main picture and (displayed) preview image usually have different dimensions, no dimension is given in the header text to avoid confusion.
Buttons
An "Additional Info" button is added as an alternative for F1. This also makes it easy to switch between "Instant View" and "Additional Info View".
A new "Toggle Instant View" button deactivates Instant View. This can be useful to speed up scrolling, particularly when "heavy" images or directories make scrolling sluggish. Also useful when only "Additional Info" or "Properties" is of interest and the file content is not needed to display.
This function is also accessible via Menu - View - Disable Instant View Mode.
The "Line Wrapping" button now displays the current status. With most GTK themes is is difficult to see if a button is pushed ("sunken") or not, in this case if line wrapping is on or off. The button icon now changes depending on status, making this destinction much clearer.
Other changes
"Fit images to viewer size" is now the default mode. The previous default, which showed all images in their original size, has been abolished (see here)
- Attachments
-
- mmview_metadata.jpg
- (144.26 KiB) Downloaded 529 times
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Hi greengeek.greengeek wrote:Is there any possibility of adding a function which could display thumbnails
of images in a directory? Even if it was a pretty slow process it could be
handy when you are trying to hunt down a specific image within a multitude
of images on a camera card or similar.
Adding to MochiMppei's remark:
IMO, this can be achieved more efficiently through a specialized app, rather
than through a universal viewer such as MochiMoppei's.
qeekie, GQView, XNViewMP and no doubt a couple of other image viewers
(have you searched the Internet on this?) can also show thumbnails of
images in a directory. Plus they all offer various sizes for thumbnails.
ROX is limited in that respect.
I remember that XnViewMP offers the capacity to create "contact sheets",
which would probably be very handy for what you want.
IHTH.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Hmmm, well I'm actually asking "on behalf of a friend".MochiMoppel wrote:Nothing is impossible but ROX-Filer already can do what you ask for. Not good enough?
i saw another thread detailing the virtues of Irfanview and bemoaning the lack of some of it's features in Linux - and in that thread Perdido made the comment that mmview had many of the features requested by the thread O.P.
One of the features the O.P mentioned was thumbnails so i thought I'd ask the question about that possibility within mmview.
mmview has a lot of potential as an alternative to ROX-Filer so if thumbnailing is possible it would be a handy inclusion. I know you label it as a "file viewer" but perhaps the ability to also offer a thumbnail view of a directory could be handy.
Actually - sometimes it would be really handy to have a pictorial/thumbnail view of every file in a directory, not just images (eg a pdf file displayed with an "adobe pdf swipe" (or just a ".pdf" icon), a text file displayed with a .txt icon etc
(sorry - my mind is running away as it usually does )
- Attachments
-
- txt_icon.png
- (1.38 KiB) Downloaded 351 times
-
- pdf_icon.png
- (1.36 KiB) Downloaded 349 times
Now that I think about your remark a second time I realise that i had no clear recall of ROX-Filer having that ability. To be honest I would not want to modify the ROX settings each time I wanted to see the thumbnails - however if that ability could be switched on and off within mmview (maybe an extra icon in the cluster at top right?) it would seem to be a more appropriate place to find that function.MochiMoppel wrote:Nothing is impossible but ROX-Filer already can do what you ask for. Not good enough?
Somehow, I don't expect anything more of ROX-Filer than it's ability to take me to a directory and let me manually handle the files. It's not the most functional FM in the world (I have an xfe pet for more fancy file manipulations).
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Then let me refresh your memory.greengeek wrote:Now that I think about your remark a second time I realise that i had no clear recall of ROX-Filer having that ability.
MMview and ROX-Filer work very fine as a combi.
1) Push button to open ROX-Filer window
2) In ROX-Filer window, If thumbnails are switched off, turn them on by right-clicking the eye icon. Use the '=' key to make thumbnails bigger.
3) Drag thumbnail from ROX-Filer to MMview to select in MMview.
Generating 500 thumbnails took only a few seconds. Neat, isn't it?
- Attachments
-
- ROX-thumbnails.jpg
- (144.42 KiB) Downloaded 327 times
This program is small enough to be made into a pet.
Be able to attach it in the first post of this topic.
Anything 256K or less can be attached to a post.
The mm_view_20180920.gz.
After removing the .gz.
The script file (mm_view_20180920) still needed to be given exec permission to run.
Would help to add that info in the download files description.
Nice program!!!
Looking like a real good possible Puppy file manager program.
Be able to attach it in the first post of this topic.
Anything 256K or less can be attached to a post.
The mm_view_20180920.gz.
After removing the .gz.
The script file (mm_view_20180920) still needed to be given exec permission to run.
Would help to add that info in the download files description.
Nice program!!!
Looking like a real good possible Puppy file manager program.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Hello MochiMoppei and all.
You have indeed created in mm_view a fine generalist file-viewing and
file-handling utility. Many thanks for this program.
But with all due respect, IMHO, concerning mm_view as a picture viewer,
( q.v. http://www.murga-linux.com/puppy/viewto ... st#1007473 )
if the user's defaultimageviewer script is configured correctly, it is simpler
to double-click on the image to view it full size in the defined viewer.
Further, if the defined image viewer is gqview, JIBS or mtpaint in viewer
mode, the user has direct access to image-processing features if needed.
My 2¢.
Best regards.
You have indeed created in mm_view a fine generalist file-viewing and
file-handling utility. Many thanks for this program.
But with all due respect, IMHO, concerning mm_view as a picture viewer,
( q.v. http://www.murga-linux.com/puppy/viewto ... st#1007473 )
if the user's defaultimageviewer script is configured correctly, it is simpler
to double-click on the image to view it full size in the defined viewer.
Further, if the defined image viewer is gqview, JIBS or mtpaint in viewer
mode, the user has direct access to image-processing features if needed.
My 2¢.
Best regards.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
I thought so too. The attached is for your consideration. The mm_viewer.desktop reads as follows (Edited, see below):bigpup wrote:This program is small enough to be made into a pet.
[Desktop Entry]
Encoding=UTF-8
Name=mm_file_info_viewer
Name[es]=mm_visor de archivos
Name[fr]=mm_visionneuse de fichiers
Icon=/usr/local/Pup-SysInfo/icons/Pup-SysInfo48.png
Comment=file information utility
Exec=/root/my-applications/bin/mm_view
Terminal=false
Type=Application
Categories=X-FilesystemUtility;
GenericName=File information utility
Don't hesitate to use or ignore it, or modify it -- especially regarding the names in Spanish and French generated by google-translate. To conserve overhead, it uses the same png as Pup-SysInfo, as that application exists in all recent Puppies.
I was sort of thinking about mm_viewer's graphic handling limitation without comparing it to other viewers. Rather, I noted that some files could be opened in the application which serves as default for its type, and that there was a tool to open text files, while graphic files could only be displayed, not edited.
Perhaps a tool to open a selected graphic file in the default graphic editor?
Edit: Based on musher0's analysis following, the Category designation has been changed so that the application will appear under filesystems. For ease of modification during development, I've left the binary in /root/my-applications/bin.
- Attachments
-
- mm_file_viewer-20180920.pet
- File-Viewer and File-System Enhancement
- (17.69 KiB) Downloaded 178 times
Last edited by mikeslr on Wed 17 Oct 2018, 23:34, edited 2 times in total.
I used svg images to provide graphic image chooser for wifi APs and Network intefaces in Wifi-TrayNet. So it is very easy to do that (I mean if I can do it, imagine what Mochi could do ... but he wont anyway!)greengeek wrote: Actually - sometimes it would be really handy to have a pictorial/thumbnail view of every file in a directory, not just images (eg a pdf file displayed with an "adobe pdf swipe" (or just a ".pdf" icon), a text file displayed with a .txt icon etc
(sorry - my mind is running away as it usually does )
- Attachments
-
- xscreenshot-20181016T201125.png
- (103.98 KiB) Downloaded 245 times
-
- xscreenshot-20181016T201021.png
- (37.17 KiB) Downloaded 237 times