Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Mark_Seng on May 05, 2015, 02:54:14 am
-
With the large files of the sony a7r, adobe camera raw got a bit slow on my mac - especially when zooming in the photo. (photoshop cc, acr 9)
Today I opened an a7r file with photoshop cs5, acr 6.6. Surprisingly it worked way faster, especially zooming...
Is acr 6 really faster than 9? Is there something I can do to make acr 9 as fast (change presets in photoshop?)
-
Is acr 6 really faster than 9? Is there something I can do to make acr 9 as fast (change presets in photoshop?)
wait for ACR9.5/LR6.5, it will take a lot of time for Adobe to fix the code to use GPU in a proper manner... I wonder what was the feedback from beta-testers and what arguments marketing plankton had with developers when the decision to release was made.
-
Yes, it seems like there is a problem with the graphic card.
I just checked the preferences in acr and found this: "Graphic Processor- Currently disabled due to an error (Unsupported hardware/driver version)."
-
How many cards are on the market? It must be difficult for Adobe to test for all especially if someone doesn't use use the latest driver.
-
Yes, it seems like there is a problem with the graphic card.
I just checked the preferences in acr and found this: "Graphic Processor- Currently disabled due to an error (Unsupported hardware/driver version)."
no, that is not the core problem - the core problem that even with supported GPU/drivers the performance is horrible vs what it should be, based on how some other GPU enabled applications are doing...
-
no, that is not the core problem - the core problem that even with supported GPU/drivers the performance is horrible vs what it should be, based on how some other GPU enabled applications are doing...
That is not my observation. I am using a 2560x1660 screen, with 2560x1440 second screen.
Develop slider w/o GPU has the sliders slightly herky jerky. With the GPU the sliders are smooth as silk. Second screen does not seem to add a noticeable difference to there is a slight delay on image change...first screen has no delay at all.
I am using an EVGA GTX 760 Superclocked video card, with i7-4770 and Win7.
Eric gives some guidance on GPU needs in this thread. http://feedback.photoshop.com/photoshop_family/topics/about-lr-cc-and-gpu
-
Hmm....still don`t know why my CS5 ACR 6.6 runs faster than CC ACR 9.
I`m using a Intel HD Graphics 3000 512 MB. As far as i know it should work with Photoshop CC.
But even when GPU "turned off" it should be as fast as CS5 ACR 6.6. Or am I wrong?
-
Hmm....still don`t know why my CS5 ACR 6.6 runs faster than CC ACR 9.
I`m using a Intel HD Graphics 3000 512 MB. As far as i know it should work with Photoshop CC.
But even when GPU "turned off" it should be as fast as CS5 ACR 6.6. Or am I wrong?
because Adobe managed to make things worse speedwise without GPU too ;D ... and your GPU really quite old, might not see any gains even in proper code (try software like fastrawviewer - an example of the code done right)
-
That is not my observation. I am using a 2560x1660 screen, with 2560x1440 second screen.
Develop slider w/o GPU has the sliders slightly herky jerky. With the GPU the sliders are smooth as silk. Second screen does not seem to add a noticeable difference to there is a slight delay on image change...first screen has no delay at all.
I am using an EVGA GTX 760 Superclocked video card, with i7-4770 and Win7.
Eric gives some guidance on GPU needs in this thread. http://feedback.photoshop.com/photoshop_family/topics/about-lr-cc-and-gpu
been there... do a simple exercise - open raw with GPU on, zoom in, zoom out, zoom in, zoom out (no sliders)... you see the delay and image being blurred during those steps... now get fastrawviewer - do the same... compare the speed of a simple operation.
as for Eric - he is doing damage control because the mgmt pushed the release before it's ready codewise, so we shall feel sorry for his situation, I bet he was not the one rallying to release it
-
been there... do a simple exercise - open raw with GPU on, zoom in, zoom out, zoom in, zoom out (no sliders)... you see the delay and image being blurred during those steps... now get fastrawviewer - do the same... compare the speed of a simple operation.
Split second response
as for Eric - he is doing damage control because the mgmt pushed the release before it's ready codewise, so we shall feel sorry for his situation, I bet he was not the one rallying to release it
I doubt Eric would release code that was not working properly. He did leave out support for some items, which he clearly stated were the result of time/resource constraints. This is normal in any development management/scheduling operation....it is the reason you do not preannounce because things happen and you don't want to promise a feature which may have to be temporarily dropped as it is either incomplete or not fully tested.
-
I doubt Eric would release code that was not working properly.
it is simply not his call - he is a developer, sr one, but not a manager...
-
Split second response
and on my PC (GTX870m GPU) that "split" second is way, way longer than FRV ;-) and that is with one 2560x1440 screen...
so are you going to argue that GPU code works as it should ;D ? or that GPU in my notebook is obsolete ?
-
okay, not sure what to do now.
I can`t work this way, the delay while zooming is driving me crazy.
I`m working on a macbookpro and an eizo monitor. (2,4 i5, 10.10.3, 16gb ram, SSD, Intel HD Graphics 3000 512mb)
Apple website says that the intel hd 3000 supports opengl 3.3.
As far as i know this is the only requirement for ACR 9 in terms of GPU?!
So the problem is ACR9 not the intel hd 300. Am I right?
So do you think its worth waiting for acr 9.5?
-
and on my PC (GTX870m GPU) that "split" second is way, way longer than FRV ;-) and that is with one 2560x1440 screen...
so are you going to argue that GPU code works as it should ;D ? or that GPU in my notebook is obsolete ?
I was not making any argument, just reporting my observations. However, it should be obvious that LR performance, w/ or w/o GPU, will be highly dependent on the hardware it is running on.
In the case of a laptop, a lot of performance trade offs are made to get the best with least heat. CPUs are usually 2 core rather than 4 or 6and clocked conservatively.
The GTX 760 I mentioned has a Passmark benchmark number of 4965 (and this is NOT superclocked, which would be faster). The GTX 870M is 2357.
In addition, my system has SSDs for OS, LR catalog, and raw cache.
-
Mark, should have quoted your post
okay, not sure what to do now.
I can`t work this way, the delay while zooming is driving me crazy.
I`m working on a macbookpro and an eizo monitor. (2,4 i5, 10.10.3, 16gb ram, SSD, Intel HD Graphics 3000 512mb)
Apple website says that the intel hd 3000 supports opengl 3.3.
As far as i know this is the only requirement for ACR 9 in terms of GPU?!
So the problem is ACR9 not the intel hd 300. Am I right?
So do you think its worth waiting for acr 9.5?
If I remember correctly, Adobe stated the minimum GPU support was 1GB on video card, with 2GB preferred.
Also, Passmark performance number for HD 3000 is 309.
-
it is simply not his call - he is a developer, sr one, but not a manager...
I'm not sure what "call" you mean, but I suspect you have never been involved in a large development organization.
There is always a trade off on timing of announcements and readiness, but no shop will release a product that the know is not ready. It will only cause them more problems down the road. The usual trade off is made to reduce those parts that are not ready...but that has to be balance against improved features.
That does not mean that products will not experience problems after release. No matter how much one tests, one cannot possibly test all the permutations of hardware, software, and update combinations are out there.
-
I was not making any argument, just reporting my observations. However, it should be obvious that LR performance, w/ or w/o GPU, will be highly dependent on the hardware it is running on.
In the case of a laptop, a lot of performance trade offs are made to get the best with least heat. CPUs are usually 2 core rather than 4 or 6and clocked conservatively.
The GTX 760 I mentioned has a Passmark benchmark number of 4965 (and this is NOT superclocked, which would be faster). The GTX 870M is 2357.
In addition, my system has SSDs for OS, LR catalog, and raw cache.
I can compare ACR with FastRawViewer on the same notebook hardware (GTX870M GPU, i7-4810MQ CPU, 32GB RAM)... no contest with zoom in zoom out... if we call ACR a fraction of second (noticeable fraction btw), FRV is milliseconds - at least 10 times faster, same raw... SSD has nothing to do with that - we are operating on the same one raw file which is totally read in already we simply zooming in and out it, w/o changing anything else... you are compensating for the bad code with more hardware raw power, but that does not make release any better !
-
There is always a trade off on timing of announcements and readiness, but no shop will release a product that the know is not ready.
you are simply so naive ... the devil is the details of what you call "ready", it seems that you define "ready" as when software does not crash on you and yes it doesn't - but just read the forums and feedback about the performance on a simple operations... that is another definition of "ready"...
-
I can compare ACR with FastRawViewer on the same notebook hardware (GTX870M GPU, i7-4810MQ CPU, 32GB RAM)... no contest with zoom in zoom out... if we call ACR a fraction of second (noticeable fraction btw), FRV is milliseconds - at least 10 times faster, same raw... SSD has nothing to do with that - we are operating on the same one raw file which is totally read in already we simply zooming in and out it, w/o changing anything else... you are compensating for the bad code with more hardware raw power, but that does not make release any better !
You are comparing apples and oranges.
If you like FRV, fine.
BTW....are you comparing the image to image or zoom in/out of the develop module (which is where the new code is) or in the library module? Isn't FRV closer to the library.....I don't think it allows raw processing, other than viewing.....if it does, $15 is a great deal for a raw converter. 😀
-
you are simply so naive ... the devil is the details of what you call "ready", it seems that you define "ready" as when software does not crash on you and yes it doesn't - but just read the forums and feedback about the performance on a simple operations... that is another definition of "ready"...
Are you talking about performance problems with slow GPUs?
-
Are you talking about performance problems with slow GPUs?
no, my GPU is not slow, dear... the mere fact that yours is faster does not make my slow - for example the best GPU-wise MacBookPro has GT 750M = http://gpuboss.com/gpus/GeForce-GTX-870M-vs-GeForce-GT-750M vs my notebook GPU... so your point was what ?
PS: about big organization and releases ("... but no shop will release a product that the know is not ready....") - you know what happened with HealthCare.gov when it launched ;) ? and it was not developed by a small mom&pop shop like LuLa was...
-
no, my GPU is not slow, dear... the mere fact that yours is faster does not make my slow - for example the best GPU-wise MacBookPro has GT 750M = http://gpuboss.com/gpus/GeForce-GTX-870M-vs-GeForce-GT-750M vs my notebook GPU... so your point was what ?
PS: about big organization and releases ("... but no shop will release a product that the know is not ready....") - you know what happened with HealthCare.gov when it launched ;) ? and it was not developed by a small mom&pop shop like LuLa was...
My point was.....
- your GPU is slow. Eric was clear that current (~2 years) 700 or 900 series GPU was required. "M" versions were not included in his statement.....they are lower performance laptop models....slowed down to reduce heat.
- more than the GPU enters into overall performance, as I am sure you are aware. All the other components are involved. Laptops are not speed demons nor are spinning 2.5" disks.
- I am sure you are aware that healthcare.gov was a last minute crash project due to the unexpected actions of many states. You cannot compare that to a planned project like LR 6.
- naive?? What is your experience in large company product and development management? I suspect little.
- if Adobe is guilty of anything, I believe it may be in not setting proper expectations of where and on what hardware the value of the GPU code would bring immediate results. Eric has tried to clarify some of that. I suspect that the base they are building will be currently valuable to people who now have the hardware to support it, but more importantly, will be value able to many as higher performance systems, including laptops, roll out over the next few years.
-
You are comparing apples and oranges.
If you like FRV, fine.
BTW....are you comparing the image to image or zoom in/out of the develop module (which is where the new code is) or in the library module? Isn't FRV closer to the library.....I don't think it allows raw processing, other than viewing.....if it does, $15 is a great deal for a raw converter. 😀
FRV is not a raw converter. There is a clue in the name. fast raw VIEWER.
-
FRV is not a raw converter. There is a clue in the name. fast raw VIEWER.
I understood that, which is why I said you were comparing apples and oranges.
BTW...I am not saying FRV doesn't have value. It has gotten good reviews and was written by the guys who did RawDigger. Personally, it would not fit into my current workflow, which is to import into LR before doing any image culling or selection. Once imported into the LR database, XMP updates should be made in LR.
-
no, that is not the core problem - the core problem that even with supported GPU/drivers the performance is horrible vs what it should be, based on how some other GPU enabled applications are doing...
I actually have pretty darned good Lr performance, even with a 4K screen; certainly usable.
However, I found that AutoPano demanded a graphic upgrade:
I upgraded my display to an NEC PA322UHD 4K one. AutoPano Giga 4.0 became painfully slow, especially the editing window. I downsized the window and that helped, but not much. Then, to get 60Hz refresh on my new monitor, I upgraded the graphics adapter from an AMD V4900 to an AMD W5000. Then I tried to stitch again. What a difference! It’s now much faster than it was before going to the 4K display. This is not a super high end GPU, but it sure makes a difference!
Configuration: Win 7 x64, 2x Hexcore Xeons @ 3.33 GHz, 256GB RAM, 192 GB used by OS, 128 GB used by AutoPano. W5000: 2 GB, GDDR5, 800MHz memory clock. This is a workstation-grade configuration.
Jim
-
I actually have pretty darned good Lr performance, even with a 4K screen; certainly usable.
again - there is a difference between "usable" and how it should be, I always call to compare with FRV on a regular notebook that a photographer might be using as an example how fast the code can work when done properly (that is not when it is not rushed to be released by a certain date)
-
FRV is not a raw converter. There is a clue in the name. fast raw VIEWER.
dear, dear... first of all to display the image FRV does raw conversion (did you ever try to think what raw conversion actually is ? do you really think that FRV is displaying an undemosaicked, non whitebalanced image and w/o color transforms applied...) and then I am talking about a simple zoom in/zoom out of the data post raw conversion in both cases... just try to think a little bit... not about speed of demosaick - just about a very simple thing - zoom in/zoom out of the image which is already rendered (so no time is actually necessary to rerender the whole thing - just scale up or down)
-
My point was.....
- your GPU is slow. Eric was clear that current (~2 years) 700 or 900 series GPU was required. "M" versions were not included in his statement.....they are lower performance laptop models....slowed down to reduce heat.
poor Eric is doing a damage control in forums instead of the people who forced the release, that's it... I am running ACR, C1, FRV to name a few on the same hardware and I can clearly see the difference in simple operations between ACR and what PhaseOne many developers or _just one_ coder in FRV case can do... ACR/LR GPU code is simply not done yet as it can be done ;D ... more so along the way Adobe managed to slow down operations with GPU off too... so the slogan of the day is (according to your interpretation of what Eric allegedly tries to say) - "dear photograpers, your new shiny MacbookPros in their best configurations are no good and never will be to run our LR/ACR, sorry... please ask Apple to shove desktop grade GPUs inside their tiny shells ;D ;D ;D:
- I am sure you are aware that healthcare.gov was a last minute crash project due to the unexpected actions of many states. You cannot compare that to a planned project like LR 6.
I am referring to some clueless generalizations about "... but no shop will release a product that the know is not ready...." (c) one great expert ...
- naive?? What is your experience in large company product and development management? I suspect little.
I suspect that the above says that your certainly miniscule... or you can consider a lesser fiascos like MS Vista ... you again simple fail to comprehend that "not ready" is not the same as "100% BSOD"
-
dear, dear... first of all to display the image FRV does raw conversion (did you ever try to think what raw conversion actually is ? do you really think that FRV is displaying an undemosaicked, non whitebalanced image and w/o color transforms applied...) and then I am talking about a simple zoom in/zoom out of the data post raw conversion in both cases... just try to think a little bit... not about speed of demosaick - just about a very simple thing - zoom in/zoom out of the image which is already rendered (so no time is actually necessary to rerender the whole thing - just scale up or down)
The library module does not "re render".
The develop module does as it needs to include any possible changes that may have been made to the sliders. Using DNG or SSD on raw cache will speed that up.
I assumed you were talking about the develop module as you were complaining about the new code. That is why the apples to oranges comment.
-
dear, dear... first of all to display the image FRV does raw conversion (did you ever try to think what raw conversion actually is ? do you really think that FRV is displaying an undemosaicked, non whitebalanced image and w/o color transforms applied...) and then I am talking about a simple zoom in/zoom out of the data post raw conversion in both cases... just try to think a little bit... not about speed of demosaick - just about a very simple thing - zoom in/zoom out of the image which is already rendered (so no time is actually necessary to rerender the whole thing - just scale up or down)
I think you are being obtuse and you know fine well what I mean. The image doesn't get converted to TIFF, jpeg of DNG. If you open an image in FR no changes are permanently made to the image when it is closed. :(