From chaz at yorba.org Wed May 1 18:04:48 2013 From: chaz at yorba.org (Charles Lindsay) Date: Wed, 1 May 2013 11:04:48 -0700 Subject: [Shotwell] Yorba's redmine temporarily unavailable Message-ID: Hi all, We're going to be doing a little cleanup of our Redmine ticket database in a few minutes here, and to avoid flooding our users with a barrage of emails, we'll be taking our Redmine offline for an hour or so. We hope to be back up by around noon Pacific time. Thanks for your patience. Cheers, Charles From chaz at yorba.org Thu May 2 22:32:14 2013 From: chaz at yorba.org (Charles Lindsay) Date: Thu, 02 May 2013 22:25:14 -0007 Subject: [Shotwell] [Geary] Yorba's redmine temporarily unavailable In-Reply-To: <5182e840.cd00340a.5394.ffff88e2@mx.google.com> References: <5182e840.cd00340a.5394.ffff88e2@mx.google.com> Message-ID: <5182e96f.035a440a.22c6.ffffaa08@mx.google.com> Uh oh, this was probably an unintended side effect of us making the projects private (we also had to temporarily remove the few external contributers we have from the projects, so maybe that confused Redmine). I can't look into it at this moment, but in a few hours I'll see if I can undo the damage. Sorry about that! Charles On Thu, May 2, 2013 at 3:27 PM, Robert Schroll wrote: > I just found that my list of watched issues has been culled rather > dramatically. I'm assuming this happened during the database > maintenance. Was this intentional? Can it be reversed? > > Thanks, > Robert > > > On Wed, May 1, 2013 at 2:04 PM, Charles Lindsay > wrote: >> Hi all, >> >> We're going to be doing a little cleanup of our Redmine ticket >> database in >> a few minutes here, and to avoid flooding our users with a barrage of >> emails, we'll be taking our Redmine offline for an hour or so. We >> hope to >> be back up by around noon Pacific time. Thanks for your patience. >> >> >> Cheers, >> Charles >> _______________________________________________ >> Geary mailing list >> Geary at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/geary >> >> From chaz at yorba.org Fri May 3 02:47:13 2013 From: chaz at yorba.org (Charles Lindsay) Date: Fri, 03 May 2013 02:40:13 -0007 Subject: [Shotwell] [Geary] Yorba's redmine temporarily unavailable In-Reply-To: <5182e96f.035a440a.22c6.ffffaa08@mx.google.com> References: <5182e840.cd00340a.5394.ffff88e2@mx.google.com> <5182e96f.035a440a.22c6.ffffaa08@mx.google.com> Message-ID: <51832532.4f79420a.316a.1d93@mx.google.com> I restored the watch list from backup for you and the few other affected individuals. It looks like I was right earlier when I said when we removed you from the project temporarily, Redmine just dropped your watch list. Please let me know if you or anyone else notice anything else wonky with your account, and apologies once again! Charles On Thu, May 2, 2013 at 3:32 PM, Charles Lindsay wrote: > Uh oh, this was probably an unintended side effect of us making the > projects private (we also had to temporarily remove the few external > contributers we have from the projects, so maybe that confused > Redmine). I can't look into it at this moment, but in a few hours > I'll see if I can undo the damage. Sorry about that! > > > Charles > > > On Thu, May 2, 2013 at 3:27 PM, Robert Schroll > wrote: >> I just found that my list of watched issues has been culled rather >> dramatically. I'm assuming this happened during the database >> maintenance. Was this intentional? Can it be reversed? >> >> Thanks, >> Robert >> >> >> On Wed, May 1, 2013 at 2:04 PM, Charles Lindsay >> wrote: >>> Hi all, >>> >>> We're going to be doing a little cleanup of our Redmine ticket >>> database in >>> a few minutes here, and to avoid flooding our users with a barrage >>> of >>> emails, we'll be taking our Redmine offline for an hour or so. We >>> hope to >>> be back up by around noon Pacific time. Thanks for your patience. >>> >>> >>> Cheers, >>> Charles >>> _______________________________________________ >>> Geary mailing list >>> Geary at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/geary >>> >>> From emailgrant at gmail.com Fri May 3 20:02:10 2013 From: emailgrant at gmail.com (Grant) Date: Fri, 3 May 2013 13:02:10 -0700 Subject: [Shotwell] Shotwell crashes when importing with "Copy Photos" In-Reply-To: References: Message-ID: >> You're the only person who's ever reported having this problem, and -- >> unfortunately -- it looks like you've been having it for a while too, given >> that we sent some messages back-and-forth about this six months ago. Out of >> curiosity, have you re-installed your operating system between then and now? >> If you haven't, it might be something to consider. There may be something >> about the configuration mapper on your machine that is just broken. Other >> than advising that, there's little more we can do on this end. You very >> helpfully submitted stack traces and log files late last year and, upon >> examining them, it was clear that the problem occurred deep inside of the >> GSettings-to-GConf mapper (gconfsettingsbackend). This might be an issue for >> you to take up on their mailing list or Bugzilla. In Shotwell, we use >> GSettings in way wholly compliant with GSettings best practices. Another >> place you might want to bring this up is on a Gentoo mailing list. >> Specifically, I'd ask the Gentoo packagers why they're using a >> GSettings-to-GConf mapper, because GSettings is designed as an evolution >> over GConf and should have no relation to it whatsoever. This is discussed >> in the GNOME Goal Blueprint Paper on GConf to GSettings Migration here: >> https://live.gnome.org/GnomeGoals/GSettingsMigration. > > Thank you for the info. This should be enough to get me going in the > right direction. I'll report back if I find anything. > > - Grant I'm happy to report that all I had to do was install dconf and now shotwell seems to be working perfectly. - Grant >>> I've been having a problem with Shotwell crashing when importing with >>> the "Copy Photos" option as opposed to "Import in Place" which does >>> not crash. I was having this problem with 0.13.1 as described in this >>> thread: >>> >>> http://shotwell.996238.n3.nabble.com/Crashes-when-importing-td56658.html >>> >>> and now 0.14.0. I have tried deleting .gconf/org/yorba/shotwell >>> (.gconf/apps/shotwell does not exist) but the result is the same. I >>> get various errors in the console such as these: >>> >>> (shotwell:6623): GConf-CRITICAL **: gconf_engine_pop_owner_usage: >>> assertion `engine->owner_use_count > 0' failed >>> >>> (shotwell:14699): GLib-CRITICAL **: g_propagate_error: assertion `src >>> != NULL' failed >>> >>> ERROR:gconfsettingsbackend.c:205:gconf_settings_backend_remove_notifier: >>> assertion failed: (notifier && g_str_equal (path, notifier->path)) >>> >>> I'm on Gentoo fully up-to-date. From emailgrant at gmail.com Fri May 3 20:17:43 2013 From: emailgrant at gmail.com (Grant) Date: Fri, 3 May 2013 13:17:43 -0700 Subject: [Shotwell] Some photos not importing/copying? Message-ID: I imported/copied a large number of photos into shotwell from a folder and I was about to delete the folder but I noticed at least several photos that did not import or copy. Why would some photos import and not others? - Grant From jim at yorba.org Fri May 3 22:05:36 2013 From: jim at yorba.org (Jim Nelson) Date: Fri, 03 May 2013 21:58:36 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: Message-ID: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> There's many reasons. At the end of an import, Shotwell should give you a list explaining why photos were not imported. In Shotwell 0.14, it will offer to save a text file giving a full report. The most likely cases are that the photos were byte-for-byte duplicates of other photos (Shotwell won't import duplicates), that they are not photo files (corrupted or named incorrectly), or that Shotwell doesn't support their data format (GIF is the most prominent for example). -- Jim On Fri, May 3, 2013 at 1:17 PM, Grant wrote: > I imported/copied a large number of photos into shotwell from a folder > and I was about to delete the folder but I noticed at least several > photos that did not import or copy. Why would some photos import and > not others? > > - Grant > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From emailgrant at gmail.com Fri May 3 22:26:03 2013 From: emailgrant at gmail.com (Grant) Date: Fri, 3 May 2013 15:26:03 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> Message-ID: > There's many reasons. At the end of an import, Shotwell should give you a > list explaining why photos were not imported. In Shotwell 0.14, it will > offer to save a text file giving a full report. > > The most likely cases are that the photos were byte-for-byte duplicates of > other photos (Shotwell won't import duplicates), that they are not photo > files (corrupted or named incorrectly), or that Shotwell doesn't support > their data format (GIF is the most prominent for example). > > -- Jim Hi Jim, I import and copy my photos from /home/grant/photodump/ to /home/grant/Pictures/. I have: # updatedb && locate IMG_20130303_144420 /home/grant/photodump/IMG_20130303_144420.jpg # "Shotwell Import Log.txt" says: /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing media item /home/grant/photodump/IMG_20130303_144420.jpg Can you help me reconcile this? - Grant > I imported/copied a large number of photos into shotwell from a folder and I > was about to delete the folder but I noticed at least several photos that > did not import or copy. Why would some photos import and not others? - Grant From jim at yorba.org Mon May 6 18:17:01 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 06 May 2013 18:10:01 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> Message-ID: <5187f393.68ed440a.7e71.6a5d@mx.google.com> It looks to me that you're attempting to import the same file (not a duplicate, but the same file) a second time. In other words, the file you're attempting to import is already in the library. -- Jim On Fri, May 3, 2013 at 3:26 PM, Grant wrote: >> There's many reasons. At the end of an import, Shotwell should >> give you a >> list explaining why photos were not imported. In Shotwell 0.14, it >> will >> offer to save a text file giving a full report. >> >> The most likely cases are that the photos were byte-for-byte >> duplicates of >> other photos (Shotwell won't import duplicates), that they are not >> photo >> files (corrupted or named incorrectly), or that Shotwell doesn't >> support >> their data format (GIF is the most prominent for example). >> >> -- Jim >> > Hi Jim, I import and copy my photos from /home/grant/photodump/ to > /home/grant/Pictures/. I have: > > # updatedb && locate IMG_20130303_144420 > /home/grant/photodump/IMG_20130303_144420.jpg > # > > "Shotwell Import Log.txt" says: > > /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing > media item > /home/grant/photodump/IMG_20130303_144420.jpg > > Can you help me reconcile this? > > - Grant > > >> I imported/copied a large number of photos into shotwell from a >> folder and I >> was about to delete the folder but I noticed at least several >> photos that >> did not import or copy. Why would some photos import and not >> others? - Grant >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From emailgrant at gmail.com Mon May 6 19:16:44 2013 From: emailgrant at gmail.com (Grant) Date: Mon, 6 May 2013 12:16:44 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <5187f393.68ed440a.7e71.6a5d@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> Message-ID: > It looks to me that you're attempting to import the same file (not a > duplicate, but the same file) a second time. In other words, the file > you're attempting to import is already in the library. > > -- Jim locate only finds the file in my target folder, not in my destination folder: # updatedb && locate IMG_20130303_144420 /home/grant/photodump/IMG_20130303_144420.jpg # But it refuses to import the file with the log message indicating it has already been imported. Could shotwell have renamed the file when it was copied to the destination folder? I'm on 0.14.1. - Grant > There's many reasons. At the end of an import, Shotwell should give you a > list explaining why photos were not imported. In Shotwell 0.14, it will > offer to save a text file giving a full report. The most likely cases are > that the photos were byte-for-byte duplicates of other photos (Shotwell > won't import duplicates), that they are not photo files (corrupted or named > incorrectly), or that Shotwell doesn't support their data format (GIF is the > most prominent for example). -- Jim > > Hi Jim, I import and copy my photos from /home/grant/photodump/ to > /home/grant/Pictures/. I have: # updatedb && locate IMG_20130303_144420 > /home/grant/photodump/IMG_20130303_144420.jpg # "Shotwell Import Log.txt" > says: /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing > media item /home/grant/photodump/IMG_20130303_144420.jpg Can you help me > reconcile this? - Grant > > I imported/copied a large number of photos into shotwell from a folder and I > was about to delete the folder but I noticed at least several photos that > did not import or copy. Why would some photos import and not others? - Grant From jim at yorba.org Tue May 7 00:36:39 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 07 May 2013 00:29:39 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> Message-ID: <51884ca0.2603430a.2119.ffffd814@mx.google.com> How are you importing the photos? Drag-and-drop or with File -> Import From Folder? -- Jim On Mon, May 6, 2013 at 12:16 PM, Grant wrote: >> It looks to me that you're attempting to import the same file (not a >> duplicate, but the same file) a second time. In other words, the >> file >> you're attempting to import is already in the library. >> >> -- Jim >> > locate only finds the file in my target folder, not in my destination > folder: > > # updatedb && locate IMG_20130303_144420 > /home/grant/photodump/IMG_20130303_144420.jpg > # > > But it refuses to import the file with the log message indicating it > has already been imported. Could shotwell have renamed the file when > it was copied to the destination folder? I'm on 0.14.1. > > - Grant > > >> There's many reasons. At the end of an import, Shotwell should give >> you a >> list explaining why photos were not imported. In Shotwell 0.14, it >> will >> offer to save a text file giving a full report. The most likely >> cases are >> that the photos were byte-for-byte duplicates of other photos >> (Shotwell >> won't import duplicates), that they are not photo files (corrupted >> or named >> incorrectly), or that Shotwell doesn't support their data format >> (GIF is the >> most prominent for example). -- Jim >> >> Hi Jim, I import and copy my photos from /home/grant/photodump/ to >> /home/grant/Pictures/. I have: # updatedb && locate >> IMG_20130303_144420 >> /home/grant/photodump/IMG_20130303_144420.jpg # "Shotwell Import >> Log.txt" >> says: /home/grant/photodump/IMG_20130303_144420.jpg duplicates >> existing >> media item /home/grant/photodump/IMG_20130303_144420.jpg Can you >> help me >> reconcile this? - Grant >> >> I imported/copied a large number of photos into shotwell from a >> folder and I >> was about to delete the folder but I noticed at least several >> photos that >> did not import or copy. Why would some photos import and not >> others? - Grant >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From joseph.bylund at gmail.com Tue May 7 01:18:41 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Mon, 06 May 2013 21:18:41 -0400 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <51884ca0.2603430a.2119.ffffd814@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> Message-ID: <51885671.9070507@gmail.com> Grant, There's a shotwell option to rename to lowercase on import maybe it got renamed to lowercase? -Joe On 05/06/2013 08:36 PM, Jim Nelson wrote: > How are you importing the photos? Drag-and-drop or with File -> Import > From Folder? > > -- Jim > > On Mon, May 6, 2013 at 12:16 PM, Grant wrote: >>> It looks to me that you're attempting to import the same file (not a >>> duplicate, but the same file) a second time. In other words, the file >>> you're attempting to import is already in the library. >>> >>> -- Jim >>> >> locate only finds the file in my target folder, not in my destination >> folder: >> >> # updatedb && locate IMG_20130303_144420 >> /home/grant/photodump/IMG_20130303_144420.jpg >> # >> >> But it refuses to import the file with the log message indicating it >> has already been imported. Could shotwell have renamed the file when >> it was copied to the destination folder? I'm on 0.14.1. >> >> - Grant >> >> >>> There's many reasons. At the end of an import, Shotwell should give >>> you a >>> list explaining why photos were not imported. In Shotwell 0.14, it >>> will >>> offer to save a text file giving a full report. The most likely >>> cases are >>> that the photos were byte-for-byte duplicates of other photos >>> (Shotwell >>> won't import duplicates), that they are not photo files (corrupted >>> or named >>> incorrectly), or that Shotwell doesn't support their data format >>> (GIF is the >>> most prominent for example). -- Jim >>> >>> Hi Jim, I import and copy my photos from /home/grant/photodump/ to >>> /home/grant/Pictures/. I have: # updatedb && locate >>> IMG_20130303_144420 >>> /home/grant/photodump/IMG_20130303_144420.jpg # "Shotwell Import >>> Log.txt" >>> says: /home/grant/photodump/IMG_20130303_144420.jpg duplicates >>> existing >>> media item /home/grant/photodump/IMG_20130303_144420.jpg Can you >>> help me >>> reconcile this? - Grant >>> >>> I imported/copied a large number of photos into shotwell from a >>> folder and I >>> was about to delete the folder but I noticed at least several >>> photos that >>> did not import or copy. Why would some photos import and not >>> others? - Grant >>> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From emailgrant at gmail.com Tue May 7 20:42:35 2013 From: emailgrant at gmail.com (Grant) Date: Tue, 7 May 2013 13:42:35 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <51884ca0.2603430a.2119.ffffd814@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> Message-ID: > How are you importing the photos? Drag-and-drop or with File -> Import From > Folder? I'm importing with File -> Import From Folder and I'm choosing Copy Photos. - Grant > It looks to me that you're attempting to import the same file (not a > duplicate, but the same file) a second time. In other words, the file you're > attempting to import is already in the library. -- Jim > > locate only finds the file in my target folder, not in my destination > folder: # updatedb && locate IMG_20130303_144420 > /home/grant/photodump/IMG_20130303_144420.jpg # But it refuses to import the > file with the log message indicating it has already been imported. Could > shotwell have renamed the file when it was copied to the destination folder? > I'm on 0.14.1. - Grant > > There's many reasons. At the end of an import, Shotwell should give you a > list explaining why photos were not imported. In Shotwell 0.14, it will > offer to save a text file giving a full report. The most likely cases are > that the photos were byte-for-byte duplicates of other photos (Shotwell > won't import duplicates), that they are not photo files (corrupted or named > incorrectly), or that Shotwell doesn't support their data format (GIF is the > most prominent for example). -- Jim Hi Jim, I import and copy my photos from > /home/grant/photodump/ to /home/grant/Pictures/. I have: # updatedb && > locate IMG_20130303_144420 /home/grant/photodump/IMG_20130303_144420.jpg # > "Shotwell Import Log.txt" says: > /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing media item > /home/grant/photodump/IMG_20130303_144420.jpg Can you help me reconcile > this? - Grant I imported/copied a large number of photos into shotwell from > a folder and I was about to delete the folder but I noticed at least several > photos that did not import or copy. Why would some photos import and not > others? - Grant From emailgrant at gmail.com Tue May 7 20:43:46 2013 From: emailgrant at gmail.com (Grant) Date: Tue, 7 May 2013 13:43:46 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <51885671.9070507@gmail.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> Message-ID: > There's a shotwell option to rename to lowercase on import maybe it got > renamed to lowercase? > > -Joe I tried this but still only one copy of the photo on my system: # updatedb && locate 144420 /home/grant/photodump/IMG_20130303_144420.jpg # - Grant >> How are you importing the photos? Drag-and-drop or with File -> Import >> From Folder? >> >> -- Jim >> >> On Mon, May 6, 2013 at 12:16 PM, Grant wrote: >>>> >>>> It looks to me that you're attempting to import the same file (not a >>>> duplicate, but the same file) a second time. In other words, the file >>>> you're attempting to import is already in the library. >>>> >>>> -- Jim >>>> >>> locate only finds the file in my target folder, not in my destination >>> folder: >>> >>> # updatedb && locate IMG_20130303_144420 >>> /home/grant/photodump/IMG_20130303_144420.jpg >>> # >>> >>> But it refuses to import the file with the log message indicating it >>> has already been imported. Could shotwell have renamed the file when >>> it was copied to the destination folder? I'm on 0.14.1. >>> >>> - Grant >>> >>> >>>> There's many reasons. At the end of an import, Shotwell should give you >>>> a >>>> list explaining why photos were not imported. In Shotwell 0.14, it will >>>> offer to save a text file giving a full report. The most likely cases >>>> are >>>> that the photos were byte-for-byte duplicates of other photos (Shotwell >>>> won't import duplicates), that they are not photo files (corrupted or >>>> named >>>> incorrectly), or that Shotwell doesn't support their data format (GIF >>>> is the >>>> most prominent for example). -- Jim >>>> >>>> Hi Jim, I import and copy my photos from /home/grant/photodump/ to >>>> /home/grant/Pictures/. I have: # updatedb && locate IMG_20130303_144420 >>>> /home/grant/photodump/IMG_20130303_144420.jpg # "Shotwell Import >>>> Log.txt" >>>> says: /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing >>>> media item /home/grant/photodump/IMG_20130303_144420.jpg Can you help >>>> me >>>> reconcile this? - Grant >>>> >>>> I imported/copied a large number of photos into shotwell from a folder >>>> and I >>>> was about to delete the folder but I noticed at least several photos >>>> that >>>> did not import or copy. Why would some photos import and not others? - >>>> Grant From jim at yorba.org Tue May 7 20:50:58 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 07 May 2013 20:43:58 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> Message-ID: <51896933.2529440a.54cf.ffffb2e3@mx.google.com> In Edit -> Preferences, what is your Library Directory set to? -- Jim On Tue, May 7, 2013 at 1:43 PM, Grant wrote: >> There's a shotwell option to rename to lowercase on import maybe it >> got >> renamed to lowercase? >> >> -Joe >> > I tried this but still only one copy of the photo on my system: > > # updatedb && locate 144420 > /home/grant/photodump/IMG_20130303_144420.jpg > # > > - Grant > > >>> How are you importing the photos? Drag-and-drop or with File -> >>> Import >>> From Folder? >>> >>> -- Jim >>> >>> On Mon, May 6, 2013 at 12:16 PM, Grant >>> wrote: >>>>> >>>>> It looks to me that you're attempting to import the same file >>>>> (not a >>>>> duplicate, but the same file) a second time. In other words, >>>>> the file >>>>> you're attempting to import is already in the library. >>>>> >>>>> -- Jim >>>>> >>>>> >>>> locate only finds the file in my target folder, not in my >>>> destination >>>> folder: >>>> >>>> # updatedb && locate IMG_20130303_144420 >>>> /home/grant/photodump/IMG_20130303_144420.jpg >>>> # >>>> >>>> But it refuses to import the file with the log message indicating >>>> it >>>> has already been imported. Could shotwell have renamed the file >>>> when >>>> it was copied to the destination folder? I'm on 0.14.1. >>>> >>>> - Grant >>>> >>>> >>>>> There's many reasons. At the end of an import, Shotwell should >>>>> give you >>>>> a >>>>> list explaining why photos were not imported. In Shotwell 0.14, >>>>> it will >>>>> offer to save a text file giving a full report. The most likely >>>>> cases >>>>> are >>>>> that the photos were byte-for-byte duplicates of other photos >>>>> (Shotwell >>>>> won't import duplicates), that they are not photo files >>>>> (corrupted or >>>>> named >>>>> incorrectly), or that Shotwell doesn't support their data >>>>> format (GIF >>>>> is the >>>>> most prominent for example). -- Jim >>>>> >>>>> Hi Jim, I import and copy my photos from /home/grant/photodump/ >>>>> to >>>>> /home/grant/Pictures/. I have: # updatedb && locate >>>>> IMG_20130303_144420 >>>>> /home/grant/photodump/IMG_20130303_144420.jpg # "Shotwell Import >>>>> Log.txt" >>>>> says: /home/grant/photodump/IMG_20130303_144420.jpg duplicates >>>>> existing >>>>> media item /home/grant/photodump/IMG_20130303_144420.jpg Can >>>>> you help >>>>> me >>>>> reconcile this? - Grant >>>>> >>>>> I imported/copied a large number of photos into shotwell from a >>>>> folder >>>>> and I >>>>> was about to delete the folder but I noticed at least several >>>>> photos >>>>> that >>>>> did not import or copy. Why would some photos import and not >>>>> others? - >>>>> Grant >>>>> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From clanlaw at googlemail.com Tue May 7 20:53:07 2013 From: clanlaw at googlemail.com (Colin Law) Date: Tue, 7 May 2013 21:53:07 +0100 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> Message-ID: On 7 May 2013 21:43, Grant wrote: >> There's a shotwell option to rename to lowercase on import maybe it got >> renamed to lowercase? >> >> -Joe > > I tried this but still only one copy of the photo on my system: > > # updatedb && locate 144420 > /home/grant/photodump/IMG_20130303_144420.jpg Are you able to see the photo in Shotwell? If so what do you see if you right click and Show in File Manager? Colin From clanlaw at googlemail.com Tue May 7 20:57:57 2013 From: clanlaw at googlemail.com (Colin Law) Date: Tue, 7 May 2013 21:57:57 +0100 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> Message-ID: On 7 May 2013 21:53, Colin Law wrote: > On 7 May 2013 21:43, Grant wrote: >>> There's a shotwell option to rename to lowercase on import maybe it got >>> renamed to lowercase? >>> >>> -Joe >> >> I tried this but still only one copy of the photo on my system: >> >> # updatedb && locate 144420 >> /home/grant/photodump/IMG_20130303_144420.jpg > > Are you able to see the photo in Shotwell? If so what do you see if > you right click and Show in File Manager? If you cannot see it in Shotwell what happens if you drag that photo into Shotwell? Colin > > Colin From emailgrant at gmail.com Tue May 7 22:46:23 2013 From: emailgrant at gmail.com (Grant) Date: Tue, 7 May 2013 15:46:23 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <51896933.2529440a.54cf.ffffb2e3@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <51896933.2529440a.54cf.ffffb2e3@mx.google.com> Message-ID: > In Edit -> Preferences, what is your Library Directory set to? Library Location says Import photos to: Pictures. Which is /home/grant/Pictures. - Grant > There's a shotwell option to rename to lowercase on import maybe it got > renamed to lowercase? -Joe > > I tried this but still only one copy of the photo on my system: # updatedb > && locate 144420 /home/grant/photodump/IMG_20130303_144420.jpg # - Grant > > How are you importing the photos? Drag-and-drop or with File -> Import From > Folder? -- Jim On Mon, May 6, 2013 at 12:16 PM, Grant > wrote: > > It looks to me that you're attempting to import the same file (not a > duplicate, but the same file) a second time. In other words, the file you're > attempting to import is already in the library. -- Jim > > locate only finds the file in my target folder, not in my destination > folder: # updatedb && locate IMG_20130303_144420 > /home/grant/photodump/IMG_20130303_144420.jpg # But it refuses to import the > file with the log message indicating it has already been imported. Could > shotwell have renamed the file when it was copied to the destination folder? > I'm on 0.14.1. - Grant > > There's many reasons. At the end of an import, Shotwell should give you a > list explaining why photos were not imported. In Shotwell 0.14, it will > offer to save a text file giving a full report. The most likely cases are > that the photos were byte-for-byte duplicates of other photos (Shotwell > won't import duplicates), that they are not photo files (corrupted or named > incorrectly), or that Shotwell doesn't support their data format (GIF is the > most prominent for example). -- Jim Hi Jim, I import and copy my photos from > /home/grant/photodump/ to /home/grant/Pictures/. I have: # updatedb && > locate IMG_20130303_144420 /home/grant/photodump/IMG_20130303_144420.jpg # > "Shotwell Import Log.txt" says: > /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing media item > /home/grant/photodump/IMG_20130303_144420.jpg Can you help me reconcile > this? - Grant I imported/copied a large number of photos into shotwell from > a folder and I was about to delete the folder but I noticed at least several > photos that did not import or copy. Why would some photos import and not > others? - Grant From emailgrant at gmail.com Tue May 7 22:53:23 2013 From: emailgrant at gmail.com (Grant) Date: Tue, 7 May 2013 15:53:23 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> Message-ID: >>> There's a shotwell option to rename to lowercase on import maybe it got >>> renamed to lowercase? >>> >>> -Joe >> >> I tried this but still only one copy of the photo on my system: >> >> # updatedb && locate 144420 >> /home/grant/photodump/IMG_20130303_144420.jpg > > Are you able to see the photo in Shotwell? If so what do you see if > you right click and Show in File Manager? > > Colin I do see the photo in Shotwell. When I Show in File Manager, it appears in /home/grant/photodump/ which is the folder I import from. How can I ensure that all of the photos in /home/grant/photodump/ are copied to /home/grant/Pictures/? I thought I always chose the copy option as opposed to importing in place. How can I be sure it's OK to delete the contents of the photodump folder? - Grant From lucas at yorba.org Tue May 7 22:55:04 2013 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 07 May 2013 22:48:04 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <51896933.2529440a.54cf.ffffb2e3@mx.google.com> Message-ID: <51898651.62a4420a.1a6f.ffffe9b6@mx.google.com> Hi Grant, You can't see the photo in Shotwell, but Shotwell -- at least according to its own import log -- thinks that you've previously imported the same file. I'm curious if you at some point (perhaps accidentally) marked the photo as "Rejected?" If this is the case, you should be able to see the photo by pressing F8 to bring up the Search Filter bar and then choosing All+Rejected from the ratings filter popup. Lucas On Tue, May 7, 2013 at 3:46 PM, Grant wrote: >> In Edit -> Preferences, what is your Library Directory set to? >> > Library Location says Import photos to: Pictures. Which is > /home/grant/Pictures. > > - Grant > > >> There's a shotwell option to rename to lowercase on import maybe it >> got >> renamed to lowercase? -Joe >> >> I tried this but still only one copy of the photo on my system: # >> updatedb >> && locate 144420 /home/grant/photodump/IMG_20130303_144420.jpg # - >> Grant >> >> How are you importing the photos? Drag-and-drop or with File -> >> Import From >> Folder? -- Jim On Mon, May 6, 2013 at 12:16 PM, Grant >> >> wrote: >> >> It looks to me that you're attempting to import the same file (not a >> duplicate, but the same file) a second time. In other words, the >> file you're >> attempting to import is already in the library. -- Jim >> >> locate only finds the file in my target folder, not in my >> destination >> folder: # updatedb && locate IMG_20130303_144420 >> /home/grant/photodump/IMG_20130303_144420.jpg # But it refuses to >> import the >> file with the log message indicating it has already been imported. >> Could >> shotwell have renamed the file when it was copied to the >> destination folder? >> I'm on 0.14.1. - Grant >> >> There's many reasons. At the end of an import, Shotwell should give >> you a >> list explaining why photos were not imported. In Shotwell 0.14, it >> will >> offer to save a text file giving a full report. The most likely >> cases are >> that the photos were byte-for-byte duplicates of other photos >> (Shotwell >> won't import duplicates), that they are not photo files (corrupted >> or named >> incorrectly), or that Shotwell doesn't support their data format >> (GIF is the >> most prominent for example). -- Jim Hi Jim, I import and copy my >> photos from >> /home/grant/photodump/ to /home/grant/Pictures/. I have: # updatedb >> && >> locate IMG_20130303_144420 >> /home/grant/photodump/IMG_20130303_144420.jpg # >> "Shotwell Import Log.txt" says: >> /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing >> media item >> /home/grant/photodump/IMG_20130303_144420.jpg Can you help me >> reconcile >> this? - Grant I imported/copied a large number of photos into >> shotwell from >> a folder and I was about to delete the folder but I noticed at >> least several >> photos that did not import or copy. Why would some photos import >> and not >> others? - Grant >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Tue May 7 23:01:22 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 07 May 2013 22:54:22 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> Message-ID: <518987c9.84a2440a.23f1.ffffa461@mx.google.com> I think I see the problem, Grant. Shotwell is being conservative here. It will copy the photos to Pictures, but since it has the imported photo in its database (admittedly in a different directory) it aborts the import. We have had some requests for a feature that you're looking for, notably http://redmine.yorba.org/issues/5773 What I would do is this: 1. In Shotwell, Edit -> Preferences 2. Enable "Watch library directory for new files" Note that this will add all pictures and videos in Pictures to Shotwell. I don't know if you want this or not. 3. Quit Shotwell 4. Move the photos from photodump into Pictures manually (using Files or Nautilus) 5. Start Shotwell Shotwell will do a scan of your library directory (Pictures) as well as of all photos not in Pictures. When it detects the moved photos, it will update its database. Give this process a few minutes, it might take Shotwell a while to find all your photos depending on the size of your library. Does that help? -- Jim On Tue, May 7, 2013 at 3:53 PM, Grant wrote: >>>> There's a shotwell option to rename to lowercase on import maybe >>>> it got >>>> renamed to lowercase? >>>> >>>> -Joe >>>> >>> I tried this but still only one copy of the photo on my system: >>> >>> # updatedb && locate 144420 >>> /home/grant/photodump/IMG_20130303_144420.jpg >>> >> Are you able to see the photo in Shotwell? If so what do you see if >> you right click and Show in File Manager? >> >> Colin >> > I do see the photo in Shotwell. When I Show in File Manager, it > appears in /home/grant/photodump/ which is the folder I import from. > How can I ensure that all of the photos in /home/grant/photodump/ are > copied to /home/grant/Pictures/? I thought I always chose the copy > option as opposed to importing in place. How can I be sure it's OK to > delete the contents of the photodump folder? > > - Grant > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From emailgrant at gmail.com Wed May 8 00:21:53 2013 From: emailgrant at gmail.com (Grant) Date: Tue, 7 May 2013 17:21:53 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <518987c9.84a2440a.23f1.ffffa461@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> Message-ID: > I think I see the problem, Grant. > > Shotwell is being conservative here. It will copy the photos to Pictures, > but since it has the imported photo in its database (admittedly in a > different directory) it aborts the import. > > We have had some requests for a feature that you're looking for, notably > http://redmine.yorba.org/issues/5773 > > > What I would do is this: > > 1. In Shotwell, Edit -> Preferences > 2. Enable "Watch library directory for new files" > > Note that this will add all pictures and videos in Pictures to Shotwell. I > don't know if you want this or not. > > 3. Quit Shotwell > 4. Move the photos from photodump into Pictures manually (using Files or > Nautilus) > 5. Start Shotwell > > Shotwell will do a scan of your library directory (Pictures) as well as of > all photos not in Pictures. When it detects the moved photos, it will > update its database. Give this process a few minutes, it might take > Shotwell a while to find all your photos depending on the size of your > library. > > Does that help? I tried it but I'm not sure how that is different from just importing in place. What I like about the copy option (as opposed to importing in place) is that the photos are physically copied into a meaningful directory structure based on date instead of remaining jumbled together in the photodump folder. Maybe I should delete the shotwell database (how is that done?) and start over with the import and copy option? The problem is I will never know if it's safe to delete the contents of the photodump folder. I think a move option in addition to the copy option would be ideal because using it would mean nothing needs to be manually deleted from photodump. If the file doesn't exist in photodump after an import, it has been moved. If it does exist after an import, it has not been moved and something is wrong so don't delete it. - Grant > There's a shotwell option to rename to lowercase on import maybe it got > renamed to lowercase? -Joe > > I tried this but still only one copy of the photo on my system: # updatedb > && locate 144420 /home/grant/photodump/IMG_20130303_144420.jpg > > Are you able to see the photo in Shotwell? If so what do you see if you > right click and Show in File Manager? Colin > > I do see the photo in Shotwell. When I Show in File Manager, it appears in > /home/grant/photodump/ which is the folder I import from. How can I ensure > that all of the photos in /home/grant/photodump/ are copied to > /home/grant/Pictures/? I thought I always chose the copy option as opposed > to importing in place. How can I be sure it's OK to delete the contents of > the photodump folder? - Grant From emailgrant at gmail.com Wed May 8 00:24:09 2013 From: emailgrant at gmail.com (Grant) Date: Tue, 7 May 2013 17:24:09 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <51898651.62a4420a.1a6f.ffffe9b6@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <51896933.2529440a.54cf.ffffb2e3@mx.google.com> <51898651.62a4420a.1a6f.ffffe9b6@mx.google.com> Message-ID: > Hi Grant, > > You can't see the photo in Shotwell, but Shotwell -- at least according to > its own import log -- thinks that you've previously imported the same file. > I'm curious if you at some point (perhaps accidentally) marked the photo as > "Rejected?" If this is the case, you should be able to see the photo by > pressing F8 to bring up the Search Filter bar and then choosing All+Rejected > from the ratings filter popup. > > Lucas Hi Lucas, I actually can see the photo in shotwell so it appears it was imported in place somehow. I've gone into more depth in my response to Jim. - Grant > In Edit -> Preferences, what is your Library Directory set to? > > Library Location says Import photos to: Pictures. Which is > /home/grant/Pictures. - Grant > > There's a shotwell option to rename to lowercase on import maybe it got > renamed to lowercase? -Joe I tried this but still only one copy of the photo > on my system: # updatedb && locate 144420 > /home/grant/photodump/IMG_20130303_144420.jpg # - Grant How are you > importing the photos? Drag-and-drop or with File -> Import From Folder? -- > Jim On Mon, May 6, 2013 at 12:16 PM, Grant wrote: It > looks to me that you're attempting to import the same file (not a duplicate, > but the same file) a second time. In other words, the file you're attempting > to import is already in the library. -- Jim locate only finds the file in my > target folder, not in my destination folder: # updatedb && locate > IMG_20130303_144420 /home/grant/photodump/IMG_20130303_144420.jpg # But it > refuses to import the file with the log message indicating it has already > been imported. Could shotwell have renamed the file when it was copied to > the destination folder? I'm on 0.14.1. - Grant There's many reasons. At the > end of an import, Shotwell should give you a list explaining why photos were > not imported. In Shotwell 0.14, it will offer to save a text file giving a > full report. The most likely cases are that the photos were byte-for-byte > duplicates of other photos (Shotwell won't import duplicates), that they are > not photo files (corrupted or named incorrectly), or that Shotwell doesn't > support their data format (GIF is the most prominent for example). -- Jim Hi > Jim, I import and copy my photos from /home/grant/photodump/ to > /home/grant/Pictures/. I have: # updatedb && locate IMG_20130303_144420 > /home/grant/photodump/IMG_20130303_144420.jpg # "Shotwell Import Log.txt" > says: /home/grant/photodump/IMG_20130303_144420.jpg duplicates existing > media item /home/grant/photodump/IMG_20130303_144420.jpg Can you help me > reconcile this? - Grant I imported/copied a large number of photos into > shotwell from a folder and I was about to delete the folder but I noticed at > least several photos that did not import or copy. Why would some photos > import and not others? - Grant From jim at yorba.org Thu May 9 01:25:06 2013 From: jim at yorba.org (Jim Nelson) Date: Thu, 09 May 2013 01:18:06 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> Message-ID: <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> On Tue, May 7, 2013 at 5:21 PM, Grant wrote: > I tried it but I'm not sure how that is different from just importing > in place. What I like about the copy option (as opposed to importing > in place) is that the photos are physically copied into a meaningful > directory structure based on date instead of remaining jumbled > together in the photodump folder. > > Maybe I should delete the shotwell database (how is that done?) and > start over with the import and copy option? The problem is I will > never know if it's safe to delete the contents of the photodump > folder. I think a move option in addition to the copy option would be > ideal because using it would mean nothing needs to be manually deleted > from photodump. If the file doesn't exist in photodump after an > import, it has been moved. If it does exist after an import, it has > not been moved and something is wrong so don't delete it. > What I'm suggesting is essentially an in-place import, but because you're moving them manually, you can choose where the photos should go. If you did an in-place import from photodump, the photos would remain there. If you want Shotwell to copy in your photos and organize them in directories by name, that is also something we'd like to offer but don't have today. If you're comfortable, yes, you can delete your Shotwell database and start over. I would be careful about this, since you'll lose any changes you made to the photos (such as auto-enhance, tags, etc.). Some of those changes can be written out to the files (tags, for example), but not all of them. If you truly want to delete the database, these commands will do it (warning, they won't ask for confirmation): $ rm -rf ~/.local/share/shotwell $ rm -rf ~/.cache/shotwell You could also consider in Shotwell selecting Edit -> Select All, then Edit -> Remove From Library. Choose "Only Remove" to clear the library -- none of the files will be deleted or moved to the desktop trash. This will clear your library without those commands, which can be dangerous. I've ticketed moving photos during import: http://redmine.yorba.org/issues/6929 It's a good idea. -- Jim From mark.sheriff at online.fr Thu May 9 14:14:35 2013 From: mark.sheriff at online.fr (Mark Sheriff) Date: Thu, 09 May 2013 16:14:35 +0200 Subject: [Shotwell] Upgrade problems 12 to 14 ubuntu Message-ID: <1368108875.3248.15.camel@mark-eME644> Upgrade problems 12 to 14 ubuntu Shotwell was failing to display videos (mp4 and ASF), even though they had been imported, and placed in the correct folder. So I checked the Yorba site and discovered, my version was out of date. I entered the following 3 commands: $ sudo add-apt-repository ppa:yorba/ppa $ sudo apt-get update $ sudo apt-get install shotwell Note I didn't remove the earlier version, cos the Yorba site did not instruct me to do do so. Result: Clicking the shotwell icon does not launch the app. Typing shotwell, or./shotwell in terminal doesn't work. I ran $ sudo apt-get install shotwell again..... terminal reported: shotwell is already the newest version Tried launching from dash, but this doesn't work. Loaded software centre, and this informs me shotwell is installed, offering the option to remove it. tried inserting an SD card with pics, to get the 'load shotwell' command. Clicked the command but only got a lot of hard disk activity for a period. What is my best course of action? What, if any, changes should be made to the install instructions, to ensure this does not happen to future users? From mark.sheriff at online.fr Thu May 9 14:43:21 2013 From: mark.sheriff at online.fr (Mark Sheriff) Date: Thu, 09 May 2013 16:43:21 +0200 Subject: [Shotwell] Upgrade problems 12 to 14 ubuntu In-Reply-To: <1368108875.3248.15.camel@mark-eME644> References: <1368108875.3248.15.camel@mark-eME644> Message-ID: <1368110601.5315.1.camel@mark-eME644> I since decided to remove shotwell thru software center. I then re-installed, but no joy. Typing shotwell in terminal still produces this: shotwell: error while loading shared libraries: libgexiv2.so.2: cannot open shared object file: No such file or directory On Thu, 2013-05-09 at 16:14 +0200, Mark Sheriff wrote: > Upgrade problems 12 to 14 ubuntu > > Shotwell was failing to display videos (mp4 and ASF), even though they > had been imported, and placed in the correct folder. > So I checked the Yorba site and discovered, my version was out of date. > > I entered the following 3 commands: > > $ sudo add-apt-repository ppa:yorba/ppa > $ sudo apt-get update > $ sudo apt-get install shotwell > > Note I didn't remove the earlier version, cos the Yorba site did not > instruct me to do do so. > > Result: > > Clicking the shotwell icon does not launch the app. > Typing shotwell, or./shotwell in terminal doesn't work. > > I ran $ sudo apt-get install shotwell again..... terminal reported: > shotwell is already the newest version > > Tried launching from dash, but this doesn't work. > Loaded software centre, and this informs me shotwell is installed, > offering the option to remove it. > > tried inserting an SD card with pics, to get the 'load shotwell' > command. > Clicked the command but only got a lot of hard disk activity for a > period. > > What is my best course of action? > > What, if any, changes should be made to the install instructions, to > ensure this does not happen to future users? > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From clinton at yorba.org Thu May 9 19:48:54 2013 From: clinton at yorba.org (Clint Rogers) Date: Thu, 9 May 2013 12:48:54 -0700 Subject: [Shotwell] Upgrade problems 12 to 14 ubuntu In-Reply-To: <1368110601.5315.1.camel@mark-eME644> References: <1368108875.3248.15.camel@mark-eME644> <1368110601.5315.1.camel@mark-eME644> Message-ID: Good afternoon Mark, It sounds like you may have been bitten by http://redmine.yorba.org/issues/6618, and we apologize for this. Fortunately, there's a workaround: 1) Add the following PPA to your system: https://launchpad.net/~yorba/+archive/ppa (this page contains instructions on how to do this if you're unfamiliar) 2) Remove, then reinstall Shotwell (this should grab the PPA version, which should, in turn, pull in the required version of libgexiv2) As for the video problem, when you say 'failing to display', do you mean that Shotwell couldn't create thumbnails for them, or that they wouldn't play when double-clicked? Thumbnails not working may indicate that your system doesn't have GStreamer plugins for those formats - do you get thumbnails for the affected video files in your file manager? If you're simply not seeing thumbnails, it's likely a missing codec, and installing something like gst-plugins-bad1.0 would help. If videos won't play when double-clicked, though, it may be that Shotwell is having trouble launching an external media player. When you try to open one of the affected videos from the file manager, what happens? Please let us know. Cheers, -c On 9 May 2013 07:43, Mark Sheriff wrote: > I since decided to remove shotwell thru software center. > I then re-installed, but no joy. > Typing shotwell in terminal still produces this: shotwell: error while > loading shared libraries: libgexiv2.so.2: cannot open shared object > file: No such file or directory > > > > On Thu, 2013-05-09 at 16:14 +0200, Mark Sheriff wrote: > > Upgrade problems 12 to 14 ubuntu > > > > Shotwell was failing to display videos (mp4 and ASF), even though they > > had been imported, and placed in the correct folder. > > So I checked the Yorba site and discovered, my version was out of date. > > > > I entered the following 3 commands: > > > > $ sudo add-apt-repository ppa:yorba/ppa > > $ sudo apt-get update > > $ sudo apt-get install shotwell > > > > Note I didn't remove the earlier version, cos the Yorba site did not > > instruct me to do do so. > > > > Result: > > > > Clicking the shotwell icon does not launch the app. > > Typing shotwell, or./shotwell in terminal doesn't work. > > > > I ran $ sudo apt-get install shotwell again..... terminal reported: > > shotwell is already the newest version > > > > Tried launching from dash, but this doesn't work. > > Loaded software centre, and this informs me shotwell is installed, > > offering the option to remove it. > > > > tried inserting an SD card with pics, to get the 'load shotwell' > > command. > > Clicked the command but only got a lot of hard disk activity for a > > period. > > > > What is my best course of action? > > > > What, if any, changes should be made to the install instructions, to > > ensure this does not happen to future users? > > > > > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. From emailgrant at gmail.com Fri May 10 02:34:07 2013 From: emailgrant at gmail.com (Grant) Date: Thu, 9 May 2013 19:34:07 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> Message-ID: > I tried it but I'm not sure how that is different from just importing in > place. What I like about the copy option (as opposed to importing in place) > is that the photos are physically copied into a meaningful directory > structure based on date instead of remaining jumbled together in the > photodump folder. Maybe I should delete the shotwell database (how is that > done?) and start over with the import and copy option? The problem is I will > never know if it's safe to delete the contents of the photodump folder. I > think a move option in addition to the copy option would be ideal because > using it would mean nothing needs to be manually deleted from photodump. If > the file doesn't exist in photodump after an import, it has been moved. If > it does exist after an import, it has not been moved and something is wrong > so don't delete it. > > > What I'm suggesting is essentially an in-place import, but because you're > moving them manually, you can choose where the photos should go. If you did > an in-place import from photodump, the photos would remain there. > > If you want Shotwell to copy in your photos and organize them in directories > by name, that is also something we'd like to offer but don't have today. If Not by name but by date. Shotwell does this currently right? The problem with importing in place is it doesn't have this functionality. > you're comfortable, yes, you can delete your Shotwell database and start > over. I would be careful about this, since you'll lose any changes you made > to the photos (such as auto-enhance, tags, etc.). Some of those changes can > be written out to the files (tags, for example), but not all of them. > > If you truly want to delete the database, these commands will do it > (warning, they won't ask for confirmation): > > $ rm -rf ~/.local/share/shotwell > $ rm -rf ~/.cache/shotwell That works great, thank you. > I've ticketed moving photos during import: > http://redmine.yorba.org/issues/6929 It's a good idea. Thanks that would be a really slick feature. - Grant From emailgrant at gmail.com Fri May 10 06:45:16 2013 From: emailgrant at gmail.com (Grant) Date: Thu, 9 May 2013 23:45:16 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> Message-ID: > I've ticketed moving photos during import: > http://redmine.yorba.org/issues/6929 It's a good idea. I found a workaround for the meantime. After importing+copying a batch of photos/videos, I check the total number of items in shotwell's library and import the same folder where shotwell stores all of the items. If it doesn't say that it skipped the exact number of items that are in its library, something is wrong and I shouldn't delete the original location of the items. - Grant From mark.sheriff at online.fr Fri May 10 09:04:59 2013 From: mark.sheriff at online.fr (Mark Sheriff) Date: Fri, 10 May 2013 11:04:59 +0200 Subject: [Shotwell] Upgrade problems 12 to 14 ubuntu In-Reply-To: References: <1368108875.3248.15.camel@mark-eME644> <1368110601.5315.1.camel@mark-eME644> Message-ID: <1368176699.5315.9.camel@mark-eME644> Thanks for the information Clint v14 is now working, and and at far greater speed than before. I'll post the video thumbnail probs under such a title, for all to see. Thanks again Mark On Thu, 2013-05-09 at 12:48 -0700, Clint Rogers wrote: > Good afternoon Mark, > > > It sounds like you may have been bitten by > http://redmine.yorba.org/issues/6618, and we apologize for this. > Fortunately, there's a workaround: > 1) Add the following PPA to your system: > https://launchpad.net/~yorba/+archive/ppa (this page contains > instructions on how to do this if you're unfamiliar) > > 2) Remove, then reinstall Shotwell (this should grab the PPA version, > which should, in turn, pull in the required version of libgexiv2) > > > As for the video problem, when you say 'failing to display', do you > mean that Shotwell couldn't create thumbnails for them, or that they > wouldn't play when double-clicked? > > Thumbnails not working may indicate that your system doesn't have > GStreamer plugins for those formats - do you get thumbnails for the > affected video files in your file manager? If you're simply not seeing > thumbnails, it's likely a missing codec, and installing something like > gst-plugins-bad1.0 would help. > > If videos won't play when double-clicked, though, it may be that > Shotwell is having trouble launching an external media player. When > you try to open one of the affected videos from the file manager, what > happens? > > > Please let us know. > > Cheers, > -c > > > > On 9 May 2013 07:43, Mark Sheriff wrote: > I since decided to remove shotwell thru software center. > I then re-installed, but no joy. > Typing shotwell in terminal still produces this: shotwell: > error while > loading shared libraries: libgexiv2.so.2: cannot open shared > object > file: No such file or directory > > > > On Thu, 2013-05-09 at 16:14 +0200, Mark Sheriff wrote: > > Upgrade problems 12 to 14 ubuntu > > > > Shotwell was failing to display videos (mp4 and ASF), even > though they > > had been imported, and placed in the correct folder. > > So I checked the Yorba site and discovered, my version was > out of date. > > > > I entered the following 3 commands: > > > > $ sudo add-apt-repository ppa:yorba/ppa > > $ sudo apt-get update > > $ sudo apt-get install shotwell > > > > Note I didn't remove the earlier version, cos the Yorba site > did not > > instruct me to do do so. > > > > Result: > > > > Clicking the shotwell icon does not launch the app. > > Typing shotwell, or./shotwell in terminal doesn't work. > > > > I ran $ sudo apt-get install shotwell again..... terminal > reported: > > shotwell is already the newest version > > > > Tried launching from dash, but this doesn't work. > > Loaded software centre, and this informs me shotwell is > installed, > > offering the option to remove it. > > > > tried inserting an SD card with pics, to get the 'load > shotwell' > > command. > > Clicked the command but only got a lot of hard disk activity > for a > > period. > > > > What is my best course of action? > > > > What, if any, changes should be made to the install > instructions, to > > ensure this does not happen to future users? > > > > > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > -- > --------------------------- > "I don't know what (b? - 4ac) equals, and I don't care," Tom said > indiscriminately. > > > > > > From mark.sheriff at online.fr Fri May 10 14:24:09 2013 From: mark.sheriff at online.fr (Mark Sheriff) Date: Fri, 10 May 2013 16:24:09 +0200 Subject: [Shotwell] SHOTWELL v14 - Video thumbnail display & Date issues In-Reply-To: References: <1368108875.3248.15.camel@mark-eME644> <1368110601.5315.1.camel@mark-eME644> Message-ID: <1368195849.5315.61.camel@mark-eME644> VIDEO THUMBNAIL DISPLAY/DATE - ISSUES *************************** Nav Tree 'Folders' ***** The 169 video files have been allocated as follows: 59 - 1970 01/01 I cannot say how all these video files of all different dates ended up in a single dir dated 1970, but Nautilus also reports the same. They are all videos that present 'no date & time data', other than the file creation time. The remaining 110 videos appear to be stored correctly. It would appear all thumbnails are present, and the files do run when clicked. Nav Tree 'Events' **** The problem appears to only effect the Nav Tree 'Events', stemming(?) from video files that present 'no date & time data', other than the file creation time. The 169 video files have been allocated as follows: 109 - No Event 3 - 1947 (but correct month and day) ***** It would appear that if the video files contain additional date and time info, they are accurately logged. If only the 'file date & time' is available, they may not be logged correctly. ***** I wonder.... If I created a new library, and import/copied all the photo's and videos to a new destination....... would shotwell build a directory structure based upon the file date (if other data not available.) However, I can envisage problems with edited pics. I can see that it is not easy. Using Nav Tree Folders I could manually transfer vids to their correctly dated folders, and that would provide a working system. I guess I'd then just NOT use Nav Tree Events as it has too many errors with vids and pics (also 110 pics in No Events). Mark On Thu, 2013-05-09 at 12:48 -0700, Clint Rogers wrote: > Good afternoon Mark, > > > It sounds like you may have been bitten by > http://redmine.yorba.org/issues/6618, and we apologize for this. > Fortunately, there's a workaround: > 1) Add the following PPA to your system: > https://launchpad.net/~yorba/+archive/ppa (this page contains > instructions on how to do this if you're unfamiliar) > > 2) Remove, then reinstall Shotwell (this should grab the PPA version, > which should, in turn, pull in the required version of libgexiv2) > > > As for the video problem, when you say 'failing to display', do you > mean that Shotwell couldn't create thumbnails for them, or that they > wouldn't play when double-clicked? > > Thumbnails not working may indicate that your system doesn't have > GStreamer plugins for those formats - do you get thumbnails for the > affected video files in your file manager? If you're simply not seeing > thumbnails, it's likely a missing codec, and installing something like > gst-plugins-bad1.0 would help. > > If videos won't play when double-clicked, though, it may be that > Shotwell is having trouble launching an external media player. When > you try to open one of the affected videos from the file manager, what > happens? > > > Please let us know. > > Cheers, > -c > > > > On 9 May 2013 07:43, Mark Sheriff wrote: > I since decided to remove shotwell thru software center. > I then re-installed, but no joy. > Typing shotwell in terminal still produces this: shotwell: > error while > loading shared libraries: libgexiv2.so.2: cannot open shared > object > file: No such file or directory > > > > On Thu, 2013-05-09 at 16:14 +0200, Mark Sheriff wrote: > > Upgrade problems 12 to 14 ubuntu > > > > Shotwell was failing to display videos (mp4 and ASF), even > though they > > had been imported, and placed in the correct folder. > > So I checked the Yorba site and discovered, my version was > out of date. > > > > I entered the following 3 commands: > > > > $ sudo add-apt-repository ppa:yorba/ppa > > $ sudo apt-get update > > $ sudo apt-get install shotwell > > > > Note I didn't remove the earlier version, cos the Yorba site > did not > > instruct me to do do so. > > > > Result: > > > > Clicking the shotwell icon does not launch the app. > > Typing shotwell, or./shotwell in terminal doesn't work. > > > > I ran $ sudo apt-get install shotwell again..... terminal > reported: > > shotwell is already the newest version > > > > Tried launching from dash, but this doesn't work. > > Loaded software centre, and this informs me shotwell is > installed, > > offering the option to remove it. > > > > tried inserting an SD card with pics, to get the 'load > shotwell' > > command. > > Clicked the command but only got a lot of hard disk activity > for a > > period. > > > > What is my best course of action? > > > > What, if any, changes should be made to the install > instructions, to > > ensure this does not happen to future users? > > > > > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > -- > --------------------------- > "I don't know what (b? - 4ac) equals, and I don't care," Tom said > indiscriminately. > > > > > > From nigeldodd at gmail.com Fri May 10 16:44:20 2013 From: nigeldodd at gmail.com (Nigel Dodd) Date: Fri, 10 May 2013 17:44:20 +0100 Subject: [Shotwell] can shotwell be made to ignore raw files? Message-ID: Raw files are like negatives. I only "print" (to jpg) a fraction of all the raw images I shoot. It is absurd to suggest that Shotwell is qualified to print those raw files since it has no idea of the preprocessing I want. This has been asked before, but can Shotwell be made to ignore raw files? The answers before don't seem to suggest it can without external help. I hope I am wrong. From jim at yorba.org Fri May 10 17:08:43 2013 From: jim at yorba.org (Jim Nelson) Date: Fri, 10 May 2013 17:01:43 -0007 Subject: [Shotwell] can shotwell be made to ignore raw files? In-Reply-To: References: Message-ID: <518d2998.0794420a.79ec.1bc3@mx.google.com> Shot answer: Shotwell cannot ignore RAW files, although there's a long-standing bug to implement that: http://redmine.yorba.org/issues/2623 Long answer: Shotwell doesn't presume to know how to develop ("print") your RAW files. It has two developer options ("Shotwell", which uses LibRaw to develop the files, and "Camera", which uses the JPEG file the camera embeds in the RAW file). If you want to develop your own RAW files, Shotwell can launch a RAW image processing app (like RawTherapee) and let you tweak it. Understand, Shotwell can't display a RAW file without using some kind of JPEG file; processing a RAW file in real time is incredibly slow on modern processors. Our recommendation is to use Camera developer to organize your RAW photos, then use a RAW image processor to fine-tune the ones you want to keep and share. -- Jim On Fri, May 10, 2013 at 9:44 AM, Nigel Dodd wrote: > Raw files are like negatives. I only "print" (to jpg) a fraction of > all the > raw images I shoot. It is absurd to suggest that Shotwell is > qualified to > print those raw files since it has no idea of the preprocessing I > want. > > This has been asked before, but can Shotwell be made to ignore raw > files? > > The answers before don't seem to suggest it can without external help. > > I hope I am wrong. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Fri May 10 18:36:05 2013 From: jim at yorba.org (Jim Nelson) Date: Fri, 10 May 2013 18:29:05 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> Message-ID: <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> On Thu, May 9, 2013 at 7:34 PM, Grant wrote: >> >> > Not by name but by date. Shotwell does this currently right? The > problem with importing in place is it doesn't have this functionality. > Yes, by date, that's what I meant. Glad to hear you were able to word around the problem in the meantime. -- Jim From emailgrant at gmail.com Fri May 10 19:31:23 2013 From: emailgrant at gmail.com (Grant) Date: Fri, 10 May 2013 12:31:23 -0700 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> Message-ID: > Not by name but by date. Shotwell does this currently right? The problem > with importing in place is it doesn't have this functionality. > > > Yes, by date, that's what I meant. I'm a little confused. You said: "If you want Shotwell to copy in your photos and organize them in directories by name, that is also something we'd like to offer but don't have today." But since you meant date instead of name, did you mean to say Shotwell doesn't have the ability to organize items in directories by date? It does seem to do exactly that here. - Grant From jim at yorba.org Fri May 10 21:09:07 2013 From: jim at yorba.org (Jim Nelson) Date: Fri, 10 May 2013 21:02:07 -0007 Subject: [Shotwell] Some photos not importing/copying? In-Reply-To: References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> Message-ID: <518d61f1.4f79420a.6e88.3f7b@mx.google.com> I meant Shotwell can't reorganize your files after they've been imported. When you're importing and copying files (not in-place), Shotwell will organize files into directories by the photos' dates. See Edit -> Preferences for different ways to organize by date when importing. -- Jim On Fri, May 10, 2013 at 12:31 PM, Grant wrote: >> Not by name but by date. Shotwell does this currently right? The >> problem >> with importing in place is it doesn't have this functionality. >> >> >> Yes, by date, that's what I meant. >> > I'm a little confused. You said: > > "If you want Shotwell to copy in your photos and organize them in > directories by name, that is also something we'd like to offer but > don't have today." > > But since you meant date instead of name, did you mean to say Shotwell > doesn't have the ability to organize items in directories by date? It > does seem to do exactly that here. > > - Grant > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From hendry.michael at gmail.com Sat May 11 09:14:43 2013 From: hendry.michael at gmail.com (Michael Hendry) Date: Sat, 11 May 2013 10:14:43 +0100 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <518d61f1.4f79420a.6e88.3f7b@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> Message-ID: <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> Earlier this year I retired my elderly Dell PC running Ubuntu 12.04 in favour of a new iMac 27". Virtually every application I was using on the Dell can be replaced with a Mac-compiled version, but I'm still running Shotwell in a virtual Ubuntu machine, storing all the images in a shared directory on the Mac. I've found that I've got a number of JPG versions of NEF files I'd previously uploaded to the Ubuntu machine, and the migrated to the Mac, for example: DSC_8937.NEF is accompanied by DSC_8937_NEF_embedded.jpg DSC_8937_NEF_shotwell_1.jpg and DSC_8937_NEF_shotwell.jpg I'm currently using Shotwell 0.12.3 with Ubuntu 12.04 in a Parallels VM. Is it safe to delete any or all of these Shotwell-generated JPGs? Will Shotwell generate a new JPG version if all that's left in a directory is the raw NEF file? Or does it only generate this on the initial import? I don't _need_ the extra space at the moment, but I'd like to dispose of an unnecessary overhead and reduce back-up requirements if I can. Thanks in advance, Michael From papa.filter at googlemail.com Sat May 11 10:47:30 2013 From: papa.filter at googlemail.com (R S) Date: Sat, 11 May 2013 12:47:30 +0200 Subject: [Shotwell] Fuji .RAF and Canon .CR2 different speed and thumbnail creation Message-ID: Hi, I am new to shotwell , I like the program for its clear structure and obvious workflow. Thanks for it ! But there are some , for my point of view strange behaviors. I have two cameras, a canon 40D and a Fuji X-E1. When I import canon raws - shotwell is set to raw developer in the preferences - everything is fast and correctly imported. But if there are no corresponding jpegs -developed by the camera- shotwell is creating them and writes them into the folder. I would prefer not to have these extra files in my folder , because I want to to create my own jepgs later with my favorite raw converter. It would be enough to show little thumbnails - may be stored in the database - and just read the embedded jpegs if I click on the thumb to see a fullscreen version of the raw. Now to the Fuji's. When I import in the same way like above, - jpegs already created by the camera , only a view thumbs are created , the others are just white rectangles.The whole import takes a really long time and the CPU (intel I5)is used up to 90 %. When I click on them (thumbs and white rectangles ) they are displayed ok in fullscreen mode. But the only chance to get a thumb instead a white area, I have to select these white thumbs and switch to raw developer = shotwell , then wait a long time (up to hours for a few hundred pics) and the switch back raw developer = camera , do get the thumbs. Thanx for reading, papa -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From mark.sheriff at online.fr Sat May 11 16:56:08 2013 From: mark.sheriff at online.fr (Mark Sheriff) Date: Sat, 11 May 2013 18:56:08 +0200 Subject: [Shotwell] SHOTWELL v14 - Video thumbnail display & Date issues In-Reply-To: <1368195849.5315.61.camel@mark-eME644> References: <1368108875.3248.15.camel@mark-eME644> <1368110601.5315.1.camel@mark-eME644> <1368195849.5315.61.camel@mark-eME644> Message-ID: <1368291368.5315.92.camel@mark-eME644> In order to rectify the problem of files being stored in 'no events', and also being 'lumped together in 1970', I decided to remove all the files - photos and vids from the library....... and then rebuild the library importing and copying the files to a new directory. This was a big mistake. I now have 73 videos in the new 1970 folder (up from 59) AND No thumbnails at all. I now have 91 photos, and 131 videos, in the new 'No event' folder (down from 110 pics, and up from 109 videos) The 1947 'Events' folder has thankfully gone. All the files in the 1970 folder are video.avi files It would appear that there is now less photo/video info available..... only the name is displayed. The fact that the file storage has worsened is less of a problem than the loss of the thumbnails, as we can now no longer choose to play a video on the basis of its contents. Q 1. Is there any way to force shotwell to read the file creation date, in order for it to build the correct directories and events? Q 2. How can I get my thumbnails back? Clearly I should never have tried to rebuild the library...... oh the value of hindsight. Mark On Fri, 2013-05-10 at 16:24 +0200, Mark Sheriff wrote: > VIDEO THUMBNAIL DISPLAY/DATE - ISSUES > *************************** > > Nav Tree 'Folders' > ***** > > The 169 video files have been allocated as follows: > 59 - 1970 01/01 > > I cannot say how all these video files of all different dates ended up > in a single dir dated 1970, but Nautilus also reports the same. > > They are all videos that present 'no date & time data', other than the > file creation time. > > The remaining 110 videos appear to be stored correctly. > > It would appear all thumbnails are present, and the files do run when > clicked. > > > Nav Tree 'Events' > **** > The problem appears to only effect the Nav Tree 'Events', stemming(?) > from video files that present 'no date & time data', other than the file > creation time. > The 169 video files have been allocated as follows: > > 109 - No Event > 3 - 1947 (but correct month and day) > > ***** > It would appear that if the video files contain additional date and time > info, they are accurately logged. > If only the 'file date & time' is available, they may not be logged > correctly. > > ***** > I wonder.... If I created a new library, and import/copied all the > photo's and videos to a new destination....... would shotwell build a > directory structure based upon the file date (if other data not > available.) > > However, I can envisage problems with edited pics. > I can see that it is not easy. > > > Using Nav Tree Folders I could manually transfer vids to their correctly > dated folders, and that would provide a working system. > > I guess I'd then just NOT use Nav Tree Events as it has too many errors > with vids and pics (also 110 pics in No Events). > > Mark > > > > > > > > On Thu, 2013-05-09 at 12:48 -0700, Clint Rogers wrote: > > Good afternoon Mark, > > > > > > It sounds like you may have been bitten by > > http://redmine.yorba.org/issues/6618, and we apologize for this. > > Fortunately, there's a workaround: > > 1) Add the following PPA to your system: > > https://launchpad.net/~yorba/+archive/ppa (this page contains > > instructions on how to do this if you're unfamiliar) > > > > 2) Remove, then reinstall Shotwell (this should grab the PPA version, > > which should, in turn, pull in the required version of libgexiv2) > > > > > > As for the video problem, when you say 'failing to display', do you > > mean that Shotwell couldn't create thumbnails for them, or that they > > wouldn't play when double-clicked? > > > > Thumbnails not working may indicate that your system doesn't have > > GStreamer plugins for those formats - do you get thumbnails for the > > affected video files in your file manager? If you're simply not seeing > > thumbnails, it's likely a missing codec, and installing something like > > gst-plugins-bad1.0 would help. > > > > If videos won't play when double-clicked, though, it may be that > > Shotwell is having trouble launching an external media player. When > > you try to open one of the affected videos from the file manager, what > > happens? > > > > > > Please let us know. > > > > Cheers, > > -c > > > > > > > > On 9 May 2013 07:43, Mark Sheriff wrote: > > I since decided to remove shotwell thru software center. > > I then re-installed, but no joy. > > Typing shotwell in terminal still produces this: shotwell: > > error while > > loading shared libraries: libgexiv2.so.2: cannot open shared > > object > > file: No such file or directory > > > > > > > > On Thu, 2013-05-09 at 16:14 +0200, Mark Sheriff wrote: > > > Upgrade problems 12 to 14 ubuntu > > > > > > Shotwell was failing to display videos (mp4 and ASF), even > > though they > > > had been imported, and placed in the correct folder. > > > So I checked the Yorba site and discovered, my version was > > out of date. > > > > > > I entered the following 3 commands: > > > > > > $ sudo add-apt-repository ppa:yorba/ppa > > > $ sudo apt-get update > > > $ sudo apt-get install shotwell > > > > > > Note I didn't remove the earlier version, cos the Yorba site > > did not > > > instruct me to do do so. > > > > > > Result: > > > > > > Clicking the shotwell icon does not launch the app. > > > Typing shotwell, or./shotwell in terminal doesn't work. > > > > > > I ran $ sudo apt-get install shotwell again..... terminal > > reported: > > > shotwell is already the newest version > > > > > > Tried launching from dash, but this doesn't work. > > > Loaded software centre, and this informs me shotwell is > > installed, > > > offering the option to remove it. > > > > > > tried inserting an SD card with pics, to get the 'load > > shotwell' > > > command. > > > Clicked the command but only got a lot of hard disk activity > > for a > > > period. > > > > > > What is my best course of action? > > > > > > What, if any, changes should be made to the install > > instructions, to > > > ensure this does not happen to future users? > > > > > > > > > > > > _______________________________________________ > > > Shotwell mailing list > > > Shotwell at lists.yorba.org > > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > > > > > > -- > > --------------------------- > > "I don't know what (b? - 4ac) equals, and I don't care," Tom said > > indiscriminately. > > > > > > > > > > > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From jim at yorba.org Mon May 13 17:53:47 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 13 May 2013 17:46:47 -0007 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> Message-ID: <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> Those extra files are generated by Shotwell because decoding the .NEF file (or any RAW file) takes a lot of CPU power and time. Also, there's two ways Shotwell can "develop" a RAW file: by decoding the file or using one of its internal JPEG files. Generally the internal JPEG file looks better because the camera has tweaked it using various parameters (white point, exposure, etc.) If you delete those files, Shotwell will regenerate them when you next view that file in Shotwell. Note that the latest version of Shotwell (0.14) will not generate so many of them; it's an old bug that caused all those different versions to appear. -- Jim On Sat, May 11, 2013 at 2:14 AM, Michael Hendry wrote: > Earlier this year I retired my elderly Dell PC running Ubuntu 12.04 > in favour of a new iMac 27". > > Virtually every application I was using on the Dell can be replaced > with a Mac-compiled version, but I'm still running Shotwell in a > virtual Ubuntu machine, storing all the images in a shared directory > on the Mac. > > I've found that I've got a number of JPG versions of NEF files I'd > previously uploaded to the Ubuntu machine, and the migrated to the > Mac, for example: > > DSC_8937.NEF is accompanied by > DSC_8937_NEF_embedded.jpg > DSC_8937_NEF_shotwell_1.jpg and > DSC_8937_NEF_shotwell.jpg > > I'm currently using Shotwell 0.12.3 with Ubuntu 12.04 in a Parallels > VM. > > Is it safe to delete any or all of these Shotwell-generated JPGs? > > Will Shotwell generate a new JPG version if all that's left in a > directory is the raw NEF file? Or does it only generate this on the > initial import? > > I don't _need_ the extra space at the moment, but I'd like to dispose > of an unnecessary overhead and reduce back-up requirements if I can. > > Thanks in advance, > > Michael > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From hendry.michael at gmail.com Mon May 13 18:51:32 2013 From: hendry.michael at gmail.com (Michael Hendry) Date: Mon, 13 May 2013 19:51:32 +0100 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> Message-ID: <031B228D-E577-4124-82BD-BA1E1F4C87A1@gmail.com> On 13 May 2013, at 18:53, Jim Nelson wrote: > Those extra files are generated by Shotwell because decoding the .NEF file (or any RAW file) takes a lot of CPU power and time. Also, there's two ways Shotwell can "develop" a RAW file: by decoding the file or using one of its internal JPEG files. Generally the internal JPEG file looks better because the camera has tweaked it using various parameters (white point, exposure, etc.) > > If you delete those files, Shotwell will regenerate them when you next view that file in Shotwell. Note that the latest version of Shotwell (0.14) will not generate so many of them; it's an old bug that caused all those different versions to appear. > > -- Jim > Thanks, Jim. I tried deleting the three JPG files accompanying DSC_8937.NEF, and the result was that DSC_8937.NEF became a "Missing File", according to Shotwell, and it disappeared from its event. After half a minute or so, it appeared to move from Missing FIle to its event again, but double-clicking on it in its event window (to view it) resulting in its going back into the "Missing FIle" slot. I tried dragging and dropping the file from its folder in the file system into Shotwell, and opted to leave it in place. The image duly reappeared in the relevant event, but no JPG file has been generated, and every time I double-click on it, it bounces back into the "Missing File" box. At no time since I deleted the JPG files has a new one been generated in the relevant directory. This is obviously not going to be as easy as I thought! Could my difficulty have something to do with the fact that the images I'm dealing with were shot entirely in RAW mode (i.e. not RAW+JPG) on my Nikon D70? Michael > On Sat, May 11, 2013 at 2:14 AM, Michael Hendry wrote: >> Earlier this year I retired my elderly Dell PC running Ubuntu 12.04 in favour of a new iMac 27". >> >> Virtually every application I was using on the Dell can be replaced with a Mac-compiled version, but I'm still running Shotwell in a virtual Ubuntu machine, storing all the images in a shared directory on the Mac. >> >> I've found that I've got a number of JPG versions of NEF files I'd previously uploaded to the Ubuntu machine, and the migrated to the Mac, for example: >> >> DSC_8937.NEF is accompanied by >> DSC_8937_NEF_embedded.jpg >> DSC_8937_NEF_shotwell_1.jpg and >> DSC_8937_NEF_shotwell.jpg >> >> I'm currently using Shotwell 0.12.3 with Ubuntu 12.04 in a Parallels VM. >> >> Is it safe to delete any or all of these Shotwell-generated JPGs? >> >> Will Shotwell generate a new JPG version if all that's left in a directory is the raw NEF file? Or does it only generate this on the initial import? >> >> I don't _need_ the extra space at the moment, but I'd like to dispose of an unnecessary overhead and reduce back-up requirements if I can. >> >> Thanks in advance, >> >> Michael >> >> >> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From jim at yorba.org Mon May 13 19:29:56 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 13 May 2013 19:22:56 -0007 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <031B228D-E577-4124-82BD-BA1E1F4C87A1@gmail.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> <031B228D-E577-4124-82BD-BA1E1F4C87A1@gmail.com> Message-ID: <51913f37.e7e1440a.5476.1565@mx.google.com> Ah -- something I didn't notice earlier: you're using an old version of Shotwell. The latest version (0.14.1) fixes numerous problems with RAW support, including this issue. I highly recommend upgrading from Yorba's PPA: https://launchpad.net/~yorba/+archive/ppa -- Jim On Mon, May 13, 2013 at 11:51 AM, Michael Hendry wrote: > > On 13 May 2013, at 18:53, Jim Nelson wrote: > >> Those extra files are generated by Shotwell because decoding the >> .NEF file (or any RAW file) takes a lot of CPU power and time. >> Also, there's two ways Shotwell can "develop" a RAW file: by >> decoding the file or using one of its internal JPEG files. >> Generally the internal JPEG file looks better because the camera has >> tweaked it using various parameters (white point, exposure, etc.) >> >> If you delete those files, Shotwell will regenerate them when you >> next view that file in Shotwell. Note that the latest version of >> Shotwell (0.14) will not generate so many of them; it's an old bug >> that caused all those different versions to appear. >> >> -- Jim >> >> > > Thanks, Jim. > > I tried deleting the three JPG files accompanying DSC_8937.NEF, and > the result was that DSC_8937.NEF became a "Missing File", according > to Shotwell, and it disappeared from its event. > > After half a minute or so, it appeared to move from Missing FIle to > its event again, but double-clicking on it in its event window (to > view it) resulting in its going back into the "Missing FIle" slot. > > I tried dragging and dropping the file from its folder in the file > system into Shotwell, and opted to leave it in place. The image duly > reappeared in the relevant event, but no JPG file has been generated, > and every time I double-click on it, it bounces back into the > "Missing File" box. > > At no time since I deleted the JPG files has a new one been generated > in the relevant directory. > > This is obviously not going to be as easy as I thought! > > Could my difficulty have something to do with the fact that the > images I'm dealing with were shot entirely in RAW mode (i.e. not > RAW+JPG) on my Nikon D70? > > Michael > > >> On Sat, May 11, 2013 at 2:14 AM, Michael Hendry >> wrote: >>> Earlier this year I retired my elderly Dell PC running Ubuntu 12.04 >>> in favour of a new iMac 27". >>> >>> Virtually every application I was using on the Dell can be replaced >>> with a Mac-compiled version, but I'm still running Shotwell in a >>> virtual Ubuntu machine, storing all the images in a shared >>> directory on the Mac. >>> >>> I've found that I've got a number of JPG versions of NEF files I'd >>> previously uploaded to the Ubuntu machine, and the migrated to the >>> Mac, for example: >>> >>> DSC_8937.NEF is accompanied by >>> DSC_8937_NEF_embedded.jpg >>> DSC_8937_NEF_shotwell_1.jpg and >>> DSC_8937_NEF_shotwell.jpg >>> >>> I'm currently using Shotwell 0.12.3 with Ubuntu 12.04 in a >>> Parallels VM. >>> >>> Is it safe to delete any or all of these Shotwell-generated JPGs? >>> >>> Will Shotwell generate a new JPG version if all that's left in a >>> directory is the raw NEF file? Or does it only generate this on the >>> initial import? >>> >>> I don't _need_ the extra space at the moment, but I'd like to >>> dispose of an unnecessary overhead and reduce back-up requirements >>> if I can. >>> >>> Thanks in advance, >>> >>> Michael >>> >>> >>> >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> > > From damienlmoore at gmail.com Tue May 14 15:55:49 2013 From: damienlmoore at gmail.com (Damien Moore) Date: Tue, 14 May 2013 11:55:49 -0400 Subject: [Shotwell] Storing photo edits in metadata? Message-ID: Hi, I see that Shotwell stores image edits in its database http://www.yorba.org/shotwell/help/edit-nondestructive.html. Have you guys given some thought to how you might also store those instructions in the image metadata itself? (You already support this for descriptive metadata, of course.) Full disclosure: I work on my own photo manager, so this isn't really a user support question (I do like shotwell, however, and recommend it to people who ask for an easy to use photo manager). I mostly ask because I am about to embark on implementing my own non-destructive editing process storing the instructions (e.g. crop, rotate, brightness/level/curve/color adjustments) in the photo metadata or in a sidecar. It would be great if there were other programs doing the same thing and we could coordinate on a standard set of tags. I haven't seen any standards for doing this, but I haven't searched very thoroughly either. One option, of course, would just be to register an Xmp namespace for each program and each program can then do its own thing and do its best to import image manipulation instructions from other programs (the Wild West approach). I recognize that image manipulation instructions could be interpreted differently on different implementations, but that's a limitation of any non-destructive editing process. Keep up the good work on Shotwell! Thanks, Damien From jim at yorba.org Tue May 14 18:44:49 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 14 May 2013 18:37:49 -0007 Subject: [Shotwell] Storing photo edits in metadata? In-Reply-To: References: Message-ID: <51928619.a433440a.7ad4.0f20@mx.google.com> We have thought about this, although we've not gone into great detail about it on the wiki. XMP would be the right way to do this, as it allows for user extensions. It would be *best* if there was a standard way to save transformations, but one doesn't appear to exist yet and so it would probably be up to the various projects to come together and agree on a format. Note that some users may want the metadata written to the original file and not a sidecar. Sidecars also introduce the problem of conflicting metadata -- when fields are present in both the original and the sidecar, which has priority? (Probably the sidecar, or the mtime of both files could be compared.) I do think the bulk of transformations could be described in a near-universal way. Color transformations may be the most difficult, since the inputs are reliant on the algorithms, which may be different from application to application. But things like crop and straighten could be described in straightforward terms. So, yes, this is something we've thought a lot about. If there was some momentum to begin something like a standardization process, I know we would definitely like to be a part of that conversation. -- Jim On Tue, May 14, 2013 at 8:55 AM, Damien Moore wrote: > Hi, > > I see that Shotwell stores image edits in its database > http://www.yorba.org/shotwell/help/edit-nondestructive.html. Have you > guys > given some thought to how you might also store those instructions in > the > image metadata itself? (You already support this for descriptive > metadata, > of course.) > > Full disclosure: I work on my own photo manager, so this isn't really > a > user support question (I do like shotwell, however, and recommend it > to > people who ask for an easy to use photo manager). I mostly ask > because I am > about to embark on implementing my own non-destructive editing process > storing the instructions (e.g. crop, rotate, > brightness/level/curve/color > adjustments) in the photo metadata or in a sidecar. It would be great > if > there were other programs doing the same thing and we could > coordinate on a > standard set of tags. I haven't seen any standards for doing this, > but I > haven't searched very thoroughly either. One option, of course, would > just > be to register an Xmp namespace for each program and each program can > then > do its own thing and do its best to import image manipulation > instructions > from other programs (the Wild West approach). I recognize that image > manipulation instructions could be interpreted differently on > different > implementations, but that's a limitation of any non-destructive > editing > process. > > Keep up the good work on Shotwell! > > Thanks, > Damien > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Tue May 14 20:47:02 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 14 May 2013 20:40:02 -0007 Subject: [Shotwell] Fuji .RAF and Canon .CR2 different speed and thumbnail creation In-Reply-To: References: Message-ID: <5192a2bd.e7e1440a.5476.4513@mx.google.com> Shotwell needs to generate the JPEGs because decoding the RAWs each time you access them would take too long. If you want to tweak how these JPEGs are generated, you can specify a RAW editor inside Shotwell's preferences. You probably want to use Camera developer rather than Shotwell developer; the RAW library we use doesn't work with all cameras out there. -- Jim On Sat, May 11, 2013 at 3:47 AM, R S wrote: > Hi, > > I am new to shotwell , I like the program for its clear structure and > > obvious workflow. Thanks for it ! > > But there are some , for my point of view strange behaviors. > I have two cameras, a canon 40D and a Fuji X-E1. > When I import canon raws - shotwell is set to raw developer in the > preferences - everything is fast and correctly imported. > But if there are no corresponding jpegs -developed by the camera- > shotwell > is creating them and writes them into the folder. > I would prefer not to have these extra files in my folder , because I > want > to to create my own jepgs later with my favorite raw converter. It > would > be enough to show little thumbnails - may be stored in the database - > and > just read the embedded jpegs if I click on the thumb to see a > fullscreen > version of the raw. > > Now to the Fuji's. > > When I import in the same way like above, - jpegs already created by > the > camera , only a view thumbs are created , the others are just white > rectangles.The whole import takes a really long time and the CPU > (intel > I5)is used up to 90 %. > When I click on them (thumbs and white rectangles ) they are > displayed ok > in fullscreen mode. But the only chance to get a thumb instead a > white > area, I have to select these white thumbs and switch to raw > developer = > shotwell , then wait a long time (up to hours for a few hundred pics) > and > the switch back raw developer = camera , do get the thumbs. > > Thanx for reading, > > papa > > > > > > > -- > Erstellt mit Operas revolution?rem E-Mail-Modul: > http://www.opera.com/mail/ > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From hendry.michael at gmail.com Tue May 14 22:25:56 2013 From: hendry.michael at gmail.com (Michael Hendry) Date: Tue, 14 May 2013 23:25:56 +0100 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <51913f37.e7e1440a.5476.1565@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> <031B228D-E577-4124-82BD-BA1E1F4C87A1@gmail.com> <51913f37.e7e1440a.5476.1565@mx.google.com> Message-ID: <1CE09817-8FC1-46FD-A1EC-065952C2B8C5@gmail.com> On 13 May 2013, at 20:29, Jim Nelson wrote: > Ah -- something I didn't notice earlier: you're using an old version of Shotwell. The latest version (0.14.1) fixes numerous problems with RAW support, including this issue. I highly recommend upgrading from Yorba's PPA: https://launchpad.net/~yorba/+archive/ppa Thanks, Jim. That worked! But it seems to be important to shut down Shotwell before deleting the Shotwell-generated JPGs, as images tend to be shoved into Missing Files. One feature I didn't expect - the generation of replacement Shotwell-generated JPGs still occurs after Shotwell has been shut down. I had the Nautilus window open on a directory whose JPGs I'd just deleted, and was surprised to find it was being populated with new JPGs as I watched. Michael > > -- Jim > > On Mon, May 13, 2013 at 11:51 AM, Michael Hendry wrote: >> >> On 13 May 2013, at 18:53, Jim Nelson wrote: >> >>> Those extra files are generated by Shotwell because decoding the .NEF file (or any RAW file) takes a lot of CPU power and time. Also, there's two ways Shotwell can "develop" a RAW file: by decoding the file or using one of its internal JPEG files. Generally the internal JPEG file looks better because the camera has tweaked it using various parameters (white point, exposure, etc.) >>> >>> If you delete those files, Shotwell will regenerate them when you next view that file in Shotwell. Note that the latest version of Shotwell (0.14) will not generate so many of them; it's an old bug that caused all those different versions to appear. >>> >>> -- Jim >>> >> >> Thanks, Jim. >> >> I tried deleting the three JPG files accompanying DSC_8937.NEF, and the result was that DSC_8937.NEF became a "Missing File", according to Shotwell, and it disappeared from its event. >> >> After half a minute or so, it appeared to move from Missing FIle to its event again, but double-clicking on it in its event window (to view it) resulting in its going back into the "Missing FIle" slot. >> >> I tried dragging and dropping the file from its folder in the file system into Shotwell, and opted to leave it in place. The image duly reappeared in the relevant event, but no JPG file has been generated, and every time I double-click on it, it bounces back into the "Missing File" box. >> >> At no time since I deleted the JPG files has a new one been generated in the relevant directory. >> >> This is obviously not going to be as easy as I thought! >> >> Could my difficulty have something to do with the fact that the images I'm dealing with were shot entirely in RAW mode (i.e. not RAW+JPG) on my Nikon D70? >> >> Michael >> >> >>> On Sat, May 11, 2013 at 2:14 AM, Michael Hendry wrote: >>>> Earlier this year I retired my elderly Dell PC running Ubuntu 12.04 in favour of a new iMac 27". >>>> >>>> Virtually every application I was using on the Dell can be replaced with a Mac-compiled version, but I'm still running Shotwell in a virtual Ubuntu machine, storing all the images in a shared directory on the Mac. >>>> >>>> I've found that I've got a number of JPG versions of NEF files I'd previously uploaded to the Ubuntu machine, and the migrated to the Mac, for example: >>>> >>>> DSC_8937.NEF is accompanied by >>>> DSC_8937_NEF_embedded.jpg >>>> DSC_8937_NEF_shotwell_1.jpg and >>>> DSC_8937_NEF_shotwell.jpg >>>> >>>> I'm currently using Shotwell 0.12.3 with Ubuntu 12.04 in a Parallels VM. >>>> >>>> Is it safe to delete any or all of these Shotwell-generated JPGs? >>>> >>>> Will Shotwell generate a new JPG version if all that's left in a directory is the raw NEF file? Or does it only generate this on the initial import? >>>> >>>> I don't _need_ the extra space at the moment, but I'd like to dispose of an unnecessary overhead and reduce back-up requirements if I can. >>>> >>>> Thanks in advance, >>>> >>>> Michael >>>> >>>> >>>> >>>> _______________________________________________ >>>> Shotwell mailing list >>>> Shotwell at lists.yorba.org >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> From nigeldodd at gmail.com Wed May 15 09:29:59 2013 From: nigeldodd at gmail.com (Nigel Dodd) Date: Wed, 15 May 2013 10:29:59 +0100 Subject: [Shotwell] Storing photo edits in metadata? In-Reply-To: <51928619.a433440a.7ad4.0f20@mx.google.com> References: <51928619.a433440a.7ad4.0f20@mx.google.com> Message-ID: I am confused. If shotwell stores things like tags in metadata, why can it not recover the tags when it messes up its database? On 14 May 2013 19:44, Jim Nelson wrote: > We have thought about this, although we've not gone into great detail > about it on the wiki. XMP would be the right way to do this, as it allows > for user extensions. It would be *best* if there was a standard way to > save transformations, but one doesn't appear to exist yet and so it would > probably be up to the various projects to come together and agree on a > format. > > Note that some users may want the metadata written to the original file > and not a sidecar. Sidecars also introduce the problem of conflicting > metadata -- when fields are present in both the original and the sidecar, > which has priority? (Probably the sidecar, or the mtime of both files > could be compared.) > > I do think the bulk of transformations could be described in a > near-universal way. Color transformations may be the most difficult, since > the inputs are reliant on the algorithms, which may be different from > application to application. But things like crop and straighten could be > described in straightforward terms. > > So, yes, this is something we've thought a lot about. If there was some > momentum to begin something like a standardization process, I know we would > definitely like to be a part of that conversation. > > -- Jim > > > On Tue, May 14, 2013 at 8:55 AM, Damien Moore > wrote: > >> Hi, >> >> I see that Shotwell stores image edits in its database >> http://www.yorba.org/shotwell/**help/edit-nondestructive.html. >> Have you guys >> given some thought to how you might also store those instructions in the >> image metadata itself? (You already support this for descriptive metadata, >> of course.) >> >> Full disclosure: I work on my own photo manager, so this isn't really a >> user support question (I do like shotwell, however, and recommend it to >> people who ask for an easy to use photo manager). I mostly ask because I >> am >> about to embark on implementing my own non-destructive editing process >> storing the instructions (e.g. crop, rotate, brightness/level/curve/color >> adjustments) in the photo metadata or in a sidecar. It would be great if >> there were other programs doing the same thing and we could coordinate on >> a >> standard set of tags. I haven't seen any standards for doing this, but I >> haven't searched very thoroughly either. One option, of course, would just >> be to register an Xmp namespace for each program and each program can then >> do its own thing and do its best to import image manipulation instructions >> from other programs (the Wild West approach). I recognize that image >> manipulation instructions could be interpreted differently on different >> implementations, but that's a limitation of any non-destructive editing >> process. >> >> Keep up the good work on Shotwell! >> >> Thanks, >> Damien >> ______________________________**_________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell >> >> ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From damienlmoore at gmail.com Wed May 15 15:14:06 2013 From: damienlmoore at gmail.com (Damien Moore) Date: Wed, 15 May 2013 11:14:06 -0400 Subject: [Shotwell] Storing photo edits in metadata? In-Reply-To: <51928619.a433440a.7ad4.0f20@mx.google.com> References: <51928619.a433440a.7ad4.0f20@mx.google.com> Message-ID: Hi Jim, Thanks for the reply. See responses below On Tue, May 14, 2013 at 2:44 PM, Jim Nelson wrote: > We have thought about this, although we've not gone into great detail > about it on the wiki. XMP would be the right way to do this, as it allows > for user extensions. It would be *best* if there was a standard way to > save transformations, but one doesn't appear to exist yet and so it would > probably be up to the various projects to come together and agree on a > format. Agree on the merits of XMP. Adobe has the camera raw schema that could be a starting point: http://www.exiv2.org/tags-xmp-crs.html (Notice that the uri for the schema http://ns.adobe.com/camera-raw-settings/1.0/ is a dead link -- do these things ever go to a live page?) I'm not sure when these are generated, maybe when processed by Adobe's raw processor? In any case, I don't think it would be a good idea to write to those "crs" tags, but one could perhaps use them as a jumping off point for defining a new namespace. One thing I am not sure about is whether it would be better to just define a single tag array-type transform (or a string of xml), say "Xmp.namespace.ImageTransforms" that contains all of the transforms that must be performed (in sequence) instead of a key for each tansform. The problem with defining a key for each transform (or multiple keys for each transform in the case of adobe crs) is that it implies those transforms can either be performed in any order or that there is a canonical ordering. There's also the issue of how to handle multiple transforms (e.g. multiple red eye reductions) vs transforms that should be singletons (e.g. probably only makes sense to have one crop per image). One essential tag to include would be the version of software that generated these keys, which might be helpful when trying to recreate transforms that are idiosyncratic to particular software. > > Note that some users may want the metadata written to the original file > and not a sidecar. Sidecars also introduce the problem of conflicting > metadata -- when fields are present in both the original and the sidecar, > which has priority? (Probably the sidecar, or the mtime of both files > could be compared.) > In my own program, I currently use sidecars as a fallback for whatever exiv2 can't write to. The approach I have taken is that everything the user does to the image is written to the image or a sidecar (i.e. the database can be fully reproduced from the directory of images). Re conflicts -- in my current approach, if the sidecar exists it is given priority over the image metadata (but one could also imagine checking which file is newer and doing something more sophisticated.) In general, Adobe's spec for handling metadata conflicts is very complicated. > > I do think the bulk of transformations could be described in a > near-universal way. Color transformations may be the most difficult, since > the inputs are reliant on the algorithms, which may be different from > application to application. But things like crop and straighten could be > described in straightforward terms. > Agree > > So, yes, this is something we've thought a lot about. If there was some > momentum to begin something like a standardization process, I know we would > definitely like to be a part of that conversation. > Good to know. I might bring this up with the gthumb, DigiKam and DarkTable guys. If the major open source projects could agree on something, that would be a great start. I wonder if this is a spec that freedesktop.orgwould be interested in? Cheers, Damien From jim at yorba.org Wed May 15 17:36:27 2013 From: jim at yorba.org (Jim Nelson) Date: Wed, 15 May 2013 17:29:27 -0007 Subject: [Shotwell] Storing photo edits in metadata? In-Reply-To: References: <51928619.a433440a.7ad4.0f20@mx.google.com> Message-ID: <5193c797.e4dd420a.62e2.1cfd@mx.google.com> It can. If tags are written out to the photo files and the database is corrupted or deleted, it will import those tags when the photo is added to the new database. Are you seeing something different? -- Jim On Wed, May 15, 2013 at 2:29 AM, Nigel Dodd wrote: > I am confused. If shotwell stores things like tags in metadata, why > can it not recover the tags when it messes up its database? > > > On 14 May 2013 19:44, Jim Nelson wrote: >> We have thought about this, although we've not gone into great >> detail about it on the wiki. XMP would be the right way to do this, >> as it allows for user extensions. It would be *best* if there was a >> standard way to save transformations, but one doesn't appear to >> exist yet and so it would probably be up to the various projects to >> come together and agree on a format. >> >> Note that some users may want the metadata written to the original >> file and not a sidecar. Sidecars also introduce the problem of >> conflicting metadata -- when fields are present in both the original >> and the sidecar, which has priority? (Probably the sidecar, or the >> mtime of both files could be compared.) >> >> I do think the bulk of transformations could be described in a >> near-universal way. Color transformations may be the most >> difficult, since the inputs are reliant on the algorithms, which may >> be different from application to application. But things like crop >> and straighten could be described in straightforward terms. >> >> So, yes, this is something we've thought a lot about. If there was >> some momentum to begin something like a standardization process, I >> know we would definitely like to be a part of that conversation. >> >> -- Jim >> >> >> On Tue, May 14, 2013 at 8:55 AM, Damien Moore >> wrote: >>> Hi, >>> >>> I see that Shotwell stores image edits in its database >>> http://www.yorba.org/shotwell/help/edit-nondestructive.html. Have >>> you guys >>> given some thought to how you might also store those instructions >>> in the >>> image metadata itself? (You already support this for descriptive >>> metadata, >>> of course.) >>> >>> Full disclosure: I work on my own photo manager, so this isn't >>> really a >>> user support question (I do like shotwell, however, and recommend >>> it to >>> people who ask for an easy to use photo manager). I mostly ask >>> because I am >>> about to embark on implementing my own non-destructive editing >>> process >>> storing the instructions (e.g. crop, rotate, >>> brightness/level/curve/color >>> adjustments) in the photo metadata or in a sidecar. It would be >>> great if >>> there were other programs doing the same thing and we could >>> coordinate on a >>> standard set of tags. I haven't seen any standards for doing this, >>> but I >>> haven't searched very thoroughly either. One option, of course, >>> would just >>> be to register an Xmp namespace for each program and each program >>> can then >>> do its own thing and do its best to import image manipulation >>> instructions >>> from other programs (the Wild West approach). I recognize that image >>> manipulation instructions could be interpreted differently on >>> different >>> implementations, but that's a limitation of any non-destructive >>> editing >>> process. >>> >>> Keep up the good work on Shotwell! >>> >>> Thanks, >>> Damien >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >>> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > > From jim at yorba.org Wed May 15 17:40:57 2013 From: jim at yorba.org (Jim Nelson) Date: Wed, 15 May 2013 17:33:57 -0007 Subject: [Shotwell] Storing photo edits in metadata? In-Reply-To: References: <51928619.a433440a.7ad4.0f20@mx.google.com> Message-ID: <5193c89f.0794420a.39f7.2180@mx.google.com> > One thing I am not sure about is whether it would be better to just > define a single tag array-type transform (or a string of xml), say > "Xmp.namespace.ImageTransforms" that contains all of the transforms > that must be performed (in sequence) instead of a key for each > tansform. The problem with defining a key for each transform (or > multiple keys for each transform in the case of adobe crs) is that it > implies those transforms can either be performed in any order or that > there is a canonical ordering. > That's a good point. There's a lot of issues here, especially if this format were to support journaling transformations and such. This is why it would be good to have a roundtable of some kind to discuss the issues, so that no application is left out or unable to use it. -- Jim From hendry.michael at gmail.com Wed May 15 21:17:56 2013 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 15 May 2013 22:17:56 +0100 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <1CE09817-8FC1-46FD-A1EC-065952C2B8C5@gmail.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> <031B228D-E577-4124-82BD-BA1E1F4C87A1@gmail.com> <51913f37.e7e1440a.5476.1565@mx.google.com> <1CE09817-8FC1-46FD-A1EC-065952C2B8C5@gmail.com> Message-ID: <5039753E-A9A2-40E5-971F-460827AC689E@gmail.com> On 14 May 2013, at 23:25, Michael Hendry wrote: > > On 13 May 2013, at 20:29, Jim Nelson wrote: > >> Ah -- something I didn't notice earlier: you're using an old version of Shotwell. The latest version (0.14.1) fixes numerous problems with RAW support, including this issue. I highly recommend upgrading from Yorba's PPA: https://launchpad.net/~yorba/+archive/ppa > > Thanks, Jim. That worked! > > But it seems to be important to shut down Shotwell before deleting the Shotwell-generated JPGs, as images tend to be shoved into Missing Files. > > One feature I didn't expect - the generation of replacement Shotwell-generated JPGs still occurs after Shotwell has been shut down. I had the Nautilus window open on a directory whose JPGs I'd just deleted, and was surprised to find it was being populated with new JPGs as I watched. > > Michael > I've been working my way through, deleting the additional files, and noticed that some directories have NEF files without corresponding JPG files. I've tried shutting down Shotwell and deleting these files (in case they'd been left behind), but they're recreated when I start Shotwell again. Michaels-iMac:29 michaelhendry$ ls DSC_6713.NEF DSC_6730.NEF DSC_6747.NEF DSC_6764.NEF DSC_6779_NEF_shotwell.jpg DSC_6714.NEF DSC_6731.NEF DSC_6748.NEF DSC_6765.NEF DSC_6780.NEF DSC_6715.NEF DSC_6732.NEF DSC_6749.NEF DSC_6766.NEF DSC_6780_NEF_shotwell.jpg DSC_6716.NEF DSC_6733.NEF DSC_6750.NEF DSC_6767.NEF DSC_6781.NEF DSC_6717.NEF DSC_6734.NEF DSC_6751.NEF DSC_6768.NEF DSC_6781_NEF_shotwell.jpg DSC_6718.NEF DSC_6735.NEF DSC_6752.NEF DSC_6769.NEF DSC_6782.NEF DSC_6719.NEF DSC_6736.NEF DSC_6753.NEF DSC_6770.NEF DSC_6782_NEF_shotwell.jpg DSC_6720.NEF DSC_6737.NEF DSC_6754.NEF DSC_6771.NEF DSC_6783.NEF DSC_6721.NEF DSC_6738.NEF DSC_6755.NEF DSC_6772.NEF DSC_6784.NEF DSC_6722.NEF DSC_6739.NEF DSC_6756.NEF DSC_6773.NEF DSC_6784_NEF_shotwell.jpg DSC_6723.NEF DSC_6740.NEF DSC_6757.NEF DSC_6774.NEF DSC_6785.NEF DSC_6724.NEF DSC_6741.NEF DSC_6758.NEF DSC_6775.NEF DSC_6786.NEF DSC_6725.NEF DSC_6742.NEF DSC_6759.NEF DSC_6776.NEF DSC_6786_NEF_shotwell.jpg DSC_6726.NEF DSC_6743.NEF DSC_6760.NEF DSC_6777.NEF DSC_6727.NEF DSC_6744.NEF DSC_6761.NEF DSC_6778.NEF DSC_6728.NEF DSC_6745.NEF DSC_6762.NEF DSC_6778_NEF_shotwell.jpg DSC_6729.NEF DSC_6746.NEF DSC_6763.NEF DSC_6779.NEF Michaels-iMac:29 michaelhendry$ Although all the above images were taken at a single event (a wedding), the majority are said to have been Developed by the Camera, and the remainder (those with JPGs) by Shotwell. I can't see any obvious reason why Shotwell (set in Preferences as the default developer) shouldn't have developed all of the images. There's probably some simple explanation? Michael >> >> -- Jim >> >> On Mon, May 13, 2013 at 11:51 AM, Michael Hendry wrote: >>> >>> On 13 May 2013, at 18:53, Jim Nelson wrote: >>> >>>> Those extra files are generated by Shotwell because decoding the .NEF file (or any RAW file) takes a lot of CPU power and time. Also, there's two ways Shotwell can "develop" a RAW file: by decoding the file or using one of its internal JPEG files. Generally the internal JPEG file looks better because the camera has tweaked it using various parameters (white point, exposure, etc.) >>>> >>>> If you delete those files, Shotwell will regenerate them when you next view that file in Shotwell. Note that the latest version of Shotwell (0.14) will not generate so many of them; it's an old bug that caused all those different versions to appear. >>>> >>>> -- Jim >>>> >>> >>> Thanks, Jim. >>> >>> I tried deleting the three JPG files accompanying DSC_8937.NEF, and the result was that DSC_8937.NEF became a "Missing File", according to Shotwell, and it disappeared from its event. >>> >>> After half a minute or so, it appeared to move from Missing FIle to its event again, but double-clicking on it in its event window (to view it) resulting in its going back into the "Missing FIle" slot. >>> >>> I tried dragging and dropping the file from its folder in the file system into Shotwell, and opted to leave it in place. The image duly reappeared in the relevant event, but no JPG file has been generated, and every time I double-click on it, it bounces back into the "Missing File" box. >>> >>> At no time since I deleted the JPG files has a new one been generated in the relevant directory. >>> >>> This is obviously not going to be as easy as I thought! >>> >>> Could my difficulty have something to do with the fact that the images I'm dealing with were shot entirely in RAW mode (i.e. not RAW+JPG) on my Nikon D70? >>> >>> Michael >>> >>> >>>> On Sat, May 11, 2013 at 2:14 AM, Michael Hendry wrote: >>>>> Earlier this year I retired my elderly Dell PC running Ubuntu 12.04 in favour of a new iMac 27". >>>>> >>>>> Virtually every application I was using on the Dell can be replaced with a Mac-compiled version, but I'm still running Shotwell in a virtual Ubuntu machine, storing all the images in a shared directory on the Mac. >>>>> >>>>> I've found that I've got a number of JPG versions of NEF files I'd previously uploaded to the Ubuntu machine, and the migrated to the Mac, for example: >>>>> >>>>> DSC_8937.NEF is accompanied by >>>>> DSC_8937_NEF_embedded.jpg >>>>> DSC_8937_NEF_shotwell_1.jpg and >>>>> DSC_8937_NEF_shotwell.jpg >>>>> >>>>> I'm currently using Shotwell 0.12.3 with Ubuntu 12.04 in a Parallels VM. >>>>> >>>>> Is it safe to delete any or all of these Shotwell-generated JPGs? >>>>> >>>>> Will Shotwell generate a new JPG version if all that's left in a directory is the raw NEF file? Or does it only generate this on the initial import? >>>>> >>>>> I don't _need_ the extra space at the moment, but I'd like to dispose of an unnecessary overhead and reduce back-up requirements if I can. >>>>> >>>>> Thanks in advance, >>>>> >>>>> Michael >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Shotwell mailing list >>>>> Shotwell at lists.yorba.org >>>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> > From man.music860 at gmail.com Thu May 16 10:48:10 2013 From: man.music860 at gmail.com (Music Man) Date: Thu, 16 May 2013 16:18:10 +0530 Subject: [Shotwell] OT Writing an Article about Shotwell Message-ID: Hi ! I'm writing an article about FOSS personal photo management software and was wondering whether anyone could suggest a way to get in touch with the current project lead (preferably email address) ? I love FOSS and hope my articles will bring brilliant projects like Shotwell to more peoples' attention. Thank you all for taking the time to develop and maintain Shotwell. Sorry for posting off topic. Thanks, Tushar Bhargava. From jim at yorba.org Thu May 16 18:02:34 2013 From: jim at yorba.org (Jim Nelson) Date: Thu, 16 May 2013 17:55:34 -0007 Subject: [Shotwell] OT Writing an Article about Shotwell In-Reply-To: References: Message-ID: <51951f34.8f0a430a.1d27.47e1@mx.google.com> Tushar, you can contact me directly at jim at yorba.org. -- Jim On Thu, May 16, 2013 at 3:48 AM, Music Man wrote: > Hi ! > > I'm writing an article about FOSS personal photo management software > and > was wondering whether anyone could suggest a way to get in touch with > the > current project lead (preferably email address) ? > > I love FOSS and hope my articles will bring brilliant projects like > Shotwell to more peoples' attention. Thank you all for taking the > time to > develop and maintain Shotwell. > > Sorry for posting off topic. > > Thanks, > Tushar Bhargava. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Thu May 16 18:35:18 2013 From: jim at yorba.org (Jim Nelson) Date: Thu, 16 May 2013 18:28:18 -0007 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <5039753E-A9A2-40E5-971F-460827AC689E@gmail.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> <031B228D-E577-4124-82BD-BA1E1F4C87A1@gmail.com> <51913f37.e7e1440a.5476.1565@mx.google.com> <1CE09817-8FC1-46FD-A1EC-065952C2B8C5@gmail.com> <5039753E-A9A2-40E5-971F-460827AC689E@gmail.com> Message-ID: <519526e0.e7e1440a.1cab.484a@mx.google.com> > I can't see any obvious reason why Shotwell (set in Preferences as > the default developer) shouldn't have developed all of the images. > > There's probably some simple explanation? > Without looking into the code, it may be that the developed JPEGs are only regenerated when you view (double-click) the photo. Shotwell should eventually develop those images, whether due to user action or background process. -- Jim From hendry.michael at gmail.com Thu May 16 20:04:02 2013 From: hendry.michael at gmail.com (Michael Hendry) Date: Thu, 16 May 2013 21:04:02 +0100 Subject: [Shotwell] Superfluous JPG versions of imported NEF files In-Reply-To: <519526e0.e7e1440a.1cab.484a@mx.google.com> References: <518434a5.240b450a.40ab.ffffeed1@mx.google.com> <5187f393.68ed440a.7e71.6a5d@mx.google.com> <51884ca0.2603430a.2119.ffffd814@mx.google.com> <51885671.9070507@gmail.com> <518987c9.84a2440a.23f1.ffffa461@mx.google.com> <518afaf3.e5f2440a.3a7d.2e2a@mx.google.com> <518d3e12.a6fe440a.6d9a.29c7@mx.google.com> <518d61f1.4f79420a.6e88.3f7b@mx.google.com> <66113CA6-D8F9-455C-B2CF-D18DB5A00927@gmail.com> <519128a4.a433440a.7ad4.ffffdd10@mx.google.com> <031B228D-E577-4124-82BD-BA1E1F4C87A1@gmail.com> <51913f37.e7e1440a.5476.1565@mx.google.com> <1CE09817-8FC1-46FD-A1EC-065952C2B8C5@gmail.com> <5039753E-A9A2-40E5-971F-460827AC689E@gmail.com> <519526e0.e7e1440a.1cab.484a@mx.google.com> Message-ID: <243E8899-FB37-4330-8C54-4EBE2F5004AF@gmail.com> On 16 May 2013, at 19:35, Jim Nelson wrote: >> I can't see any obvious reason why Shotwell (set in Preferences as the default developer) shouldn't have developed all of the images. >> >> There's probably some simple explanation? > > Without looking into the code, it may be that the developed JPEGs are only regenerated when you view (double-click) the photo. Shotwell should eventually develop those images, whether due to user action or background process. > > -- Jim Thanks, Jim. I've left Shotwell running all day, but no more JPG files have been generated. I've also run through the whole event by double-clicking on the first thumbnail and displaying it in full-screen size, and then right-arrowing through from beginning to end. Still there are only seven JPG files in this directory. I shouldn't complain, because there is no apparent performance hit, and I'm saving a lot of disc space, but I'm worried that I might have to pay for this seemingly free lunch in the end! I'm going to be away from home for a couple of weeks, will continue to investigate this oddity when I get back. Michael From dougie at highmoor.co.uk Sun May 19 17:49:06 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 19 May 2013 18:49:06 +0100 Subject: [Shotwell] deleting photos : confusion + gimp integration In-Reply-To: References: Message-ID: <51991092.5050503@highmoor.co.uk> On 06/04/13 01:46, Lucas Beeler wrote: > [ ... ] > You're not the first person to point this out. Indeed, we at Yorba think > that the whole thing could be clearer too -- we even have a feature request > on this topic here: http://redmine.yorba.org/issues/2645. > > First, a few things to keep in mind. Shotwell has the notion of a "library > directory," which is the folder on disk where the photo files in Shotwell's > library are stored (provided you selected the default "Copy to Library" > option when you imported the photos). Second, Shotwell has its own > Wastebasket that is separate from the system Wastebasket. When you select > some photos in Shotwell and then press the "Delete" key on your keyboard, > the photos are moved to Shotwell's private Wastebasket. While the photos > change locations within Shotwell, the location of the photo files on your > hard disk does not change. In particular, Shotwell does not move the photo > files into the system Wastebasket on your desktop. The photo files stay > right where they were -- in your library directory. Now, let's say that > after a few hours of using Shotwell, you've reached the point where you're > really, really, terribly sure that you do actually want to delete the > photos in Shotwell's private Wastebasket. In this case, once again, > "delete" means "delete from Shotwell" and not "delete the actual photo file > on disk." To do this, in Shotwell, you switch to the Wastebasket page and > click the "Empty Wastebasket" button. At this point, you will have deleted > the photos from within Shotwell, but this says nothing about what happens > to the actual photo files on disk. So Shotwell asks you "Do you want to > move the file(s) to the system Wastebasket?" This question pertains to the > photo files. If you say yes, the photo files will be moved from your > library directory into the system wastebasket. If you say no, the photo > files will stay put in the library directory. Either way, the photos will > be deleted from within Shotwell. > [ ... ] I've encountered a related problem with deletion that may have nothing to do with Shotwell and more to do with XFCE. It's a new PC in which I've decided to import my images from the old PC into a new Shotwell install (rather than copy over the database), as well as importing images from various other sources. I now have around 61,000 images. The problem came to my notice when I tried to delete multiple images using my old Shift-Delete technique and found there was a problem. I could explain in detail but it's easier just to upload a screenshot showing the error messages in the log file. If I do the deletion in two stages - as described above - I still get an error, but the deletion goes ahead after selecting delete. (If done using Shift-Del it only deletes one image in a multiple selection). Sorry, probably not very clear, but the attachment should be. Is it possible I need to create an xfce wastebasket? I seem to have a ~/.local/share/Trash filesystem Dougie [ EDIT: screenshot available: http://www.fellandforest.co.uk/p326476854/h6ACE9C30#h6ace9c30 instead of attachment ] [ EDIT 2: helps if I delete the original attachment :-) ] From joseph.bylund at gmail.com Sun May 19 18:50:09 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Sun, 19 May 2013 14:50:09 -0400 Subject: [Shotwell] deleting photos : confusion + gimp integration In-Reply-To: <51991092.5050503@highmoor.co.uk> References: <51991092.5050503@highmoor.co.uk> Message-ID: <51991EE1.7070400@gmail.com> On 05/19/2013 01:49 PM, Dougie Nisbet wrote: > On 06/04/13 01:46, Lucas Beeler wrote: > > >> [ ... ] >> You're not the first person to point this out. Indeed, we at Yorba think >> that the whole thing could be clearer too -- we even have a feature >> request >> on this topic here: http://redmine.yorba.org/issues/2645. >> >> First, a few things to keep in mind. Shotwell has the notion of a >> "library >> directory," which is the folder on disk where the photo files in >> Shotwell's >> library are stored (provided you selected the default "Copy to Library" >> option when you imported the photos). Second, Shotwell has its own >> Wastebasket that is separate from the system Wastebasket. When you >> select >> some photos in Shotwell and then press the "Delete" key on your >> keyboard, >> the photos are moved to Shotwell's private Wastebasket. While the photos >> change locations within Shotwell, the location of the photo files on >> your >> hard disk does not change. In particular, Shotwell does not move the >> photo >> files into the system Wastebasket on your desktop. The photo files stay >> right where they were -- in your library directory. Now, let's say that >> after a few hours of using Shotwell, you've reached the point where >> you're >> really, really, terribly sure that you do actually want to delete the >> photos in Shotwell's private Wastebasket. In this case, once again, >> "delete" means "delete from Shotwell" and not "delete the actual >> photo file >> on disk." To do this, in Shotwell, you switch to the Wastebasket page >> and >> click the "Empty Wastebasket" button. At this point, you will have >> deleted >> the photos from within Shotwell, but this says nothing about what >> happens >> to the actual photo files on disk. So Shotwell asks you "Do you want to >> move the file(s) to the system Wastebasket?" This question pertains >> to the >> photo files. If you say yes, the photo files will be moved from your >> library directory into the system wastebasket. If you say no, the photo >> files will stay put in the library directory. Either way, the photos >> will >> be deleted from within Shotwell. >> [ ... ] > > I've encountered a related problem with deletion that may have nothing > to do with Shotwell and more to do with XFCE. > > It's a new PC in which I've decided to import my images from the old > PC into a new Shotwell install (rather than copy over the database), > as well as importing images from various other sources. I now have > around 61,000 images. > > The problem came to my notice when I tried to delete multiple images > using my old Shift-Delete technique and found there was a problem. I > could explain in detail but it's easier just to upload a screenshot > showing the error messages in the log file. If I do the deletion in > two stages - as described above - I still get an error, but the > deletion goes ahead after selecting delete. (If done using Shift-Del > it only deletes one image in a multiple selection). Sorry, probably > not very clear, but the attachment should be. Dougie, I noticed you have some long filenames, does what you're experiencing match up with this: http://redmine.yorba.org/issues/5046 ? -Joe From dougie at highmoor.co.uk Sun May 19 19:32:37 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 19 May 2013 20:32:37 +0100 Subject: [Shotwell] deleting photos : confusion + gimp integration In-Reply-To: <51991EE1.7070400@gmail.com> References: <51991092.5050503@highmoor.co.uk> <51991EE1.7070400@gmail.com> Message-ID: <519928D5.7020603@highmoor.co.uk> On 19/05/13 19:50, Joseph Bylund wrote: > > Dougie, > I noticed you have some long filenames, does what you're experiencing > match up with this: http://redmine.yorba.org/issues/5046 ? > -Joe > :-) Ha! That bug report looks familiar. It might be connected, but I'm not sure (yet). The only difference is that my pathname is slightly longer (I've gone from /images to /store1/images). But it should be an easy one to test. When I get the chance I'll import a short-name jpeg and see if it makes a difference. Dougie From caccolangrifata at gmail.com Tue May 21 15:21:44 2013 From: caccolangrifata at gmail.com (caccolangrifata .) Date: Tue, 21 May 2013 17:21:44 +0200 Subject: [Shotwell] Regenerate thumbnails?!? Message-ID: Hi all! Long short story I have delete .cache/shotwell folder and all thumbnail are gone! Easy regeneration by opening shotwell and scroll the library. Great shotwell 0.14 Problem: 10k photo! I have to scroll all the library and wait the regeneration :-/ Question: Is there another way? like :$ shotwell --regenerate-thumb shotwell 0.14.1 on Ubuntu 13.04 Thanks!! -- caccolangrifata From mknepher at bluethingy.com Tue May 21 16:43:07 2013 From: mknepher at bluethingy.com (Michael Knepher) Date: Tue, 21 May 2013 09:43:07 -0700 Subject: [Shotwell] Shutterfly support Message-ID: <1369154587.18033.6.camel@Pelerin> I've got my wife using Shotwell to manage our photos, and it works well for her with the exception of trying to upload photos to her Shutterfly account. Shutterfly's web upload tools tend to change, and there's a recurring problem with case-sensitivity in the file selector filters looking for *.jpg, and the cameras using *.JPG, so I usually have to assist in getting files uploaded for her. There's a feature request in the issue tracker that indicates a wish to implement this support, but there doesn't seem to have been any activity on it for 2 years. Would this be a difficult plugin to implement, or has it just fallen through the cracks? http://redmine.yorba.org/issues/1094 Thanks, Michael Knepher From jim at yorba.org Tue May 21 20:15:47 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 21 May 2013 20:08:47 -0007 Subject: [Shotwell] Shutterfly support In-Reply-To: <1369154587.18033.6.camel@Pelerin> References: <1369154587.18033.6.camel@Pelerin> Message-ID: <519bd5f0.0aec440a.750e.564e@mx.google.com> I don't know that it would be any more difficult to implement than the other Web sharing plugins, but it's not something we have any plans for in the immediate future. It would be great if someone in the community stepped forward to give it a try. We do have documentation on building a plugin and the other plugins could be used for examples: http://redmine.yorba.org/projects/shotwell/wiki/ShotwellArchWritingPlugins http://redmine.yorba.org/projects/shotwell/wiki/ShotwellPrelimPublishingAPIDoc -- Jim On Tue, May 21, 2013 at 9:43 AM, Michael Knepher wrote: > I've got my wife using Shotwell to manage our photos, and it works > well > for her with the exception of trying to upload photos to her > Shutterfly > account. Shutterfly's web upload tools tend to change, and there's a > recurring problem with case-sensitivity in the file selector filters > looking for *.jpg, and the cameras using *.JPG, so I usually have to > assist in getting files uploaded for her. > > There's a feature request in the issue tracker that indicates a wish > to > implement this support, but there doesn't seem to have been any > activity > on it for 2 years. Would this be a difficult plugin to implement, or > has > it just fallen through the cracks? > > http://redmine.yorba.org/issues/1094 > > Thanks, > Michael Knepher > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From je.pringle at gmail.com Fri May 24 09:16:46 2013 From: je.pringle at gmail.com (James Pringle) Date: Fri, 24 May 2013 10:16:46 +0100 Subject: [Shotwell] Authorising Flickr using a Google Account?? In-Reply-To: References: Message-ID: Hi, I'd like to authorise Flickr and Shotwell, however, I use google as my Flickr log in instead of yahoo. As far as I can see this isn't an option. Is there a work around? Thanks in advance. James From jim at yorba.org Fri May 24 18:06:48 2013 From: jim at yorba.org (Jim Nelson) Date: Fri, 24 May 2013 17:59:48 -0007 Subject: [Shotwell] Authorising Flickr using a Google Account?? In-Reply-To: References: Message-ID: <519fac36.68f0420a.642c.fffff3a3@mx.google.com> You can log in to Flickr with Google? I had no idea. Where do you do that? -- Jim On Fri, May 24, 2013 at 2:16 AM, James Pringle wrote: > Hi, > > I'd like to authorise Flickr and Shotwell, however, I use google as my > Flickr log in instead of yahoo. As far as I can see this isn't an > option. > > Is there a work around? > > Thanks in advance. > James > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From je.pringle at gmail.com Fri May 24 18:39:18 2013 From: je.pringle at gmail.com (James Pringle) Date: Fri, 24 May 2013 19:39:18 +0100 Subject: [Shotwell] Authorising Flickr using a Google Account?? In-Reply-To: References: <519fac36.68f0420a.642c.fffff3a3@mx.google.com> Message-ID: It may be something new as I've only just come back to flickr after a few years. http://m.flickr.com/signin/ There's an option to sign in with Google. On 24 May 2013 19:06, "Jim Nelson" wrote: You can log in to Flickr with Google? I had no idea. Where do you do that? -- Jim On Fri, May 24, 2013 at 2:16 AM, James Pringle wrote: Hi, I'd like to authorise Flickr and Shotwell, however, I use google as my Flickr log in instead of yahoo. As far as I can see this isn't an option. Is there a work around? Thanks in advance. James _______________________________________________ Shotwell mailing list Shotwell at lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From jim at yorba.org Fri May 24 19:11:59 2013 From: jim at yorba.org (Jim Nelson) Date: Fri, 24 May 2013 19:04:59 -0007 Subject: [Shotwell] Authorising Flickr using a Google Account?? In-Reply-To: References: <519fac36.68f0420a.642c.fffff3a3@mx.google.com> Message-ID: <519fbb7d.86f1440a.4fc3.fffff2ab@mx.google.com> Interesting. When I sign in to Flickr already logged in to Yahoo!, I didn't see those options. We recently updated the Flickr login to use the new OAuth routines, and logging in that way gives me the option to login via Google or Facebook. If you'd like to see it in action, you could try our Daily Build PPA (https://launchpad.net/~yorba/+archive/daily-builds/) or build it from our git repo (http://www.yorba.org/projects/shotwell/install/). -- Jim On Fri, May 24, 2013 at 11:39 AM, James Pringle wrote: > It may be something new as I've only just come back to flickr after a > few years. > > http://m.flickr.com/signin/ > > There's an option to sign in with Google. > On 24 May 2013 19:06, "Jim Nelson" wrote: >> You can log in to Flickr with Google? I had no idea. Where do you >> do that? >> >> -- Jim >> >> On Fri, May 24, 2013 at 2:16 AM, James Pringle >> wrote: >>> Hi, >>> >>> I'd like to authorise Flickr and Shotwell, however, I use google as >>> my >>> Flickr log in instead of yahoo. As far as I can see this isn't an >>> option. >>> >>> Is there a work around? >>> >>> Thanks in advance. >>> James >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> From jhoran1us at yahoo.com Fri May 31 09:32:22 2013 From: jhoran1us at yahoo.com (jhoran) Date: Fri, 31 May 2013 09:32:22 +0000 (UTC) Subject: [Shotwell] Fuji .RAF and Canon .CR2 different speed and thumbnail creation References: <5192a2bd.e7e1440a.5476.4513@mx.google.com> Message-ID: Jim Nelson writes: > > Shotwell needs to generate the JPEGs because decoding the RAWs each > time you access them would take too long. If you want to tweak how > these JPEGs are generated, you can specify a RAW editor inside > Shotwell's preferences. > > You probably want to use Camera developer rather than Shotwell > developer; the RAW library we use doesn't work with all cameras out > there. > Hi all, got the same problem with Fuji RAF files : very long time to import although the Developer is set to 'Camera'. No JPG thumb is generated though.