ACDSee Forums: Forum: ACDSee Pro 2 and 2.5

ACDSee Forums: Forum: ACDSee Pro 2 and 2.5 - Recent Posts http://community.acdsee.com/forums/ ACDSee Forums: Forum: ACDSee Pro 2 and 2.5 - Recent Posts en Sat, 21 Nov 2009 14:40:12 +0000 tdi on "unable to import photos" http://community.acdsee.com/forums/topic/unable-to-import-photos#post-45374 Sat, 21 Nov 2009 05:33:48 +0000 tdi 45374@http://community.acdsee.com/forums/ I have full-control set on my folder(s).  and the issue comes and goes... it will work fine for a while, then suddenly I can't make it work no matter what...  then one day I'll try again and it's working correctly.  major irritation.  :/ sales@scalesusa.com on "ACDSee and Windows 7" http://community.acdsee.com/forums/topic/acdsee-and-windows-7#post-45372 Sat, 21 Nov 2009 04:00:47 +0000 sales@scalesusa.com 45372@http://community.acdsee.com/forums/ <blockquote><cite><a href="#post-45371">don_1953 said:</a></cite> I'm holding off upgrading my computer to Windows 7 for now, but it sounds 50/50 whether  ACDSEE Pro V2.5 is going to work or not..... I need to double my RAM before I want to try Windows 7. I've been very loyal to ACDSee over the years, I've bought at least 8 different versions, going back to ACDSee 2 something. But being forced to buy the 3.0 version seems a stretch, my wife has been out of work for a year.... too bad they don't have any special upgrade packages for longtime loyal customers.   You and I are in the same boat, I know I started using ACDSEE a long time ago, either version 1 or two.  It was before the world wide web, we used unix commands to navigate the internet and opened gif images using acdsee in DOS.  I've been a user since then, but pro 3 is not what I want, I much prefer lightroom, so a expensive underperforming copy of Lightroom is not what I want. Perhaps I'll return to the basic ACDSEE for browsing, and use lightroom for editing.                                                                                       </blockquote>   don_1953 on "ACDSee and Windows 7" http://community.acdsee.com/forums/topic/acdsee-and-windows-7#post-45371 Sat, 21 Nov 2009 03:33:30 +0000 don_1953 45371@http://community.acdsee.com/forums/ I'm holding off upgrading my computer to Windows 7 for now, but it sounds 50/50 whether  ACDSEE Pro V2.5 is going to work or not..... I need to double my RAM before I want to try Windows 7. I've been very loyal to ACDSee over the years, I've bought at least 8 different versions, going back to ACDSee 2 something. But being forced to buy the 3.0 version seems a stretch, my wife has been out of work for a year.... too bad they don't have any special upgrade packages for longtime loyal customers. Marc Sabatella on "All the years - Database is the culprit: Kill it !" http://community.acdsee.com/forums/topic/all-the-years-database-is-the-culprit-kill-it#post-45303 Thu, 19 Nov 2009 03:24:34 +0000 Marc Sabatella 45303@http://community.acdsee.com/forums/ <blockquote> <cite><a href="#post-45275">dfidler said:</a></cite> I've been using ACDSee since the mid 90s (ACDSee v3 IIRC) and I've been asking for DBMS support for most of that time. </blockquote> I agree that having a more portable, robust, multi-user db interface would be great!  I think you've done a good job describing some of the issues that would presumably be involved, but at some point, I suspect they'll run into enough limitations with the current db that they'll have no choice. <blockquote> As an aside: I must admit that I've recently switched to Adobe Bridge + Photoshop. Bridge provides the option to write all of the catalog info to the directory in which the files live. </blockquote> BTW, not sure if you knew this, but ACDSee as of Pro 2.5 has the ability to write its db info to the files themselves (as a backup, mostly, or a means of sharing info - the primary copy of the info is still in the central db).  I actually used this to transfer all my dbinfo from 2.5 to 3.0 - rather than try to convert the db, I just exported all the db info from 2.5 into the files, then ran Catalog Files on 3.0 to read it in.  I've also used this to get my db info to follow files when moving between drives and so forth. It's not perfect, but it's an improvement over the situation pre-2.5 Anyhow. thanks for a thought-provoking post, and I hope ACD is also thinking along these lines... dfidler on "All the years - Database is the culprit: Kill it !" http://community.acdsee.com/forums/topic/all-the-years-database-is-the-culprit-kill-it#post-45275 Wed, 18 Nov 2009 11:25:59 +0000 dfidler 45275@http://community.acdsee.com/forums/ I've been using ACDSee since the mid 90s (ACDSee v3 IIRC) and I've been asking for DBMS support for most of that time.  This is not a new request; it comes up with every new release and ACD Systems says that they'll consider it with every major point release. But like all end-users, I've made the mistake of stating a feature requrest as a requirement rather than stating my actual requirements.  The two primary requirements that I see as driving this are as follows: <ol> <li>Ability to share the catalog on multiple computers, at the same time (CRITICAL as more and more families have have more than one computer).</li> <li>Ability to query the catalog outside of ACDSee</li> </ol> Implementing a DBMS is certainly the most obvious solution to these requirements, but it's not the only solution, by any means. And please note that implementing a DBMS is a huuuuge undertaking which leaves ACD Systems with several problems.  How do they give us power users DBMS support but still keep it simple for the majority of their user base? They can either deploy a light weight DBMS with ACDSee Pro and write all of the export/backup/restore routines but then what happens if the dbms's data files become corrupt?  What happens if the DBMS is down, temporarily?  Does ACDSee refuse to start or does it act as Marc metioned above (many features are disabled until the DBMS comes back on line).  I can envision times where the DMBS is down and people absolutely NEED to get those photos off of the camera, editted, and then shipped to printing NOW!!!!!!  So refusing to start isn't a valid option.  What happens if users want to migrate their existing catalog to the DBMS (or back to a file based system)? Okay, so what about using ODBC?  Bad idea.  The windows implementation is nothing short of retarded and would frustrate many users.  They would likely just give up and bitch about it even more. The other option is to support the old catalog AND a DBMS.  But that's expensive too because they need to rewrite one of two things.  Either rewrite the existing catalog technology so that it accepts SQL queries (or use the Borland one... which I also think is a bad idea) which also means modifying their application to use SQL only.  Or they need to add support for an SQL DB right along side support for their existing catalog (this is also terrible because it means they now have two storage code paths to maintain; bleh). Then there is the question of what do they store in the DB?  Catalog info only or do they allow you to store the images in the DB?  If the latter, then that's a huuuuge problem because you start to need non-free versions of Oracle or SQL Server.  And mysql suffers massive performance problems when you start storing files > 16MB in it.   Do they also store thumbnails in it too?  How much performance are you going to lose downloading the thumbnails from a dbms than from a local or network disk?  So should the thumbnail cache be local? And with a central catalog, storage of files is now an issue for sharing the catalog.  Example:  I store all of my files on a shared disk which I mount, globally, as drive 'G'.  But the wife is constantly downloading files directly to her laptop (and I have tons of non-photographic images on my desktop).  What happens when both my wife and I have different images of the same name in the same directory?  Okay, store the 'machine name' along with the picture.  Wrong.  What happens if I reinstall my PC and rename it?  I've now lost all of my catalog info, even though I've copied the files into the same place?  Okay, what about using md5 hashes to identify files?  Better, but now you have to calculate md5 hashes for every file, on the fly.  That's expensive and takes CPU power.  Okay, so do a query by per MachineName:/path/to/file, if it retuns no hits, do an MD5 hash on the file, query the DB for files matching the md5 hash and present the catalog info to the users.  But wait... what if this is a duplicate file of another one that exists somewhere else?  Do I allow the user to 'steal' this catalog record or 'duplicate' it?   What happens if I move my files from c:\users\dfidler\acdseepix to g:\shared\drive\acdseepix?  How does ACDsee determine that the files have moved?  Does it just create new catalog entries or does it ask me if I've moved my files based on the filesize and md5 checksum?  (I'd prefer the latter so I can keep my catalog info for the moved files)  If it creates new entries, I now have orphaned catalog info in my database which is wasting space (not to mention that I've lost the catalog info for my moved files).  This means that they'll also need some kind of optimization process to clean out the database; per ACDSee instance. They can go the Adobe route and build a server-based solution that stores all of the files for you (internally) and uses the DBMS as a back-end.  You then check these files in and out to work on them.  Then catalog info on all locally stored files is stored in the local catalog.  There are problems with this implementation too.  What platform do you write it for (windows is the obvious choice, but then everyone is going to bitch about Linux support; myself included).  And in reality, this kind of implementation lends itself well to larger organizations rather than ACDSee's market, which is the home users and Pro shops that have 1-3 users.  I suspect that most larger shops are already using the Adobe solution (and will continue to do so because of the integration with Photoshop). And using MS SQL Server (or Oracle or DB2) as their primary data source is a really bad idea (assuming an integrated solution). Less than 1% of ACDSee users will be able to manage a DBMS (especially the 'big boys of the DB world).  Mysql (though I don't really like it) is the most common dbms out there.  More and more users have some kind of experience with it.  But everyone who is not a mysql fan is going to bitch, endelessly, about the fact that their favorite DB flavour isn't supported. So does ACD Systems create a pluggable API that does DB support? Aside: I'd recommend that they make this a pluggable API; provide an abstract base class that provides all of the get/set functions required to interface with the application which saavy programmers can then use to add support for different databases.  Of course, this API would need to do version checking to ensure that old DB plugins are not used with newer versions of the program; lest database corruption may ensue.  Or they can simple decide to 'own' all plugins to ensure consistency of code quality but I suspect that ACD System's Engineering and QA teams don't currently have the expertise for that. Anyways, I'm rambling, sorry.   While I've always been annoyed at ACDSee for not implementing this feature, I do understand (being a former DBA and Software Engineer, not affiliated with ACD Systems) the number of issues that surround this request.  They are not insurmountable issues but they are expensive ones to solve.  First and fore-most, ACDSystems has to implement something that is both rock solid and dead simple to use, yet flexible enough to satisfy the 'I want to share/query my catalog info'.  That's no easy request. As an aside: I must admit that I've recently switched to Adobe Bridge + Photoshop.  Bridge provides the option to write all of the catalog info to the directory in which the files live.  Unfortunately, Adobe RAW and Bridge are both riddled with memory leaks and various other "stupid software tricks" (tm) [and Adobe is slow to react to user feedback, if they even care to at all]. But the catalog info generally moves with my files as I move directories around (and my wife can see the edits and catalog info as soon as she clicks on the files).  ACDSee and Bridge raw edits are also completely incompatible (this is not surprising) and my ACDsee edits don't carry over into Photoshop.  But then, I look at the cost of the Adobe solution; $1000 vs the $150 for ACDSsystems; ACDSee gives some truly amazing value for it's price point.  And by switching to Bridge, I felt like I was stabbing an old friend in the back, but needs-must.  I now only use ACDSee for quick edits, etc, that I don't care about (resizing already editted files, quick directory browsing, etc). So I now question whether it makes sense for ACD Systems to implement the DBMS feature.  I think it's truly great that they are committed to it (and,  honestly, it's one of the two reasons that I started looking elsewhere for another package) but then, as I said, 99%+ of their users have no need for a DBMS.   So does ACDSee need to support a proper DBMS?  I can't answer that question.  Using a DBMS is certainly the first thing that comes to mind but it's not the only solution. Anyways, I'm rambling again... sorry. Cheers, Dave.  sales@scalesusa.com on "Canon 7D raw support" http://community.acdsee.com/forums/topic/canon-7d-raw-support#post-45258 Wed, 18 Nov 2009 00:52:18 +0000 sales@scalesusa.com 45258@http://community.acdsee.com/forums/ <blockquote><cite><a href="#post-45075">Daniel_Simms said:</a></cite> <blockquote> Well I emailed them directly on Monday and its now Thursday and I still haven't had a reply. Lightroom is looking very arrtractive. </blockquote> <blockquote> Lightroom does not support the Canon 7d.  There is a beta, but it isn't very good.  for now, use DPP.  You can set DPP to export your file to ACDSEE and open it as a tiff.   </blockquote> </blockquote> sales@scalesusa.com on "ACDSee and Windows 7" http://community.acdsee.com/forums/topic/acdsee-and-windows-7#post-45257 Wed, 18 Nov 2009 00:49:15 +0000 sales@scalesusa.com 45257@http://community.acdsee.com/forums/ I have ran ACDSEE Pro 2.5 first on the windows 7 beta, and then on the released version.  These were two separate computers, one 64 bit, and the other 32 bit with clean installs. In both cases, the file list is not compatible with Windows 7, it is very difficult to locate a file, and it does not open the file list to your previous location.  This makes it very difficult to use in windows 7, so I am abandoning it unless there is some sort of fix.  There is plenty of other software out there that recognizes the windows 7 file list structure. dave victoria on "ACDSee and Windows 7" http://community.acdsee.com/forums/topic/acdsee-and-windows-7#post-45256 Wed, 18 Nov 2009 00:07:31 +0000 dave victoria 45256@http://community.acdsee.com/forums/ I don't know how some of you people are doing it.  I'm using Pro 2 and just installed Win 7 Professional on my Dell lap top.  There isn't even a hint that Pro 2 will work.  Crashes every time I try it. ACDSee says there's a patch to remove the registry key and I've done that.  Nothing seems to work.  Must say, ACDSee admits Pro2 isn't configured to work with Win 7.  Well they are right, it doesn't.  I've installed and uninstalled and installed till I'm tired of doing it. I've sent them an email complaining about it but haven't got a reply.  I should go an knock on their door.  We're in the same city and they started right here.  I've used ACDSee since their inception and have been super pleased----up until now.  I also haven't seen any place where they say that Pro 3 will work with Win 7.  They just lost and old customer. Dave Heidi on "Problems with videofiles in .mod format" http://community.acdsee.com/forums/topic/problems-with-videofiles-in-mod-format#post-45214 Mon, 16 Nov 2009 14:26:37 +0000 Heidi 45214@http://community.acdsee.com/forums/ If it has a chance to work, yes, I would suggest installing the codecs for your camera.  Usually you can install the software that came with your camera and it will get the right codecs onto your system.  Once installed, ACDSee may or may not show the video. safetysteve on "ACDsee 2.5 crashes when importing photos" http://community.acdsee.com/forums/topic/acdsee-25-crashes-when-importing-photos#post-45208 Mon, 16 Nov 2009 06:38:57 +0000 safetysteve 45208@http://community.acdsee.com/forums/ <blockquote><cite></cite>As far as my own problem, I have found that the problem was because the C drive was too full to hold the temp stuff produced when importing the photo from a card. Worth checking. Once I had cleared some junk, ACDSee worked fine. The reason why ACDSee 3 didn't have the same problem is because I suspect its more efficient in how much temp stuff it produces when importing.</blockquote> lennycorman on "ACDSee and Windows 7" http://community.acdsee.com/forums/topic/acdsee-and-windows-7#post-45200 Sun, 15 Nov 2009 23:26:15 +0000 lennycorman 45200@http://community.acdsee.com/forums/ Got Pro 2 working on Win7 using <a href="http://www.zinstall.com" title="Zinstall">Zinstall</a>! (think XP mode but with all your old apps and data automatically installed there). Haven't tried with 2.5 (haven't got it). Anyone willing to test it out? hydrant on "EXIF:Image:Date/time original" http://community.acdsee.com/forums/topic/exifimagedatetime-original#post-45191 Sun, 15 Nov 2009 19:26:28 +0000 hydrant 45191@http://community.acdsee.com/forums/ Just perfect advice... If you use "Modify | Adjust Image Time Stamp" tool you will 'destroy' correct time information. If you use another program or (even ACDsee somewhere in future when the bug will be finally repaired) you will see shifted timestamps... My workaround stays the same... Do not use ACDSee until they fix this. <img src="//dictionarytip/skin/book.png" /> jbreeves on "EXIF:Image:Date/time original" http://community.acdsee.com/forums/topic/exifimagedatetime-original#post-45185 Sun, 15 Nov 2009 19:13:52 +0000 jbreeves 45185@http://community.acdsee.com/forums/ Here is the ACDSee response. It is absurd that they have allowed this bug to live on for years! Brent --------------------------------------------------------------- Response (Marie-Eve P.) - 10/28/2009 10:17 AM Dear Mr.Reeves, Thank you for contacting ACD Systems Customer Support. The issue in question has been reported to our QA and Development Team for investigation. Should we require additional information, we will contact you. We appreciate your cooperation and feedback. Here is a workaround to resolve the issue : If the EXIF Date/Time Original differs by one hour in ACDSee, as compared with the time indicated by the camera. You can use the Adjust Time Stamp tool to change the date and time properties of one or more files in the Browser or in the Viewer. To change the date and time properties of a file, do one of the following: In the Browser, select one or more files, and click Tools | Adjust Image Time Stamp. In the Viewer, click Modify | Adjust Image Time Stamp. To continue this correspondence, please just hit “reply” to this email. Regards, Marie-Ève P. Customer Support ACD Systems --------------------------------------------------------------- QuBe on "ACDSee and Windows 7" http://community.acdsee.com/forums/topic/acdsee-and-windows-7#post-45184 Sun, 15 Nov 2009 18:48:02 +0000 QuBe 45184@http://community.acdsee.com/forums/ Pro 2.5 working fine here on W7. (RC 7100 with all updates.) In fact, my XP Pro reg keys for 2.5 actually imported without a hitch as well. Saved me an hour of config time. Sweet! QuBe. Janeka on "Problems with videofiles in .mod format" http://community.acdsee.com/forums/topic/problems-with-videofiles-in-mod-format#post-45166 Sat, 14 Nov 2009 23:17:11 +0000 Janeka 45166@http://community.acdsee.com/forums/ Hi Everbody, Im using ACDSee 2.5 and Windows 7. I would like to organize also my videos with ACDSee. The problem is, I have a JVC-Camcorder which produces files in .mod format. Unfortunatly its noch possible to see them inside ACDSee, never mind a thumbnail. I pretty sure on my old computer I could see them. Im not very familiar with videostuff, so I dont know what is the reason. Do I need codecs (whatever the hell this is) or is there something else I can do?   Thanks for help Janeka   Shutterbug63 on "ACDSee and Windows 7" http://community.acdsee.com/forums/topic/acdsee-and-windows-7#post-45155 Sat, 14 Nov 2009 13:15:25 +0000 Shutterbug63 45155@http://community.acdsee.com/forums/ I have ACDSee Pro 2 and haven't have any problems at all running it first on XP, then with Vista and now with Windows 7. Doesn't seem to really make any difference what kind of OS in running under. Install and works perfectly! LOVE IT!! Marc Sabatella on "Approximate Dates such as year only or year + month only" http://community.acdsee.com/forums/topic/approximate-dates-such-as-year-only-or-year-month-only#post-45132 Fri, 13 Nov 2009 22:12:01 +0000 Marc Sabatella 45132@http://community.acdsee.com/forums/ Both ACDSee's database and the EXIF info in the image files themselves understand only actual dates, not approximations.  So one way or another, you've got to enter something specific.  Probably lots of different shortcuts you could use to enter info quickly, but one way or another, it's going to be specific dates that get entered. John Radcliffe on "Approximate Dates such as year only or year + month only" http://community.acdsee.com/forums/topic/approximate-dates-such-as-year-only-or-year-month-only#post-45123 Fri, 13 Nov 2009 14:28:27 +0000 John Radcliffe 45123@http://community.acdsee.com/forums/ The only "solution" I can see is to use two separate fields (I'll call then Date1 and Date2) to allow a date span. If you know the date exactly then Date1 = Date2. Of course this would increase the data input required, but if it does what you want it might be worth the effort. E.g. "Images One": thought to have been taken early in 1995 > set Date1 = 1 Jan 1995 and Date2 = 31 Feb 1995 "Image Two": might have been taken any time from 1991 to 1995 > set Date1 = 1 Jan 1991 and Date2 = 31 Dec 1995 In this case a search for images "possibly taken in the second half of 1995" (by specifying "Date1 before 23:59 on 30 Jun 1995" [the end of the search period] and "Date2 after 23:59 on 31 Dec 1994" [the start] ) would return both images. You might consider using "Date/Time original" for Date1 and "Date/Time digitized" for Date2 as for any digital camera images these should automatically be the same. Shabbadang on "Colour Management and Printing" http://community.acdsee.com/forums/topic/colour-management-and-printing#post-45110 Thu, 12 Nov 2009 22:25:19 +0000 Shabbadang 45110@http://community.acdsee.com/forums/ The problem is now sorted out. See the link in the above post. Melanie Wood on "Canon 7D raw support" http://community.acdsee.com/forums/topic/canon-7d-raw-support#post-45105 Thu, 12 Nov 2009 18:01:34 +0000 Melanie Wood 45105@http://community.acdsee.com/forums/ Daniel, November 11th (the Wednesday when you posted) is Remembrance Day here in Canada and the office was closed. Please allow five to seven business days for a reply. -Melanie