Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Exit
Todd Shaner
LEGEND
Todd Shaner
LEGEND
Activity
Nov 13, 2012
03:43 AM
Much appreciated, thank you. There is a known issue with processor core and hyper-threading utilization on Mac OSX platforms and some Win 7 platforms. It appears to be related to the specific processor used, with high performance quad-core and six-core processors the most prevalent. My modest i7-860 quad-core system with a single 1920 x 1080 display works flawlessly with no lag or speed issues. High display resolution such as 2560 x 1600 and Mac Retina displays are also known to make LR sluggish. The current solution for this is to use a smaller Loupe view by dragging the side and/or top and bottom panels to make the image smaller.
... View more
Nov 13, 2012
03:08 AM
bmphotography wrote: I have treid LR 4.3 on big mac + MBP and still have the issue. Not yet checked win LR 4.3 but no reason yet to assume its different. As I said at least one LR forum member here has stated there is better processor utilization on Win 7. Since you are experiencing issues on both platforms it would be very helpful if you also tried LR4.3 RC on your Win 7 system and let us (and Adobe) know your results.....for better or worse...or nothing. http://forums.adobe.com/message/4837109#4837109 Thanks!
... View more
Nov 11, 2012
06:25 AM
bmphotography wrote: Well I have tried pretty much everything from a hardware standpoint. Played with RAM latencies, spent money on better RAM, spent money on better cooler to OC higher. Spent money an SSD. Nothing. Tried a clean install on a clean OS both Win 7 and Mountain Lion As soon as I start using the noise sliders it all just turns to glue. Have you tried LR4.3 RC on both your Win 7 and Mountain Lion OSX Mac system? Their is no mention of "speed issues" under LR4.3 RC Bugs Corrected, but at least one forum member here has stated it provides better processor utilization on Win 7. http://labs.adobe.com/technologies/lightroom4-3/ Adobe provides release candidates so users with problems can test them and see if it resolves their issues. Adobe also request you share your feedback in this forum concerning your results.
... View more
Nov 09, 2012
06:41 AM
Rob Cole wrote: Lr4.3RC any better? PS - Has anybody in New Jersey or Portland taken trshaner or Brett N up on their offers? No PMs to date, but the NY, NJ, PA tri-state area has been hit pretty hard by Hurricane Sandy. My power and Internet connection went out on Oct. 28th and finally was restored last night. It's been like a 'War Zone' along most of the Jersey Shore, but I'm back up and running with no major issues or complaints.
... View more
Oct 27, 2012
03:20 PM
Bob_Peters wrote: Unfortunately, that switch when viewing at 1:1 (all 1:1 previews generated prior to any measurements) takes more than twice as long in the Library module. How long does the switch take in the Library when you are viewing at 1:1? When switching images on my system at 1:1 view in the library module with 1:1 previews rebuilt takes less than .5 sec. To insure this happens you need to update ALL images that have been modified during an editing session. This can be accomplished by selecting all of the images you have just edited (or all of the images in the folder) and go to Library> Previews> Render 1:1 (ALT + L, V, P). Previews will only update for the images you have edited, so no worries about selecting all of the files and having LR go crazy.
... View more
Oct 27, 2012
03:01 PM
bob frost wrote: From doing a lot of reading and with my experience with Win7x64, hyperthreading seems to be more of a marketing exercise than a performance improvement! My 6 core i3930K runs faster and cooler with hyperthreading off for everything. The virtual cores are not real cores, but just 6 extra queues for the 6 real cores. They might save a little time when the 6 cores have a slack moment, but some programs simply don't like them, and a lot of people in the past have recommended turning HT off. As I said, my cpu runs several degrees cooler and no slower with HT off all the time. It is not a 'must have' feature! That may be the case for six-core and higher core-count systems, but not so with my i7-860 quad core system running LR4 on Windows 7: http://forums.adobe.com/message/4661813#4661813 Excerpt from above post: "To verify how much hyper-threading helps LR4 I ran benchmarks with hyper-threading enabled and disabled. Interestingly the benchmarks were almost identical, but LR lost its responsiveness in both the Develop and Library modules when 1:1 previews were being built or images were being exported. With hyper-threading enabled all eight threads never reached 100% utilization (see above screenshot). With hyper-threading disabled utilization rose to near 100% for all four cores during 1:1 preview building and during exports. This may be one (1) of the reasons why LR becomes sluggish on systems without hyper-threading." Message was edited by: trshaner -
Added quoted text by Bob Frost.
... View more
Oct 27, 2012
11:29 AM
I have to say that it sounds like your LR4.2 system is performing quite well, but I guess everything is relative. What one LR users considers "sluggish" may be perfectly acceptable to another. I also noticed that the LR4 initial launch and "first use" of the develop module take much longer than LR3. Since I only do this once a day I'd hardly call that a huge annoyance. Windows 7 takes longer to "fully" launch on my system and that is annoying, since I shutdown my system every night. Switching between images in the Develop module is going to be slower because it has to rebuild the screen image using the current develop settings. The Camera Raw cache speeds up things and is created the first time you open an image in the Develop module. The actual time required is determined primarily by the resolution of your display, with a 2560 x 1600 display taking twice as long as a 1920 x 1080 display (4Mp vs 2Mp). In the Library module switching between images should be instantaneous, at least after 1:1 previews have been built. I do most of my reviewing and "browsing" of image files in the Library module for that reason. On my system it takes 1 to 2 sec. to fully build the screen image in the Develop module at 'Fit' view with a 1920 x1080 display. What are you seeing and what display(s) are you using?
... View more
Oct 27, 2012
08:26 AM
What's interesting about hyper-threading is that some LR users (both Mac & Windows) with the same systems are experiencing very different behavior. There are many people at this post Experiencing performance related issues in Lightroom 4.x with high-end six-core i7 desktop and Xeon server processor based systems who are finding LR4 "barely usable," and some also have SSDs. The solution suggested was to turn-off hyper-threading to make the LR sliders more responsive, especially noise reduction sliders. Of course this is at the expense of making everything else run slower. The OP here (Sebasvideo) has hyper-threading enabled on a six-core i7 Windows 7 system that appears to be running extremely well. Sebasvideo, are you experiencing sluggishness with any of the Develop module sliders?
... View more
Oct 27, 2012
06:39 AM
Bob_Peters wrote: When you are exporting images how much activity, if any, are you seeing on the virtual cores? I don't see any. Same question for jim01403. I think this is a know issue with certain Mac systems. Perhaps it is also an issue with certain "high-end" processors also running on Windows systems? http://feedback.photoshop.com/photoshop_family/topics/very_poor_perfromance_on_high_end_system_partial_solution_discovered
... View more
Oct 26, 2012
03:58 PM
I totally agree and see Export times ranging from 5 sec. up to 30 sec. for 21Mp 5D MKII CR2 images, depending on how many Devlope module tools (spot removal, adjustment brush, graduated filter, etc.) have been used on the image. With just the Basic, Detail, and Lens Corrections tools applied it's typically in the range of 5-6 sec.
... View more
Oct 26, 2012
11:44 AM
If you're averaging about two seconds per image on Export that sounds about right, regardless of the what the CPU utilization is showing. SSDs help a bit, but exports are mostly processor bound. Passmark Benchmarks: i7-860 5,224 i7-3930k 11,925 5,224/11,925 x 5 sec. (my Export time) = 2.2 sec. What's your processor utilization on raw Imports during preview building, and how long does it take to build a 1:1 preview? That to me is abigger issue. If your running close to 100% processor utilization during any LR process than the system is pretty much useless for anything else. I can start working in the develop module during 1:1 preview building with very little slow down or slider lag, but not during Exports.
... View more
Oct 26, 2012
03:57 AM
My LR4.2 Windows 7 64 bit i7-860 quad core processor system peaks at 100% on all eight threads running a single export with JPEG, convert to sRGB, and limit of 7000KB. The below screenshot is with Canon T3i CR2 files same 5,184 x 3,456 resolution as yours. It took 25 secs. to export five images. Your i7-3930k has more than 2x the performance of my CPU, so it should be less than 5.0 sec per file export. http://www.cpubenchmark.net/high_end_cpus.html Try unchecking 'Limit File Size' and use the 'Quality' setting to control the file's size. Message was edited by: trshaner
Corrected camera model.
... View more
Oct 25, 2012
04:55 PM
uphotography wrote: Geoff the kiwi wrote: Certainly not an endorsed method which I would strongly not recommend. Modules aren't loaded until used. And this would be my reason why sometimes I want Adobe to speak out instead of letting us all try to help each other. There are many people here that know enough as to offer sound advice, but there are also people like me than when desparate will try "anything" sometimes leading us to unforseen risks. That is why we LR forum members as a community of professionals, semi-professionals, and amateurs must all hang together, or assuredly we shall all hang separately. Benjamin Franklin July 4, 1776 Let's look at the stats for this post: Views Replies Experiencing performance related issues in Lightroom 4.x 217,116 1,464 We have 217,116 views and only 1,464 replies, or a 148 to 1 ratio. The ratio for most posts is much lower, except for those concerning LR4 issues. There's no doubt LR4 performance posts are a highly “viewed” topic, but with much less input from the "viewers." Most customers fall into three category rankings: 1 – Customers that love the product (Exceeds Expectations) 2 – Customers that like the product (Meets Expectations) 3 – Customers that have issues with the product (Below Expectations). As you’ve probably already guessed #1 and #3 rank customers provide the most feedback (i.e. Replies) and the majority of #2 rank customers remain silent (i.e. Views only). For every #1 or #3 ranked LR customer there are roughly 148 #2 rank customers, meaning about 99% (147/148) of the total LR customer base is mostly “satisfied,” and less than 1% (1/148) is dissatisfied with LR4. I’ll grant you this is a simplistic analysis, but it would be a stretch to say the margin of error in this sampling is more than 5x or even 10x. It’s also probably safe to assume that 50% of the LR viewers replying on this post are #3 category and the other 50% fall into categories #1 or #2. This would mean the actual number of LR users with significant performance issues is probably no more than 1.7% to 3.3%. From a LR end-user perspective this is still totally unacceptable, since in most cases LR4 is virtually unusable. If the above stats are anywhere near accurate don’t expect Adobe to “throw the kitchen sink” at finding and correcting the code in LR4 that is at the root of these performance issues. We stand a better chance of doing that here on an individual basis. Putting Titanium in a Swiss Army Knife because some customers are breaking the blades is bad product management. As "unacceptable" as that may seem it is the reality of business economics. If we can’t help you find a solution the Bridge/ACR/Photoshop route seems like a viable alternative, especially if you don’t need the other modules in LR.
... View more
Oct 24, 2012
05:18 PM
uphotography wrote: I give you more examples. One of the suggestions (and solutions to some) is to unplug colour calibrators (especially if they do constant ambient light monitoring). But, hold on a second, we are talking about a software built and made for professional photographers that cannot work with basic and well known photographers hardware? What is next? Sorry, LR cannot read anything but DNG and PSD? I mean, I could understand maybe needing to unplug my phone, but my calibrator? my printer or scanner? Seriously? That was me and I'm sitting at my Windows 7 system with LR4.2 and an i1 Display 2 calibrator plugged in and monitoring and measuring ambient light. Guess what? LR is running just fine, no performance issues, no lockups, and no issues opening images in the Library or Develop module like this OP: http://forums.adobe.com/message/4670182#4670182 The solution in the above post was to disconnect the USB i1 Display 2 calibrator. So why don't I have the same problem when using the same exact calibrator, with the same exact software, performing the same exact function? I've tried like heck to make it misbehave importing images, closing LR, opening LR, adjusting images, import more images, measure the ambient light a few more times, and then repeating everything all over. So what's different about o2Gallop's system or LR usage? I have no freak'n idea and I'm pretty good at pushing systems to their limits. Dennis Smith mentioned he would love the opportunity to get his hands on a misbehaving LR4 system and likewise. I have 45 years of system design engineering experience, just retired with lots of time on my hands, and always up for a challenge. Anyone who lives in New Jersey with ANY of these problems send me a private message and let's talk. Now how's that for an offer of technical assistance and Adobe isn't paying me anything!
... View more
Oct 21, 2012
04:58 AM
1 Upvote
At the above link for the grayscale ramp test pattern I stated: Import the above image into LR and observe the Histogram in the Develop module. You will see 21 lines representing the 21 gray scale values from 0%-100% in this image. Adjust each of the Basic panel Tone controls individually to see how they affect the Histogram and Loupe image. Now adjust the four regions in the Tone Curve. Notice that the PV2012 Highlights and Shadows Basic Tone controls work quite differently than their companion Tone Curve controls. The PV2012 Tone Curve works virtually identical to the tone curve in PS. The Highlight and Shadow controls not only modify the tone curve, but add an effect similar to Clarity (micro-contrast). Try adjusting the Tone Curve to -50 Highlights and then compare the histogram to what the Highlights control does at -50. With -50 Highlights notice how the leading edges (R to L) of the lighter grayscale patches are slightly darker than the rest of the patch, making the transition from the lighter patch more pronounced. So in fact you could say that the Highlights and Shadows controls add "edge enhancement," but that is NOT their primary purpose. The PV2012 Basic panel sliders are complicated controls that I'm sure only the Adobe LR team fully understand how they work. I've gained most of my insight by simply using them and from the above 21-step grayscale image. But I will tip my hat to Rob Cole who was instrumental in posting some great PV2012 controls usage tips early on in the LR forums.
... View more
Oct 20, 2012
10:23 AM
Moving the Highlights slider to the left (i.e. minus Highlights) reduces the brightest areas of the image, which is the right most area of the Histogram. In an actual raw image with overexposed highlight areas you will see an increase in edge definition with minus Highlights due to "recovery" of clipped image data that is at 100% RGB. Highlight areas that are not clipped will simply get darker, as you experienced with the downloaded test ramp TIFF file. Since this is a processed TIFF image and NOT a raw file LR doesn't apply a camera profile or any other adjustments. There are no recoverable highlights extending past the right side of the histogram. A typical raw image file has much more dynamic range than what you see when viewing it inside LR with the camera profile and LR defaults applied. Much of the highlights that appear to be 100% clipped are fully recoverable using the -Exposure and and/or -Highlights sliders. RawDigger and Rawnalyze freeware applications allow you to see the raw image and histogram without any processing applied: http://www.rawdigger.com/ You may be surprised to find that many of your raw images in fact have no clipped pixels at all (i.e. no 100% R, no 100% G, or no 100% B). This is also helpful when trying to determine how far you can "overexpose" images during a shoot using the camera histogram. Most cameras use an in-camera processed JPEG for the histogram display, which has much less dynamic range than the raw file. So a lot of the clipping seen in the camera histogram is not in the raw file.
... View more
Oct 16, 2012
11:32 AM
Rob Cole wrote: Way back when: Programmers *did* have the entire machine to themselves. Not only did only one set of code run at a time, but there was *no* code reused from project to project - every project was redone from scratch. And, there was no hardware attached that was not being used. The hardware people pointed their fingers at the software people, and the software people pointed their fingers at the hardware people, but nobody pointed fingers at other software, because there wasn't any. Amen! Been there and done that starting with my first job designing "minicomputer" systems in 1968. But then we only had 64KB of memory and that took up an entire 19" rack cabinet over six-feet tall! The complexity of today's hardware and software systems create exponentially larger challenges, and it will only get more challenging with migration to handheld and cloud based computing. There's no question LR has significant issues for some people. Unfortunately I don't have access to a badly behaving system to investigate these LR issues firsthand. My two-year old i7 quad core Win 7 based system continues to run LR4.2 without any issues.
... View more
Oct 16, 2012
07:46 AM
Here's a similar discussion with a 21 step grayscale test pattern you can download and import into LR: http://forums.adobe.com/message/4602370#4602370
... View more
Sep 23, 2012
07:59 AM
Rob Cole wrote: @trshaner - I think jpegs would have to already be imported separately for that to work, no? Rob you are correct, but the OP didn't specifically state that the JPEGs are not already imported (i.e. 'Treat JPEG files next to raw files as separate photos' checked). Even they aren't imported it looks like it might be easier and "cleaner" to import them, and use an "extended search plugin like Jeffrey Friedl's. Then you don't have the NEF+JPEG file extension label issue. If Adobe adds this capability in a future release orphaned NEF+JPEG extension tags could create a problem using it. Using 'Synchronize Folders' with 'Show Folders in Subfolders' selected the JPEG import should be fairly quick with 'Render Previews' set to 'Minimal.' Rob & Richard keep the suggestions coming, since I don't expect Adobe will add this capability any time soon.
... View more
Sep 22, 2012
04:49 PM
No offense intended, but you said the same thing about LR3.3 in this post: http://forums.adobe.com/thread/776004 Did you ever resolve the issues you were having with LR3.3? If so, what was the solution(s)? If not, then you know that LR4 is only going to be worse. Way more information is required before anyone here in the forums or at Adobe can possibly help you. What kind of image files, what resolution monitor(s), what additional external devices do you have attached, what LR operations are slow, and just how long do they take to complete.
... View more
Sep 22, 2012
12:14 PM
I assume the OP is referring to use of wide gamut monitor with LR, so relevant. If you are printing to a wide gamut inkjet printer (6 or more inks) than using a wide gamut display will be helpful. For web, screen, and printing to standard CMYK 4-ink printers it won't provide much better color accuracy than an sRGB gamut display. With LR4's Soft Proof feature you can get a very accurate onscreen rendering of what the final print output will look like using the target printer and paper profile. Wide gamut displays will not render color properly with most web browsers and other non-color managed applications. Because of this I would also suggest using a dual display setup with one sRGB gamut standard display and a wide gamut display. Also be aware that 10bit/color will provide better rendering of fine gradients on wide gamut displays, but LR currently only supports 8 bit/color display output. Only PS CS4-CS6 support 10bit color display output. You also need to be using a graphics adapter that supports 10/bit color, and one that is compatible with PS. If you don't fully understand the differences between a wide gamut and standard gamut (sRGB) display I suggest doing some research. Also search this forum and the Web for reviews on displays you are considering. There have been numerous issues with calibrating certain model wide gamut displays.
... View more
Sep 22, 2012
06:43 AM
This LR plugin looks like it will let you find raw+JPEG pairs: http://regex.info/blog/lightroom-goodies/extended-search It claims to be LR4 compatible. I haven't used it, but try this search criteria: Find images whose: Leave it blank or select something that will pull up all images (i.e.wildcard). I don't know what's available. JPEG file: Select 'has related JPEG' and 'include related JPEG in search' Once you have all of the files filtered you can review the results. You should be able to sort by 'File extension' to separate JPEGs from raw, and then move them to another folder on your hard drive or simply delete them. Give it a try and let us know if this works for you. Looking at this now I have no idea why Adobe didn't include it as an option in the Filter Bar.
... View more
Sep 21, 2012
03:52 AM
1 Upvote
This might help you: http://www.qandasystem.info/photo/how-to-delete-jpg-files-but-only-if-the-matching-raw-file-exists/ As long as you haven't changed the file raw/JPEG paired file names a script should work. If you have changed naming it just won't delete those JPEG files.
... View more
Sep 14, 2012
09:46 AM
Thanks web-weaver. It looks like this requires that 'Automatically write changes into XMP' be selected, but I don't need or want XMP files. It seems like there should be a preference option for 'Automatically save metadata changes inside JPEG, TIFF, and PSD files. Having this option in addition to the current 'Include Develop settings inside JPEG, TIFF, and PSD files' unchecked should work. LR exported TIFF and JPEG files currently have the metadata (not develop settings) automatically written into the file. CTRL + S keys will do the same thing manually, but I was hoping for a way to have it done automatically. Maybe I'll add it to the Bug Report & Feature Request site. This would be very useful for anyone who needs to use both LR and Adobe Bridge for digital asset management.
... View more
Sep 14, 2012
04:26 AM
Thank you, I agree with all of your responses and I rarely use ACR. The primary reason you would need to select 'Overwrite settings' when you get a metadata changed warning in LR is if you did use both ACR AND LR on a TIF file. I'm not suggesting that as a workflow method. You also might want to 'Overwrite settings' if you've changed the file's metadata and/or keywords externally using Adobe Bridge or another metadata editor. When working with Adobe Creative Suite in a graphic arts or publishing environment Bridge is a much better tool for keeping track of all your material, including camera images, scan images, Illustrator, InDesign, PDF, and many other file types that LR can’t import. So that is part of the dilemma in trying to use both LR and PS or LR and Bridge. That's where Rob Cole's ChangeManager would be helpful and the very point I was trying to convey. I’d rather work a little smarter and prevent the need upfront. What I am doing now is to do all non-destructive editing in LR (not ACR), including keyword and metadata changes. File types that LR can’t import are all edited externally, including metadata. So I have to use both Bridge and LR when searching for project collateral materials. This is where it gets confusing. I can sync TIF and JPEG metadata changes made in Bridge inside LR using 'Overwrite settings. Is there a way to have LR write metadata (not develop settings) to both exported and imported TIF and JPEG files, so that the metadata will also appear in Adobe Bridge?
... View more
Sep 13, 2012
04:49 PM
Thanks, that's what I thought. So LR is just comparing the TIF file's 'Date Modified' field, and then updating the catalog with status 'Up to date' and the new metadata date. If this were a TIF (or other type) file edited in ACR with XMP sidecar (or DNG), then you would have the alternate choice to update the image with the externally changed develop settings, correct. So if editing externally only in PS this will never be the case, which is why it seems redundant. I can see where a preference setting to allow LR to auotmatically update the catalog for this editing scenario would be helpful. No XMP or DNG, then no change to the Develop settings, and LR automatically updates the catalog metadata. Obviously it would be safer NOT to allow this, but then Adobe can place a warning message next to the preferences setting. Am I missing something?
... View more
Sep 13, 2012
03:13 PM
I’m glad to see that I’m not the only one that gets confused by the LR metadata warning. There's another PS/LR/PS editing scenario that I use, which hasn't been mentioned here. All of my film scanning is first processed in PS using TIF, 16 bit/color, Pro Photo RGB image files. I do frame cropping, spot removal, and sometimes add one or more adjustment layers. Next I import the TIF image files into LR and process them similar to camera images, but they are obviously not raw files. Most often I will then go back into PS to do more spot removal and other "destructive" processing. When I return to LR the ‘Metadata was changed externally' arrow is present, but If I select 'Import settings from disk' the arrow does not go away. I have always selected 'Overwrite settings, but it would seem for this PS/LR/PS editing process the warning is not necessary and LR should just retain the current metadata. If I remove the metadata warning or not, the image still looks correct and as expected in both LR and PS. What exactly is changed in the metadata by PS and then by the LR ‘Overwrite settings?’ Yours Truly Confused.
... View more
Sep 13, 2012
04:09 AM
Uphotography it's pretty clear from your video that you have other issues affecting LR's performance, not just display size. That's why I said the following concerning Adobe adding Open GL/CL support to speed display image building: "My guess is it will only happen if/when Adobe decides to do a major rewrite of LR, since we know there are other issues that adding Open GL will not fully correct." I suspect many people with poor LR performance in this thread have two or more issues affecting LR's performance.
... View more
Sep 12, 2012
10:30 AM
Correct, it's dependent on the actual Loupe view window size (Mp) and the performance of your system processor (MIPS). I tested this using my single 1920x1080 display by opening a 'Second Window' using the '2' button in lower left-hand corner with the 2nd window as large as possible (1500 x 1000). This is only about 36% larger than my normal Loupe size (1100 x 733). Develop slider response went from virtually instantaneous to about a 1.0 sec. delay for the 2nd window Loupe (1000x1500). Going from a 1500 x1000 Loupe (~1.5Mp) display to a 30" 2560 x 1600 (~4Mp) display is going to produce at least a 2.7X slower Develop module slider response, or about 2.7 sec. on my system. It could be even worse!
... View more
Sep 12, 2012
05:46 AM
We try to help! I guess I'm fortunate that LR4.1 is running fine on my Win 7 "middle of the road" HP desktop system with a single 1920 x 1080 display. I was going to add a higher resolution display, but won't with the current LR performance issues. So I guess you can add me to the list of LR users who aren't totally happy.
... View more
Copyright © 2024 Adobe. All rights reserved.
AdChoices