– Viewing a variety of multimedia formats in a simple and attractive environment I offered a suggestion above (suppressing rendering) that helps some people because it brings Bridge more in line with how other file browsers work, but very aware that it isn’t a solution for everyone depending on what they need to do.Features and Specification of Adobe Bridge software : We can certainly switch to that topic if that’s what you meant. If you’re now discussing the raw editing aspect of DPP (the equivalent of Adobe Camera Raw), that’s a different discussion because what affects performance there is different than Bridge folder previewing. That is why I wasn’t discussing how fast DPP edits individual images. ![]() I assumed our discussion here is about how quickly/slowly it takes Bridge to preview thumbnails for photos in a folder, not edit individual images. That is precisely why I said it shares the same raw processing engine that their cameras use. I am very aware that DPP is Canon’s desktop raw processor. Remember that the applications that simply display built-in previews would not be an accurate comparison - they have to be applications that have their own raw processor and can preview a folder of images as rendered by that raw processor. I haven’t tried all the raw processors/organizers out there, so I would welcome suggestions of any you know of that render a folder of raw files significantly faster than what Adobe has, and would really like to know about any that render a raw preview as fast as a camera does, if you know of one. The new Apple Silicon processors are showing us that further performance optimization is possible than what we take for granted on x86, but even that probably won’t be as fast as a camera’s specialized silicon. Computer processors are more generalized so that they can be a jack-of-all-trades, but that naturally means they are a master of none. Unfortunately that means those Camera Raw previews have to be built if they don’t already exist.Īs for the speed of cameras, they have extremely specialized, custom-designed processors that are highly optimized for that camera’s format and power envelope. Therefore it’s preferable to see a Camera Raw-generated preview for all of the raw files, and that’s why Adobe defaults to generating previews for every raw file in a folder based on the current Camera Raw settings for each image. Then it will show you the built-in previews like simpler applications do, and it will be fast.īut if you are viewing files in Bridge with the intention of editing them in Camera Raw, then the camera’s built-in preview isn’t of much use because it’s going to look different coming out of Camera Raw. If you want to equal that performance, just tell Bridge not to render previews. Photos display fast in a lot of other applications (like the desktop or simple file browsers) because all they have to do is show the preview built into the files they do not have their own rendering engine. And that making appropriate adjustments is acceptable for some people, those who are OK with not seeing an Adobe Camera Raw version of each raw file right away. All I’m saying is that adjusting the preview settings in Bridge can lower CPU/GPU usage upon displaying the contents of a folder. Everyone hates waiting for raw previews, me included. No, I never said that the current performance is ideal. Or if the previews are set to display size, 200 previews for a new 4K display are much more intensive to generate than for a 1080p display. 200 1:1 previews of 36-megapixel raw images are much more intensive to generate than for 12-megapixel images. This issue may have gotten worse lately because sensor and display resolutions have gone up. Lightroom Classic has similar behavior which causes similar complaints, and there too I prevent CPU/GPU issues by having it use embedded previews first and not render previews until I ask it to. If changing the Bridge preview generation settings help, then this isn’t a bug. If Bridge is pointed to a folder containing 200 items it will start rendering previews for those 200 items, and the computer will be busy until 200 previews are done. They view whole folders, and that is why this can be so processor intensive. ![]() You say “without opening an image” but Bridge and other file browsers don’t “open” images to edit them (except when you open an image in Camera Raw). But by changing settings, you can set Bridge to use low-quality previews first, and defer processor-intensive high-quality preview rendering until an item is selected, or on demand only. It’s based on the idea that high CPU/GPU usage might be because Bridge builds high-quality previews of all items in a folder as soon as you view that folder. ![]() See if my response in another thread helps (see link below).Īdobe bridge 2021 mac version causes very heavy GPU load on activity monitor
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |