XnView Software

In a previous thread it was discovered that the reading of the descript ion file could cause long delays when loading an image;
http://newsgroup.xnview.com/viewtopic.p ... c&start=15

Here I would like to address 2 other issues:

1. Image loading times (w/o any descriptions)

I disabled the read ahead cache in XnView and ACDSee and loaded images in full screen mode. Picture size was 2904x4368x24b.

ACDSee loading time (average of 5): 0.49 sec*
XnView loading time (average of 5): 1.85 sec

To try to improve the loading time with XnView, I dissabled the HQ Zoom option, and that reduced the loading time by 0.3 sec.

Still, ACDSee is 3 times faster when loading large images. Is there anything that can be done to improve the XnView loading times?

XnView's loading time are comparable to many other image editors and File Managers. It appears that ACDSee is unique! How can they achieve such lightening fast loading times..??


2. Read Ahead Cache

I then enabled the read ahead cache in ACDSee and XnView and loaded images in full screen mode. Picture size was still 2904x4368x24b.

ACDSee loading time (average of 5):<0.15 sec (I can't click the stop watch fast enough). Appears to load instantly.
XnView loading time (average of 5): 0.83 sec

The loading time is less than half when using the read ahead cache in XnView. However, it is still 0.8 sec compared to virtually instant in ACDSee. Why are the images not loading "instantly" with XnView, as with ACDSee, if the image is already stored in the cache?


*) Note that ACDsee is using a progressive display so it looks like the images are loading even faster. The loading times given are after the images have completely finished loading.

viking wrote:XnView's loading time is comparable to many other image editors and File Managers. It appears that ACDSee is unique! How can they achieve such lightening fast loading times..??

I don't know but they have more than 30 developers on this product

The loading time is less than half when using the read ahead cache in XnView. However, it is still 0.8 sec compared to virtually instant in ACDSee. Why is the images not loading "instantly" with XnView, as with ACDSee if the image is already stored in the cache?

High zoom quality enabled?

xnview wrote:

viking wrote:XnView's loading time is comparable to many other image editors and File Managers. It appears that ACDSee is unique! How can they achieve such lightening fast loading times..??

I don't know but they have more than 30 developers on this product

The loading time is less than half when using the read ahead cache in XnView. However, it is still 0.8 sec compared to virtually instant in ACDSee. Why is the images not loading "instantly" with XnView, as with ACDSee if the image is already stored in the cache?

High zoom quality enabled?

I am still using v3.1 (the "best" one). They later stopped descript.ion support

As I wrote above: "To try to improve the loading time with XnView, I disabled the HQ Zoom option, and that reduced the loading time by 0.3 sec. "

xnview wrote:

viking wrote:XnView's loading time is comparable to many other image editors and File Managers. It appears that ACDSee is unique! How can they achieve such lightening fast loading times..??

I don't know but they have more than 30 developers on this product

Last year I evaluated mid range Digital Asset Management (DAM) products - ACDSee Pro, Breeze Browser, idImager, IMatch, Lightroom/Bridge, PhotoMechanic etc.

ACDSee Pro was much faster than than any other product in getting an image from disk on to the monitor. The other products would always cluster when measuring browsing performance and ACDSee Pro was always an outlier at the desirable end of the scale; this was true, irrespective of the number, type and size of the images.

• primarily, it's their file handling that gives them the edge, and their image processing is no slouch either.
• it would seem that they've had this performance edge for quite some time - essentially forever.
• their personal & professional products share the same core code
• they keep a very close guard over the internals of their product. I suspect that's why they wont provide any sort of SDK or scripting facilities

How do they do it? I dunno either. But I wish they'd tell Microsoft so that they could put it into their O/S so that all software might benefit.

Whilst ACDSee Pro was way out in front in terms of image browsing performance, in other respects it was back with the pack and in one instance it was some way behind, XNView wasn't evaluated, it's a great browser but its not yet a professional DAM product.

RightPaddock wrote: Last year I evaluated mid range Digital Asset Management (DAM) products - ACDSee Pro, Breeze Browser, idImager, IMatch, Lightroom/Bridge, PhotoMechanic etc.

Just out of curiosity, which one came next after ACDSee in terms of browsing speed and which ones supports descript.ion..?

I'm certain the read>display performance acdsee exhibit isn't something restricted to a 30 member developers team. and there isn't any magic voodoo under acdsee hood either.

I know several image viewer (not DAM) that are actually faster than acdsee.
namely: picasa 3 viewer and FastPictureViewer.

I'm actually confident this level of performance is entirely achievable by any talented and dedicated developer... willing to tackle the issue

regarding xnview & xnviewMP, "simple" trick like progressive loading would already tremendously speed up the perceived responsivity of the application and navigation workflow.

viking wrote:

RightPaddock wrote: Last year I evaluated mid range Digital Asset Management (DAM) products - ACDSee Pro, Breeze Browser, idImager, IMatch, Lightroom/Bridge, PhotoMechanic etc.

Just out of curiosity, which one came next after ACDSee in terms of browsing speed and which ones supports descript.ion..?

As I said they were clustered so the differences were within the bounds of statistical error - in order words they all came second.

Descrpt.ion support was not a requirement, so I can't recall which products did support it and which didn't, I'm not even sure I know what it is. The eval was related to core business processes, i.e. not a marketing or creativity function.

thibaud wrote: I know several image viewer (not DAM) that are actually faster than acdsee.
namely: picasa 3 viewer and FastPictureViewer.

I haven't looked as Picasa 3, wouldn't have thought that earlier versions were any faster than XNView. Maybe it's time to take another look.

I think I am right in saying that FastPictureViewer (FPV) is just what it says it is - a very fast one at a time picture viewer, I haven't spent much time with it for reasons you'll see below.

XNView, ACDSee Photo Manager, Picasa, FastStone Image Viewer and even IrfanView, are what I call image browsers, in that they all present a scrollable presentation of thumbnails from which one can select one or more images for processing, I don't think FPV can do that.

According to my firewall FastPictureViewer does direct disk device I/O - i.e. it bypasses the file system. That is not the case with any of the other products I've mentioned, including ACDSee's products. It's rarely seen in today's desktop software, but it was common in the days of MS/PC-DOS, I think Visicalc was an app that did direct disk I/O.

Today, direct disk I/O is more typically seen in d/b, web or other server products running on a dedicated machine. I normally avoid running direct disk I/O software on general purpose systems that run multiple concurrent apps (most desktops), especially if it's a Version 1.00 product. The problem is that a bug in a direct disk I/O app is more likely cause a catastrophic system crash, than is a bug in an app that uses the file system. A catastrophic crash may need a disk format, recovery from system image media + restore from backup media, or reinstall of the O/S & software + restore from backup media.

So that's why I've not spent much time with FPV.

viking wrote: I am still using v3.1 (the "best" one). They later stopped descript.ion support
"[/i]

Viking, I just looked through my notes, they indicate that ACDSee Pro 2.5 has descript.ion support, I don't know whether that's in ACDSee PM. When you say they dropped it - have you checked latest ACDSee PM - I think it's version 11.0.113 (whatever that means).

In my notes idImager is the only other product that has an entry indicating support for descript.ion, but it's a bit vague.

I wasn't looking for descript.ion support so my notes could easily be a load of ol' rubbish as well as being more 6 months old

RightPaddock wrote: Viking, I just looked through my notes, they indicate that ACDSee Pro 2.5 has descript.ion support, I don't know whether that's in ACDSee PM. When you say they dropped it - have you checked latest ACDSee PM - I think it's version 11.0.113 (whatever that means).

I checked their website, but it mentions nothing about support for it.
I know that later versions let you import and convert the descript.ion file to their proprietary database format. That is not suitable for me as I am constantly generating new descriptions for new files.

viking wrote:I checked their website, but it mentions nothing about support for it.

But that doesn't mean it wont do it, their website is singularly uninformative, and it doesn't have a search function; why not pose the question on their forums, you might get an answer.

I know later versions let you import and convert the descript.ion file to their proprietary database format. That is not suitable for me as I am constantly generating new descriptions for new files.

If you can import then you should be able to export, as I recall it was fairly straightforward in ACDSee Pro to trigger an export as the result of changing something, I certainly did it with captions, keywords and catagories which it also keeps in its database.

If you do things right, the database is just a well-tempered cache for thumbnails and fast searching, there's nothing there that's not in the source or their sidecars, which means you can rebuild the d/b from the source.

But you're best qualified to judge what's best - I barely know what a descript.ion is, I know what an OH ion or an Na ion looks like but we didn't do descript ions at my school.

This thread prompted me to do a quick appraisal of XNViews performance, here are my impressions

Once a folder's been cached then it seems pretty quick to me, I got delays between 0.5-1.5 secs before a folder starts to display, but if its cached then the thumbs are painted instantly. I navigated arond about 50 folders, some had up to 200 8Mp TIFF's, others had up to 1,000 1-2Mp JPEG's and various mixtures in between.

If a folder had not been cached then the thumbs progressively appeared on the screen, depending on the number and size of images it could take some time to load all the image files and write the cache (1-30 secs). If you select a folder and then select another one before the caching operation is complete (green progress bar bottom right) then it starts the caching again next time you select that folder, I think from the beginning but maybe it restarts, not sure.

But overall it's not too shabby, on cached folders it's a tad slower on the numerous JPEG folders than is the DAM app I'm using (IMatch) and about the same on the less numerous but bigger TIFF folders. Can't compare un-cached folders because folders are be explicitly imported into IMatch, you can just browse to one. I also have the import set up to do some extra stuff, like keyword updates etc

I don't think there's much more I can contribute - Good Luck

RightPaddock wrote:XNView wasn't evaluated, it's a great browser but its not yet a professional DAM product.

Just curious but whats missing from XnView that you would find in a "professional" DAM product?

jaqian wrote:

RightPaddock wrote:XNView wasn't evaluated, it's a great browser but its not yet a professional DAM product.

Just curious but whats missing from XnView that you would find in a "professional" DAM product?

Compared to ACDSee I'd say speed:

sacharja wrote:BTW: it would be really great if one could hide the menu bar in viewer only.

BTW2: maybe there's a chance to speed up the scrolling through image albums (clicking next image => next image ...). IMHO XnView should stop rendering the current image when the user clicks "next image" (or scrolls to the next one) and should start rendering the new image.

( from http://newsgroup.xnview.com/viewtopic.php?p=71907#71907 )

BTW2: maybe there's a chance to speed up the scrolling through image albums (clicking next image => next image ...). IMHO XnView should stop rendering the current image when the user clicks "next image" (or scrolls to the next one) and should start rendering the new image.

I also though that was the problem at first but..
Xnview does interrupt the loading when you call another image.
the main issue is that nothing is displayed until the image load is complete!

hopefully Pierre is working on that, and I'm confident that will tremendously change xnview viewer navigation experience and perceived speed.

jaqian wrote:

RightPaddock wrote:Just curious but whats missing from XnView that you might find in a "professional" DAM product?

I changed would to might. Below are some features that come to mind. The yet in my original statement was significant, i.e. you might say "but XNView/Picasa/FPV does that one" - but IMO XNView doesn't do enough of them, nor well enough. I'm not aware of any one DAM product that supports all the features listed and few (if any) DAM system deployments will need all of them. To learn more, go here - http://www.thedambook.com/

• workflow centred approach (some products are starting to include workflow definition and automation features);
• a database, this is not a "requirement" more of an essential consequence;
• option of selecting the commercial database product (SQLServer, MySQL, Oracle ...), required when user has in-house expertise, i.e. Oracle shops will usually prefer to have another Oracle server;
• access to database using third party tools - usually read only for things like report generation, dashboard presentation, workflow metrics etc;
• very large media object collections located on online, nearline and offline storage media;
• multiple concurrently open databases - e.g. you might want different databases based on construction project (e.g. Dubai Museum, London Olympic Village, ...) or camera situations (traffic, river flow, harbour activity, ...);
• integration with the web, web publishing Flickr, SmugMug, YouTube, MySpace, BlogThis .... never ending list.
• distribution of media subsets on "intelligent" optical media - e.g. burn the images and a mini database of the catwalk models that an agency represents to optical, which the recipient can offline browse and search, using software that's on the DVD (hence "intelligent").
• multiple concurrent users (server databases);
• separation of the physical from the content - this usually means that files must be EXPLICITLY "imported/ingested/acquired" by the DAM app, rather than browsing the file system;
• multiple format media object support - e.g. the RAW, TIFF, JPG of the one "shot" are managed as a single entity, even tho they be in different file's, including sidecar/buddy files.
• multiple version media object support;
• support for multi part media objects, mainly for managing moving image and audio objects, also used where image stitching is prevalent.
• external tool integration - Geosetter, Photshop, ExifTool, Media Composer, Breeze Browser, Montage, Premiere ..., another never ending list;
• Manipulation of ALL metadata (EXIF, IPTC , XMP and user defined);
• user defined mapping of database properties to/from metadata fields, and user control of update timing - immediate (slower, safer), batch (better control), background (faster, less control);
• Ability to define the metadata fields that are to be kept in the "database", so that if I need to search all images on EXIF date/time taken, including those on offline or nearline storage, then I would have EXIF data/time taken in the database;
• Some sort of "scripting" or SDK so that users can write "stuff" to support there own work practices;
• flexible user interface, with features such as edge docking, tabbed panels.
• "always on" monitoring of file system activity so that media files under DAM Management can be manipulated using the host operating systems file system tools, so if I move some images from my local hard drive to a server drive then the DAM app should spot that and update its d/b accordingly;
• support for structured vocabularies for assignment of metadata text fields - keyword, object name, city, state etc - ability to export & import same;
• some sort of hierarchical category/label scheme that can be easily imported/exported from/to a file (text, csv, xml etc) as well as the embedded metadata of course.

I can't set any order to the features, what a stock photographer would need is likely to be very different to what a criminal justice department will need, which in turn is likely to be different to what an agency needs. Database, and workflow related features are probably universal and scripting/SDK support is nearly so.