Some comments on Podcast #29

Podcast Uncategorized

I quite enjoy the work George Jardine puts into his podcasts. I like both the Lightroom specific and more generic photographer podcasts. However, there is nothing quite like listening in on conversation between Mark, Thomas, Zalman, Jeff and (did he speak at all?) Michael.
Many things were covered and I’m just putting my thoughts down on some of them. No one has to listen, but hey, at least there out there.
RAW + JPEG: While I usually shoot RAW, I think there are quite a few things that I do that would benefit from doing a RAW+JPEG workflow. With Landscapes, it would great to have the camera jpeg set to the final look I prefer to go with the RAW for a target look for my processing. Not to mention that if the file is already or nearly perfect, then I can simply use it without needing to process the RAW any further. Other people use it different ways and I do feel that Adobe needs to address this with an Option.

Options: Mark mentions that they are trying to keep it simple and that in Photoshop they simply would add an option for different things. Well not adding options in Lightroom actually makes it complicated for the USER! It means that we get forced into find ways of working around limits provided in Lightroom. Whereas if there was an option we would merely set it the way we wanted and then forget all about the other ways until we need to use them. This is all about blending Lightroom to our workflow and not being forced into other workflows. (I’m not referring to the database v browser here, I need the database and am happy to forego any browser implementation for better DAM handling and folder watching).

Import: We need better previewing in Import to allow pre selection of imported files. This would forego the need to use Bridge to make importable selections. While we’re discussing Import, I’d like to request the return of a feature that existed in Beta 4. I want to see the return of Metadata entry on a per folder basis in Lightroom. Each folder/date generally requires different metadata/keywords/ even development sometimes. In B4 you could enter these per Shoot. I know the shoots paradigm is gone, but you could still apply this to folders. Currently you must do multiple imports to get this. Being able to do it in one go saves a lot of time. An ‘Apply to All’ checkbox would return to current usage (on by default for those users not needing the more sophisticated options).

I’ll probably listen to this again and maybe make further comments in it.

Update: Once comment I will make here is on 2 additions to the podcast style. I like the polish that George has added with the music. It just gives it a ‘pro’ edge IMHO. Also the longer introduction before the actual content begins is quite welcome in setting up the scene for us. Recently George has been leaving in the pre podcast banter, giving an insight into the people we are listening to that can come from no other source. Kudos to George for this.

12 thoughts on “Some comments on Podcast #29

  1. Glad I’m not the only one who wants to see RAW+Jpeg handling… some would make you feel like you’re scum if you want to do that.

    Also agree STRONGLY that the lack of options does NOT simplify the program… you waste more time looking for options that you believe should be there, and then you’re left struggling to conform, if you can. Listen up Adobe… options are not a bad thing!

  2. In the Library module on the laptop use the Metadata>XMP>Export XMP to file command on the files you want to move. Copy the files to the Desktop and import. XMP info will be embedded in jpg, tif and dng files, while RAW files will have a sidecar file.
    edits/rank/label will travel, but snapshots/virtual copies and collections will not.

  3. Very interesting podcast indeed. Since your blog carries ‘workarounds’ in its title, can you tell me how to solve the laptop/desktop-problem? I used to transfer shoots with photobinders when I worked on location. But now I have no Idea how to import the new pictures including the library changes (for example I’ve chosen shots on location toghether with my client).

  4. An excellent podcast, I need to listen to it a second time.

    I fully agree there needs to be more flexibility and power built into Import. I’ve been trying to get someone to join my crusade for import presets just like export presets. I digress.

    LR (team and product) seems to have taken the “get it into LR, then work on it”, rather than import it properly and minimize the after work in lightroom. This seems to have been most clearly demarcted after shoots went away in terms of folders. There was, as you point out, more power importing when we had shoots. Not that I want shoots back, I’m very happy the way folders and collections work.

  5. The podcast was quite interesting.

    I am fascinated by what Michael J thinks about the progress of LR and how he is integrating with the Adobe team. Would be great if George did an idividual interview with him post V1. From the little that I have heard from him in various interviews, he seems to really know his stuff and his straight talk about problems is refreshing.

    I’m glad George mentioned Michael’s statement regarding the need for performance improvements.

    Other interesting possible developments for me are dodge/burn tool and better watch folder function or auto update.

    It seems that the team are in touch with what is going on in the forums. This whole style of development is really quite interesting and is working well. Can’t wait to see what they have fixed/added for the next release.

    Kevkevyong

  6. johnbeardy,
    I have to agree with you in most of what you say. For initial speed Lightroom needs to use embedded previews and initiate a preview build when Develop is invoked. I’d even go so far as to suggest that QD initially works on this embedded preview. We could take care of how it works with an … option.
    I think there is enough going on in Import to justify a module. After all card import is an inherent part of digital workflow. Greater control of initial keywording and metadata stamping is needed. Imagine also being able to get a quick look at what the develop setting you are choosing does PRIOR to importing (just on the embedded preview). While it’s only a bit of a pipe dream I think it would certainly aid in my workflow.

  7. Sean, if you’re talking about a separate module then you are talking about something very different from what I imagined you were saying. But I don’t know what it is about Adobe – even if they did introduce your Import browser module, they’d find some excuse to do their own rendition and slow you down just like Bridge or in LR. Why can’t they ever just let you browse with the speed of Photo Mechanic or BreezeBrowser?

    A lot depends on the camera. Quite a few do have large embedded previews that Adobe should extract and simply store. I don’t suggest doing any editing adjustments on them (Develop might initiate standard preview build), but mainly just allowing you to get the pictures into Library so you begin selection and initial metadata entry. You can then build standard previews later. Effectively it’s very similar to your idea of an Import module, but using the existing Library interface with its access to metadata entry.
    Once you’ve got them, the extracted previews should be stored for reference – eg in Before/After view for example. One use might be if you shoot digital b&w;, or apply some other proprietary setting in camera, and can use the camera’s output to match that in LR. But the argument applies more to DNGs – why does LR waste any processing time building its own previews when perfectly good ones are available in the DNG?

  8. John,
    I beg to differ. With a well designed interface (imagine if you will that import was a module, say) then it would be very usable. Imagine that when we run an import, Lightroom shows us the embedded jpg at screen resolution. Wouldn’t it be much easier to tag imports from there? This would mean a slimmer Library and not wasting time in the deletion process.

    Re Camera rendition: As Lightroom has no way of knowing what any camera has in the JPEG settings, I don’t imagine we’ll see anything even remotely like a camera rendition of an image anytime soon.
    Usually the internal preview jpg is quite small and wouldn’t be much use for most things (except maybe email and previews). The other issue with it is in apply your settings. The RAW and the jpg would require different processing. Obviously spotting and cropping would be the same, but colour based changes would be different. I would like Lightroom to be able to export the embedded preview, but it’s not anything remotely important.
    Just a note on the ‘LR-Edited’ version: we are seeing a lot of people emulating in camera settings with develop presets. While not 100% similar, they get close and this may be the way forward for the embedded look. However they have to be set manually by the user (not the program).

  9. I don’t really agree with your point about Import. Aperture has something like that, but you end up with a half-baked preview environment that’s not as good an evaluation tool as the full application window. I would rather the team focus on massively speeding up the import process – for instance, using built in previews and delaying the Adobization process. This would have additional benefits later in the workflow – for Nikon users, wouldn’t it be cool to be able to switch in LR to the camera’s rendition (or one added by Nikon Capture) and compare that with the LR-edited version?

  10. I think you really have zeroed in on the main difficulty with Lightroom, that is that the driving principle, particularly from Mark H., is simplicity. But simplicity means doing things one way, and that is the designers’ way. Hopefully things will open up a bit.

Leave a Reply

Your email address will not be published. Required fields are marked *