Ad
Ad
Ad
Pages: [1]   Bottom of Page
Print
Author Topic: Lightroom vs. IView  (Read 7428 times)
free1000
Sr. Member
****
Offline Offline

Posts: 400


WWW
« on: October 04, 2006, 03:03:34 AM »
ReplyReply

I've just been looking informally at how IView 3.1.1 stacks up against Lightroom. Having read some peoples comments about the performance of Lightroom.

I've used IView for 2 years as my DAM solution. Its big failing is a very poor handling of offline resources.

My set up is that I have a dual core 2.6Ghz PC overclocked to 3.25Ghz, 2Mb of RAM. My image archive is on a buffalo terastation and they are connected via a 1GHz Dlink switch.

I found that it took lightroom 8 seconds to import a folder with three large tiffs (120-200Mb) and one Jpeg.  It took IView over one minute.  IView does not have a loupe function, but showing a whole 120Mb tiff at 1:1 took about 25 seconds, in Lightroom it took about the same amount of time to do a 1:1 under the loupe.

I'd like to see better performance from LR in the subsequent develop module.  My overall image library is about 140,000 images and so far I've only got 9000 in Lightroom. It feels as though things are already slowing down with this library size, but as I didn't record performance in any way, I can't objectively tell.

LR seems to have the potential to make IView obsolete due to its good handling of networked and offline images. Though maybe the library organisation needs some further development to handle large existing libraries.

Has anyone loaded a really large library yet?
Logged

@foliobook
Foliobook professional photography folio for iPad
www.foliobook.mobi
Nick Rains
Sr. Member
****
Offline Offline

Posts: 700



WWW
« Reply #1 on: October 04, 2006, 04:10:48 PM »
ReplyReply

Quote
I've used IView for 2 years as my DAM solution. Its big failing is a very poor handling of offline resources.

[a href=\"index.php?act=findpost&pid=79029\"][{POST_SNAPBACK}][/a]

In what way does IView handle offline files poorly? IMO it works just fine and I can locate archived material very easily.

LR OTOH, has nowhere near the DAM capabilities of IView, or others, and will never replace it in its current form. As a RAW processor LR is quite good, and it's faster than Bridge for some things but the lack of a folder view/browse capability and poor DAM features is a deal breaker for many.

Generalist software apps can very rarely compete directly with specialist apps. Their value to some lies in the 'one size fits all' solution.
Logged

Nick Rains
Australian Landscape Photographer
www.nickrains.com
iPad Publishing
www.photique.com.au
free1000
Sr. Member
****
Offline Offline

Posts: 400


WWW
« Reply #2 on: October 05, 2006, 07:57:32 AM »
ReplyReply

Quote
In what way does IView handle offline files poorly? IMO it works just fine and I can locate archived material very easily.

Well, lets consider the problems I'm having with my network drive.  I have a networked Buffalo teraserver with about 700Gb of image files on it. Before I moved the files onto this they were held on a hard drive, so the IView library is mapped to F:\\imageLibrary

When I try to remap this drive path (relocate the folder) to my \\Server\imageLibrary IView just hangs.

Performance is slow also when handling DVD ROMs.  

LR is faster to build the library than IView is to index a disc. LR beta 4 handles nested folders through the shoots panel.
 
What does LR not have in the DAM category that is critical? Seems to do most things as far as I can see.
Logged

@foliobook
Foliobook professional photography folio for iPad
www.foliobook.mobi
john beardsworth
Sr. Member
****
Offline Offline

Posts: 2739



WWW
« Reply #3 on: October 05, 2006, 08:53:19 AM »
ReplyReply

Quote
...Seems to do most things as far as I can see.

Hm. Well, try resetting the paths to point files to a new drive, or working out if all your files from a certain folder are in LR, moving files between folders, working out which files are no longer where LR thinks they are.... However Adobe are listening to views on this beta's DAM shortcomings and I'm sure it will move forward in these areas.

As for your iView issue, it's true it doesn't behave well with network addresses. I'd expect it to perform better if you map the server as a regular drive. Don't know if you can do that.

John
Logged

free1000
Sr. Member
****
Offline Offline

Posts: 400


WWW
« Reply #4 on: October 06, 2006, 03:30:11 AM »
ReplyReply

John, Yes I know that these are important functions, heaven knows I have trouble with IView doing it. However the crticial DAM capabilities, metadata handling, offline and networked indexing are essentially there.

I hope that LR Library does cover more of the essential DAM features. I'd also like to see complete library export as XML metadata to allow use by external systems.  I'd like to see a plug in feature to allow third party addins for all the modules and many more...

However the problem I've had with DAM products is precisely how they map into ones workflow. The DAM is just the starting point for a workflow and it should integrate seamlessly. LR is one of the first products I've seen that gets this right. In other words, I believe precisely that there is significant value in integrating DAM into file preparation.

Over the years I bought Cumulus and IView. Cumulus was relatively good at storing and finding but was most disconnected from workflow. IView was very good, but critical file management and metadata features were never got right over my two years of buying and upgrading versions.  

I hope LR gets it right.
Logged

@foliobook
Foliobook professional photography folio for iPad
www.foliobook.mobi
terence_patrick
Full Member
***
Offline Offline

Posts: 149


WWW
« Reply #5 on: October 09, 2006, 04:38:38 AM »
ReplyReply

iView's weakness is in the limitation of catalog sizes to 2gb (mine seem to stop at 1.8gb though).  I've already had to break my 2006 images up into multiple sub-catalogs, which sort of defeats the purpose to me.
Logged
free1000
Sr. Member
****
Offline Offline

Posts: 400


WWW
« Reply #6 on: October 14, 2006, 02:22:33 AM »
ReplyReply

Quote
iView's weakness is in the limitation of catalog sizes to 2gb (mine seem to stop at 1.8gb though).  I've already had to break my 2006 images up into multiple sub-catalogs, which sort of defeats the purpose to me.
[a href=\"index.php?act=findpost&pid=79630\"][{POST_SNAPBACK}][/a]

I guess this large size is because of the size of the previews you are creating? I have 30,000 images from 2005 which fit in a single 256Mb catalog.  I can see the attraction of having big previews available, but maybe thats a current limitation that may eventually go away.
Logged

@foliobook
Foliobook professional photography folio for iPad
www.foliobook.mobi
free1000
Sr. Member
****
Offline Offline

Posts: 400


WWW
« Reply #7 on: October 14, 2006, 02:26:11 AM »
ReplyReply

Quote
As for your iView issue, it's true it doesn't behave well with network addresses. I'd expect it to perform better if you map the server as a regular drive. Don't know if you can do that.
John
[a href=\"index.php?act=findpost&pid=79187\"][{POST_SNAPBACK}][/a]

John, I tried creating a network share on 'Q:\' rather than just selecting the name of the server \\Archive when I remapped the folder. In both cases the problem still occurs, it takes 40 seconds to expand a folder in the organise panel !

I can't beleive that IView havent fixed this. Since reading your posting I've gone out and investigated DAM and bought Peter Kroghs excellent book. Now I've read it, I'm keen to keep using IView if possible, but this performance issue is a real deal breaker.

Lightroom seems to assist the kind of workflow Peter Krogh suggests in a very streamlined and effective way. Assuming that they beef up the DAM in version 1.0 then  I think it could be an IView killer.
Logged

@foliobook
Foliobook professional photography folio for iPad
www.foliobook.mobi
john beardsworth
Sr. Member
****
Offline Offline

Posts: 2739



WWW
« Reply #8 on: October 14, 2006, 02:31:31 AM »
ReplyReply

Quote
I guess this large size is because of the size of the previews you are creating? I have 30,000 images from 2005 which fit in a single 256Mb catalog.  I can see the attraction of having big previews available, but maybe thats a current limitation that may eventually go away.
[a href=\"index.php?act=findpost&pid=80346\"][{POST_SNAPBACK}][/a]
Portfolio does this better - the previews are stored as jpegs in a separate preview folder. That's also what Lightroom does - the .noindex files are actually jpegs (just try renaming one).

As for iView, you do have to think about the balance of thumbnail sizes + quality, which I recommend as 320 / medium, and whether you need previews which increase the catalogue file size 2-300% and only seem of great use with offline images. Hopefully the Microsoft acquisition will mean better database options.

John
Logged

john beardsworth
Sr. Member
****
Offline Offline

Posts: 2739



WWW
« Reply #9 on: October 14, 2006, 02:44:13 AM »
ReplyReply

Quote
Lightroom seems to assist the kind of workflow Peter Krogh suggests in a very streamlined and effective way. Assuming that they beef up the DAM in version 1.0 then  I think it could be an IView killer.
I suspect your conclusion is a pretty good bet, if iView stands still, but first LR has to radically improve its file management. It's a deal breaker if you can't use it to move any files between folders, list files that aren't where LR thinks they are, reset folder paths, and verify that all a folder's contents are in the library, and the managed shoots concept is repeating the very thing that attracted the most derision when Aperture was announced. But I'm sure Adobe are listening to views on these aspects.

John

ps do you mean "a network share"? I've no experienced of NAS but I was suggesting a mapping drive
« Last Edit: October 14, 2006, 02:45:59 AM by johnbeardy » Logged

seanmcfoto
Full Member
***
Offline Offline

Posts: 176


« Reply #10 on: October 15, 2006, 10:08:00 PM »
ReplyReply

Quote
That's also what Lightroom does - the .noindex files are actually jpegs (just try renaming one).

[a href=\"index.php?act=findpost&pid=80348\"][{POST_SNAPBACK}][/a]
John,
We've discussed this elsewhere, but is there a way to make an OS see .noindex as image files?
As you know I'm on a mac and it would be good to be able to browse these files. You could eve keep a catalogue of them
Logged

john beardsworth
Sr. Member
****
Offline Offline

Posts: 2739



WWW
« Reply #11 on: October 16, 2006, 02:15:49 AM »
ReplyReply

Quote
John,
We've discussed this elsewhere, but is there a way to make an OS see .noindex as image files?
As you know I'm on a mac and it would be good to be able to browse these files. You could eve keep a catalogue of them
[a href=\"index.php?act=findpost&pid=80599\"][{POST_SNAPBACK}][/a]
I've not enough Mac experience to offer a suggestion. But on Windows, right click and Open With. Then associate noindex with whatever program you want. There's also a way using Tools > Folder Options.

These files appear a little too volatile to bother cataloging but it may be possible to create an app that uses them to generate web proofs or use the jpegs in some other way, using the LR data via ODBC. But other than proving the concept, I've not dug much more along this track.

John
Logged

francois
Sr. Member
****
Offline Offline

Posts: 6782


« Reply #12 on: October 16, 2006, 06:17:10 AM »
ReplyReply

Quote
John,
We've discussed this elsewhere, but is there a way to make an OS see .noindex as image files?
As you know I'm on a mac and it would be good to be able to browse these files. You could eve keep a catalogue of them
[a href=\"index.php?act=findpost&pid=80599\"][{POST_SNAPBACK}][/a]

You can rename the file and change the extension (in the Finder, just click on the name of the file and wait about 1 second an click again, the name will become editable). The Finder will just ask for confirmation.  As an aternative, you can select the file in the Finder and use CMD+I (get info), an info window will be displayed and there you'll be able to rename the file.
Logged

Francois
john beardsworth
Sr. Member
****
Offline Offline

Posts: 2739



WWW
« Reply #13 on: October 16, 2006, 06:29:08 AM »
ReplyReply

Quote
You can rename the file and change the extension (in the Finder, just click on the name of the file and wait about 1 second an click again, the name will become editable). The Finder will just ask for confirmation.  As an aternative, you can select the file in the Finder and use CMD+I (get info), an info window will be displayed and there you'll be able to rename the file.
[a href=\"index.php?act=findpost&pid=80651\"][{POST_SNAPBACK}][/a]
Francois
I think Sean is asking about how to get another program to display these files, without renaming them and so making them unavailable to Lightroom.
John
Logged

francois
Sr. Member
****
Offline Offline

Posts: 6782


« Reply #14 on: October 16, 2006, 07:52:26 AM »
ReplyReply

Quote
Francois
I think Sean is asking about how to get another program to display these files, without renaming them and so making them unavailable to Lightroom.
John
[a href=\"index.php?act=findpost&pid=80654\"][{POST_SNAPBACK}][/a]
John,
Thanks for correcting me. I read too fast and completely missed the point... Should have stayed in bed this morning!

By the way, on a Mac, there's also an "Open with..." command accessible through a contextual menu (control-click or right-click on the file) or through the "Get Info" window in the Finder.
« Last Edit: October 16, 2006, 08:09:20 AM by francois » Logged

Francois
free1000
Sr. Member
****
Offline Offline

Posts: 400


WWW
« Reply #15 on: October 17, 2006, 12:16:00 PM »
ReplyReply

Another point on IView...

I reported the poor network drive performance via the Iview support.  They gave me an interesting answer.

Apparently the organise panel does repeatedly check for consistency between the IView library and the drive holding the files. This happens even if 'update folder' is turned off...

I'm glad that they have made this clear, as it has important implications for professional users or other people with tens of thousands of images in their archives.

As far as I can see this means that IView is not scalable for network use. Much as I love its facilities you can't really use it except for online files.  

I think that this is a major problem, though I will deal with it by moving my archive back online and using the NAS as a backup device instead. Not ideal... but will provide a solution until Lightroom v2.0   :-)  brings in the full DAM we need.
Logged

@foliobook
Foliobook professional photography folio for iPad
www.foliobook.mobi
terence_patrick
Full Member
***
Offline Offline

Posts: 149


WWW
« Reply #16 on: October 26, 2006, 04:43:23 AM »
ReplyReply

I've been using LR on-and-off since beta v3 and more heavily with v4.1.  So far, I've got about 11,000 images in the library and find that it's difficult for me to use when LR manages the library for me; I definitely prefer using my own filing system.  One thing about LR's library that feels weak when doing my edits is only being able to use a star-rating system.  I really enjoy using iView's color coding and star-rating.  I like being able to select multiple parameters of selection in iView (images coded "green" + rated 5-star).  Using those selection methods along with easy (for me) keywording functions makes LR's implementation feel clunky.  Having not to wait as I quickly scroll down a long list of thumbnails for the images to "focus" is probably iViews major victory over LR for me.  What would be great is if ACR could have all of LR's develop module controls, so I can continue to use ACR with iView, but then I guess that would defeat the purpose of LR in the first place.
Logged
mikeseb
Sr. Member
****
Offline Offline

Posts: 482



WWW
« Reply #17 on: October 26, 2006, 09:37:20 AM »
ReplyReply

I guess I never considered this question in terms of iVMP versus Lightroom; LR is miles from being an acceptable DAM solution so I don't regard it as a "lightroom killer" by any stretch.

Assuming that Adobe can sort out LR's awkward import/ingestion/folder functions so that they more closely resemble what you can do with a good third-party ingester and iView together (watched folders, ability to manipulate file structure thru LR), I can see the two programs becoming the only ones I'd need except for those images that need detailed PS work.

We've all been burned by huge bloatware that purports to be all things to all users, and maybe keeping image-correction and DAM functions separate in two clean, well-designed and smoothly coexisting programs would be the best way to go.
Logged

michael sebastian
Website  |  Blog
Pages: [1]   Top of Page
Print
Jump to:  

Ad
Ad
Ad