Martin, thanks as always for your valuable observations and useful suggestions.
On 08/12/2010 02:09 PM, Martin Olsson wrote: > Since you added RAW support in the last version I have now actually tried > Shotwell with > my real photo collection. Here are some things that I noted (some minor 0.7.0 > bugs at the end): > > First I ran into some already ticket stuff (so I'm just listen them as a +1 > for 0.8.0): > * I really really miss a Sharpen button or Sharpen slider (ticket #690). > Yes - this would be nice. I've upped the ticket priority to high. > * I don't want the "master copy" of any data in ~/.shotwell, I prefer if tags > are applied > directly as metadata to the original photo files, ofc at very explicit > opt-in from the user. (ticket #1897). > Right. Hopefully coming in the next couple of releases. > Other issues I encountered in my workflow (these most likely not relevant for > 0.7.0): > * I shoot RAW+JPG and the RAW photos look very poor since they are rendering > using "default settings". > Here are some RAW+JPG equivalents directly from the camera (no > modifications). Are you passing any > parameters to libraw when you do the conversion or is this a libraw > "bug"? Also I wonder if this affects > all RAW capable cameras much or if different camera have different > specific problems... > Anyway, import these: > http://temp.minimum.se/shotwell_raw/ > Yes - our rendering of RAW photos is not yet as nice as we'd like. There are various parameters we can specify to libraw when we do the conversion, and it's possible that we're not yet making the ideal choices. We'd like our RAW rendering to match that performed by Eye of GNOME and Evince, but we're not there yet (this is http://trac.yorba.org/ticket/2246). Even then, however, our rendering may not look as good as the JPEG coming off of the camera. If you shoot RAW+JPEG and import both, we should manage them as a pair and optionally use the JPEG for rendering (http://trac.yorba.org/ticket/1772). If no separate JPEG file is available but the RAW file has an embedded JPEG of sufficient size, we should optionally use it for rendering (http://trac.yorba.org/ticket/1771). > * I would like to have "Camera: BLAH" in the basic metadata rather than > hidden away in the extended dialog. > Ticket at http://trac.yorba.org/ticket/2401 . > * While cropping I'd like to be able to live preview the pixel size of the > crop region while I'm resizing it. > Right now the "Size:" field in "basic info" is not updated until I finish > the crop by pressing OK. > A good suggestion. Ticketed at http://trac.yorba.org/ticket/2397 . > * It would be nice if the "basic metadata" panel was re-designed so that it > fits more and more stuff into itself > the bigger I make it. So if I drag the horizontal splitter upwards, more > and more metadata shows up in this > pane (right now I just get more gray space). > Worth considering; ticketed at http://trac.yorba.org/ticket/2401 . > * I miss the ability to zoom out more than "fit photo to screen" (i.e. make > photo smaller than the photo viewport). > This is useful for quickly previewing what the photo would look like > inserted into a blog post or similar > (i.e. resized and inserted into the text). > A reasonable idea; ticketed at http://trac.yorba.org/ticket/2398 . > * At some point I wanted to inspect a photo at 100% size to check noise > levels, sharpness etc. So I zoom to > maximum but then I realized the UI doesn't tell me if "maximum zoom" > means "100% size" or not. I guess it > does but I think it would be nice if there was some actual percentage > number that changed when the zoom slider > is dragged just so that the user knows for sure what magnification he/she > is at. Since you don't have a status > bar (which I think is a good thing) maybe some tiny popup window could > appear which goes away immediately when > the user releases the zoom slider (similar to the Adjust dialog but a lot > smaller and hovering above the photo > just above the zoom slider itself)? > Ticketed at http://trac.yorba.org/ticket/2399 . > * A lot of important metadata is not viewable in Shotwell (but running exiv2 > shows it), in particular: > - I really miss "ISO Speed" > - It would also be useful to have "Metering mode" and "White balance" > included. > - And just for fun, it would be nice to include the EXIF "ShutterCount" > (i.e. total number of times the shutter > has opened on this particular camera). > - What lens was used (mostly a DSLR feature but it's something I miss a > lot from Adobe Lightroom). > Not sure if this info is available in generic EXIF but it's certain > available in for example > "Exif.NikonLd2.LensIDNumber" (see http://www.exiv2.org/tags-nikon.html > etc). > All reasonable ideas; ticketd at http://trac.yorba.org/ticket/2400 . > * I would like to be able to easily view "all photos I've ever taken with a > rating>X". Right now the > "View::Filter Photos" utility only works well for a single event. If I > select a "Month" or a year in the > event treeview I still see all events listed in the right hand side which > means I have to open each and > every event to see if there actually was any rating>N photos from that > event. I'd like some sort of smart > solution to this although I'm not sure what the best way to do it. > To see all photos you've ever taken with a rating >X, you can simply select the Photos view, then choose a ratings filter. But you're right that it would also be nice to be able to see all photos from a given year or month, filtered by rating. When the user chooses a year or month in the sidebar, we'd like to give them a choice of views so they can see either all events for that year/month (like today) or all photos from that year/month; see http://trac.yorba.org/ticket/2413 . Once that's implemented, you'll easily be able to see all photos from a given month filtered by rating, for example. > * Shotwell says "focal length: 60mm" but exiv2 terminal says "60mm (35mm > sensor equivalent: 90mm)" and I think > the latter is better (many people might not know the crop factor for > their sensor or even if they do they > might just mistake the given number for 35mm equiv). See > "Exif.Photo.FocalLengthIn35mmFilm". > Good point. Ticketed at http://trac.yorba.org/ticket/2402 . > > POTENTIAL BUGS: > > * This photo fails to import but (as far as I know it's not a corrupt file > and it opens just fine using F-Spot. > The photo came straight from my Nikon D50, although it's been sitting in > my photo folder for a long time so > maybe some program or HDD issue accidently corrupted it without me > noticing it). Here is the file: > http://temp.minimum.se/shotwell_other/file_error_DSC_0128.NEF > When I attempt to open this photo in UFRaw I get an error "Unexpected end of file", so it seems that not only Shotwell has trouble with this particular file. > * Repro steps: For a large photo collection, select "Photos" and then select > the top-left-most photo (without > opening it). Now press "Page Down" key 2-3 times. Notice that the > selection is no longer within the currently > screenful which is unintuitive compared to most other apps. This means > that if I browse around by mixing "page down" > and actual "key down" strokes things get messed up since the "key down" > takes me to where I was before I started > hitting "page down". I suggest you fix it so that pressing "page down" > actually keeps a photo within the current > screenful selected, for example if I start out with photo X selected, > then maybe you could compute the coordinates > at the center of that photos thumbnail relative to the viewport origin > and then when after the "page down" when > you arrive at the new screenful, just select the photo that lies closest > to those coordinates (I'm thinking this > semi complex procedure is needed for cases when people have imported > images of highly irregular shapes like a few > really really wide ones which tend to mess up the column alignment). > We've tried to make keyboard selection in Shotwell work exactly like in Nautilus's icon view, which also has exactly the behavior you described: Page Down does not change the selection. There are advantages and disadvantages to this approach. One advantage is that if I want to select a disjoint, scattered set of photos, I can Ctrl+click a few, press Page Down to look for more, then Ctrl+Click some more. In any case, I do think we want to act like Nautilus for the sake of GNOME consistency. > * Gtk-Critical Warning "_gtk_accel_group_detach: assertion `g_slist_find > (accel_group->acceleratables, object) != NULL' failed". > Repro steps: Import some photos, single click the first event to open it, > open the first photo, single click that same > event again to go back all view all the photos in the event. Now two bad > things happen (two bugs imo), first off the assert > fires and secondly shotwell assumes I want to rename the event which I > don't want (I just want to go back to viewing all the > photos from that event). For the latter part I could expect single click > to mean rename, only if that event was already > selected and it's photos were already visible in the main right hand view > (agree?). Anyway, here is the stack leading up > to the gtk-critical assert (and you can also hit a similar one via > "IA__gtk_window_add_accel_group"): > Good catch. Ticketed at http://trac.yorba.org/ticket/2407 . Thanks again! adam _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
