Should I match STD preview size to native screen resolution or the resolution I am actually using?

My iMac 27" monitor is 2560 pixels wide but I run it on a screen resolution of 2048 x 1152. Would it be a waste for me to set the Lightroom Standard Preview Size to size to the setting of 2880? I am thinking I should set the Standard Preview Size to 2048 to save space on my hard drive. What do you think?
When I set my monitor to the native resolution the text on menus etc is pretty hard to see with my tired old eyes. Is there a disadvantage to using 2048 x 1152 on my 27" monitor when using Lightroom?

DanATD wrote:
I am thinking I should set the Standard Preview Size to 2048 to save space on my hard drive. What do you think?
If I were you, I'd use Jeffrey Friedl's Online Lightroom Configurator to bump the font-size of the text, and leave the monitor resolution at 2560 (and standard previews at 2880). Unless of course you can't see image detail all that well either with the increased resolution. There may be some text that jf's configurator can't reach - dunno, but it may be worth a shot..
If bumping font size (and monitor rez) doesn't pan out, then the answer is yes: 2048 is sufficient resolution for standard previews, at a monitor rez of 2048.

Similar Messages

For some reason all of my forwards, and my printing come out significantly smaller than the original. Any idea how to get this back to printing the size of my screen and forwarding the size of the original mail I've received? Thanks.

Hi. I am not technically proficient. I have somehow hit something that is making my email forwards and text to the printer way smaller than what is appearing on my screen. I have looked into everything I can think of in settings and outlook express. If you have any ideas, I would greatly appreciate them. I assume that one click and I'll be back to "normal", but can't figure out which darned click that would be. Thanks.

Have you checked Outlook's font preferences? You can change to size under General Preferences>Fonts. You can also change font sizes by using ⌘shift+

Adapt the size of string constants/indicators with the resolution of the screen

Hello,
I al currently working with Labview 2009. I have designed a VI with a resolution 1280x800. When I switch to a higger resolution, my string indicators becomes bigger but the police of the strings stays the same.. It is the same with Texts directly written on the front panel.. Any suggestions?
Thanks a lot,
Kastillio

Hello,
Please take a look on the link below:
http://digital.ni.com/public.nsf/allkb/048C31D73E8EC91286256E440063E1BB?OpenDocument
Regards
Luciano Borges
National Instruments Brazil
Luciano Borges
R&D Engineer
Pirelli Brazil

Bookmarks opens in a window 2/3's the size of my screen since the latest update. Now the first bookmark I scroll over covers the whole window instead of too the side and I can't close it without closing the bookmarks window

I kept getting a reminder I had a Firefox update I needed to install. I did last night but never opened Firefox again till this morning. Now when I click on bookmarks for the drop down it opens a window almost 2/3's the size of my screen instead of the narrow window it has in the past. Now as soon as I move my mouse over or close to any bookmark it opens up that bookmark in the window and I can't access the bookmark I want. I have to close the whole window and then be very careful as I move my mouse to the correct bookmark. In the past with the narrow window it opened the bookmarks to the side and only after you clicked on them. I have tried to resize the window but can't find any option to do so. Also couldn't find an option that would let me change it so a bookmark had to be clicked on. If this can't be changed I will be removing Firefox. This is too inconvenient for me.

Take it to your local Apple Store or AASP, it's covered by a 1 year hardware warranty. If you have AppleCare then give them a call but I'm pretty sure they will advise the same. If you have not purchased AppleCare yet please do, this will extend the warranty to 3 years however it MUST be purchased within the first year of ownership. Let it go 366 days and you are out of luck. AppleCare will also include telephone support too.
Good luck.

Brush preview size does not match brush stroke

The brush preview size does not match brush stroke. I've insert a pic of the problem. I tried allmost everythning, but nothing works.
Does anyone have a solution for this problem?
*I use a wacom tablet.

Is your system cursor size set to something other than normal?
under Apple, System Preferences, Universal Access.

Brush preview size / Size of actual brush stroke do not match?

Hello.
I recently acquired a Macbook Air (2012 version) and it came with CS5 extended preloaded. Everything seems to be working fine, with the exception of these two things:
1. Whenever I select any--that means any--brush and put down a dot or stroke, the width of the stroke is ALWAYS smaller than the preview size for the brush.
With the brush preview size on the left, the dot comes out the size of the dot on the right.
2. The pencil tool has the same exact problem. Also, when I use the pencil tool, the little cross in the middle of the brush preview becomes offset a little bit down and little bit to the right on every even number. (e.g., cross is centered in 3px brush, offset in 4px brush, centered in 5px brush, offset in 6px brush.
I've reset my brush settings multiple times. As far as I can tell, this isn't an issue of any individual brush setting.
As someone who does a lot of pixel art, this has basically brought my work to a full stop. I would greatly appreciate some help.
Cheers.

Which version of mac os x are you using?
Look under System>Preferences>Accessibility>Display and see if the Cursor Size is set to something other than Normal
(you want the Cursor Size set to Normal)

Preview size for at 22 inch monitor?

Hi, I have just read some posts suggesting that changing the pixel dimensions for a specific monitor can help performance as far as rendering images is concerned. I have a 22 inch Samsung monitor, what would be the optimum pixel dimensions. At the moment it is set at default 1440 pixels, should I change it, and if so to 1680 or 2048? I suppose I could experiment, but is there an "optimum"!
As always
Thanks

The standard preview size should be set to match as closely as possible to the resolution at which you use your monitor. Therefore, there was some relevance to the question regarding the native resolution of the monitor as simply stating the size of the monitor does not dictate the resolution at which it operates. In my case, I have a 26 inch monitor, but the important information is that I have it set at its native resolution of 1900x1200. Therefore, I set the standard preview size to the closest resolution without exceeding it, which in this case will be 1680. Note that the standard preview size has nothing to do with any zoom factor as applying any zoom factor, even a 1:1, will quickly exceed the maximum standard preview size available of 2048.
Hope this helps!

Preview size & quality settings

Although I have been using LR for many months I am still confused as to what to set my import settings to when it comes to previews. Standard or 1:1? What quality settings? Can anyone enlighten me on best practices?

>... my import settings to when it comes to previews. Standard or 1:1?
Standard Size previews are of your choosing: 1024, 1440, 1680 and 2048. You set these in the catalog settings "File Handling" tab. Also, you can set the quality to Low, Medium or High. You could also think of the Standard Size as that which most closely matches you screen size.
1:1 Previews are previews that match the dimensions of the image and are generally much larger than the Standard Size previews. e.g. from a 10MP Nikon D200 the size is 3872*2592.
The implications of your choices are as follows:
- The larger the preview size that you choose, the slower the import
- Larger previews take more disc space in your .lrdata folder, specifically the thumbnail-cache file.
If you are going to import a large number of photos, that you may later cull prior to doing any develop work, then you could choose Standard Size previews, with a low (1440) pixel size, Medium Quality. Import should then be fast. After you have eliminated photos that you do not wish to keep, you could use the Library ->Previews -> Render 1:1 Preview, if you wish to generate full-size previews of the selected pictures. Again, this may take a significant amount of time, depending on how many photos you select.
When you go to Develop module, Lightroom will automatically generate a 1:1 preview of the selected photo. So if you are not concerned about a slight delay while Lighroom generates 1:1 preview in Develop module, you could stay with Standard Size previews for import.

Standard Preview size/quality Lightroom 1.1. (how and what)

I'm working on a Macbook pro, with hi-res 17" screen 1920x1200. In most manuals, tutorials etc. it says that you can "set the standard preview size fitting for your screen".
I'm looking for some more background info on the standard preview, to decide which setting to use(if somebody has other criteria to keep in mind please do say so):
1) What is the difference in size of files for the different combination of options (pixel/quality). Does somebody have a list.
2) What is the actual difference in the quality options
3) In which modules is the preview size used (also in development and slide show?)
4) Are they also used to generate the thumbnails from? If so, does a higher standard preview size reduce the performance in library mode because it as to shrink bigger files for these thumbnails?
5) what happens if I would use the smaller, let's say 1440 preview and then decide to view the picture full-size, in library or slide show
6) What would be the size (in pixels) on the normal main window in lightroom on my 1920x1200 screen. if it is about 1440 (might take that one)
Last question of course: What standard preview size / quality should I use on my 1920x1200 screen??
Thanks in advance for all your thoughts!

As to standard preview size and quality, try 1440 and 1680 and Med and High quality and see what you like best. You will probably choose 1680 size for your screen running at 1920x1200. That will let you run LR full screen where the image size will be close to the full size of your monitor. You can try 1440 too but I doubt that you will see any performance improvement. I have tried both sizes on my 1600x1200 monitor and I see no difference in quality or speed.
Try both Med and High quality and see if you notice any difference in your preview quality or speed. High will make your preview folders bigger which might be a factor if you have limited hard drive space.
Don't think preview size has anything to do with thumbs. Standard previews are separate from 1:1 previews so you can always zoom in and LR will generate a full size preview.
In short feel free to experiment with various settings in LR. Good way to learn the program and you will know what works best on your particular computer.

Finder Cover Flow image preview size is small, cannot be adjusted and showing empty blank previews in Mavericks

When using Cover Flow the image preview in the main window (not the thumbnail list at the bottom) images appear but only use about 1/2 of the window space available. It is also showing black/blank preview images as I scroll through the files even though they are cached.
I enlarge the Finder to fill my 27 inch display, slide the size adjustment handle (three lines under the file name preview) all the way down as far as I can. The preview only enlarges to a certain point leaving the upper half of the window unused. I wish to enlarge the cover flow preview images to use this window space even if it affects the overlapping or number of cover flow images avaialble in the window. I am assuming this is becasue of the nature of cover flow showing the two previous and two following images to the left and right of the previewed image. As I scroll left and right occsionally one of the upcoming images will appear as and empty preview as well. It's all goofed up.
Hoping for any suggestions.
I have seen articles about using terminal to adjust "flow height" but never anything substainial that seemend like an informed solution.

I also would like to know if there is an answer to this. My landscape photos always display with a third of the cover flow window as blank empty space (matching your screenshot). This seems like such a waste. Is there any way to change the "padding" between the top of the finder bar and the cover flow preview?

Stack size for native thread attaching to JVM

All:
I have a native thread (see below, FailoverCallbackThread) that attaches to the JVM and does a Java call through JNI. The stack size for the native thread is 256KB.
at psiUserStackBangNow+112()@0x20000000007a96d0
at psiGuessUserStackBounds+320()@0x20000000007a8940
at psiGuessStackBounds+48()@0x20000000007a8f60
at psiGetPlatformStackInfo+336()@0x20000000007a9110
at psiGetStackInfo+160()@0x20000000007a8b40
at psSetupStackInfo+48()@0x20000000007a5e00
at vmtiAttachToVMThread+208()@0x20000000007c88b0
at tsAttachCurrentThread+896()@0x20000000007ca500
at attachThread+304()@0x2000000000751940
at genericACFConnectionCallback+400(JdbcOdbc.c:4624)@0x104b1bc10
at FailoverCallbackThread+512(vocctx.cpp:688)@0x104b8ddc0
at start_thread+352()@0x20000000001457f0
at __clone2+208()@0x200000000030b9f0
This causes stack overflow in Oracle JRockit JVM. (It does not cause overflow with Oracle Sun JDK.) Is there a recommended stack size for this use case for JRockit? Is there a way to compute it roughly?
Platform Itanium 64 (linux)]
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
BEA JRockit(R) (build R26.4.0-63-63688-1.5.0_06-20060626-2259-linux-ia64, )
mp

How do I found default heap size, stack size for the
thread, number of threads per jvm/process supported ?The threads is OS, OS install and jvm version specific. That information is also not useful. If you create the maximum number of threads that your application can create you will run out of memory. Threads require memory. And it is unlikely to run very well either.
The default heap size and stack size are documented in the javadocs that explain the tools that come with the sun jdk.
and how the above things will vary for each OS and how
do I found ? Threads vary by OS, and OS install. The others do not (at least not with the sun jvm.)
If I get "OutOfMemoryError: Unable to create new native thread" Most of the time it indicates a design problem in your code. At the very lease, you should consider using a thread pool instead.
I found in one forum, in linux you can create maximum
of 894 threads. Is it true ?Seems high since in linux each thread is a new process, but it could be.

Standard Preview Size/Preview Quality

This may be a silly question, but in Library mode, under Edit>Catalogue Settings>File Handling, you have options under Preview Cache for 'Standard Preview Size' (1024/1440/1680/2048/2880 pixels) and Preview Quality (High/Medium/Low)... but what do these settings actually do; I've tried changing them & not noticed and difference??

Les_Cornwell wrote:
Thanks again Rob
You bet .
Les_Cornwell wrote:
I've tried all the different size options, namely 1024 through to 2880 & low/Medium/high and none make any obvious difference at all.
So are previews only created as required when you view a picture in full screen mode or does LR create a preview for all your files?
Every image you look at in Library module comes from the (library) previews, there are up to 8 possible jpegs:
* a tiny thumbnail in root-pixels.db
* up to 7 jpegs ranging from small to 1:1 in the "preview pyramid" (each smaller is half the dimensions of it's bigger sibling).
Try this with a 10 photo test catalog:
If you have a big monitor and set standard preview size to 1024, then (with Lr closed) delete all previews, then restart Lr and wait for all the "..." indicators to be extinguished (indicating standard previews have been built), then step from photo to photo in loupe view with all panels collapsed (loupe view "real-estate" maximized), you should see "loading" indicator, since it needs a bigger preview than you've got built. What it will do then is build 1:1 previews and all the smaller ones along with it, which is suboptimal from a performance point of view. If you try and zoom in to 1:1 after the "loading", there will be no additional loading, since 1:1 previews were already built.
Then, repeat the test with preview size at max - no loading indicators, right? (when stepping in loupe view after standard previews have finished being built, I mean). Except now if you try to zoom in there will be "loading", since 1:1 preview were not required to display the loupe view, they will need to be built for the zoomed (1:1) view.
The only difference between big enough and too big will be an ever-so-slightly greater lag when stepping in the loupe view and no 1:1 preview exists (when preview is too big I mean), since it's loading a bigger standard preview than is actually needed. Reminder: if preview is not big enough, there will be an ever-so-slightly bigger lag when stepping in loupe view too (e.g. vs. just big enough), since it's using the 1:1 preview instead of standard (which wasn't big enough). So, tester beware... (somewhat counter-intuitively, in some cases, it will be faster loading a preview when settings are, in general, too big, because it can get away with loading the next size down, which is an even better fit, e.g. if image is cropped just so - all of these little nuances make it especially tricky to test & evaluate, so consider doing initial tests using uniform-size uncropped images, to reduce the number of variables - it's confusing enough as it is ;-}).
Note: as previously mentioned, there is considerable complexity (and bugs) in the preview system, and I may not have described it perfectly, so it wouldn't surprise me if your results were not exactly like that, but I just went and retested on my system, and what happened is exactly as I described above (win7/64), as I read it anyway...
Regarding quality, you should see difference in some photos not others, but ONLY if it didn't resort to the 1:1 preview which may be higher quality than the standard and is independent of the standard quality setting. (I think somebody may have stated that you'd need to zoom in to see differences in standard preview quality settings, but that is wrong - the only way to see differences in standard preview quality settings is if you are in fact viewing standard previews, which you aren't when zoomed in to 1:1, and anyway it can be ellusive - see paragraphs above...).
PS - If you want to compare jpeg quality of standard previews, one way is to export them using PreviewExporter. Again, it's tricky, since you need to assure you aren't exporting a scaled down version of the 1:1 instead of a true standard preview. After exporting you can compare outside Lightroom, so you don't have the "preview of a preview" issue going... I use Beyond Compare by Scooter Software for doing objective comparison of like-sized jpegs, but you can compare subjectively using any ol' viewer, e.g. as built into OS.
Too much?
UPDATE:
Les_Cornwell wrote:
does LR create a preview for all your files?
No - they are created on an as-needed basis (thus the reason we hear many complaints about how stale or non-existent previews should be built in the background, to minimize "loading" in library module, e.g. after making dev changes to a large bunch), but note: standard previews may be considered "needed" when thumbnail is in view in grid or filmstrip (but not considered needed if thumbnail is off-screen, even if existing in filmstrip and/or grid).
R
Message was UPDATED by: Rob Cole

Speed-up? - Force a rebuild of Preview Size

Folks
Many people say they experience an increase in speed by having smaller previews. The default Preview size, in 1.5, as set in Preferences under 'Limit Preview Size' is 'Don't Limit'.
If you alter this setting to a smaller setting it does not alter the size of your existing Previews. Some folks suggest throwing away all your Previews and starting again. However - Tech article 304345 suggests an easier/better way
Aperture: Previews do not update after changing Limit Preview Size Preference
Solution:
Issue or symptom
After you change the Limit Preview Size setting in Aperture's Preferences, existing previews are not changed, even if you choose Images > Update Previews.
Products affected
Aperture 1.5
Solution
Changing the Limit Preview Size setting does not mark existing previews as out of date. In order to force existing previews to be regenerated using a new size setting, select the desired images, press Option and choose Images > Generate Previews.

Is there a way to easily tell which pictures have unwanted preview sizes? I started building previews (36,000 pictures)with the aperture default setting (unlimited size) and a day-and-a-half (approximately 24,000 pictures) later switched to the size recommended for my display. Aperture is definetly running slower than before I updated to 1.5. If there isn't an easy way to identify and resize the "unlimited size" photos, am I better off just deleting all previews and rebuilding them from scratch, or should I just rebuild as needed for purposes of ilife integration? I like the idea of being able to view all pictures in my Aperture library for purposes of using in other applications but if it is in fact slowing down Aperture I will happily rebuild.
G5 2.3ghz, 23 inch HD cinema display Mac OS X (10.4.8)

Web module exports all the different preview sizes

Trying out the web module - I select a flash template with extra large previews. When I export to Dreamweaver, not only are the Extra large previews exported but also large, medium etc. This means that if I upload to my server I will use far more space than necessary. Can I prevent this? Or can I simply delete all but the extra large pictures?

When exporting a Flash gallery it does export three sizes. Those three sizes are "relative" to the "preview size" setting, which you could kind of think of as setting the size for the "largest" of the three. When the gallery is loaded into a browser, the gallery automatically detects the size of the window, looks at the rendition sizes available, and then downloads the largest rendition size that will fit into the window. It then does some pretty sophisticated pre-fetching of the other images of that size based on user behavior (linear vs non-linear browsing of the gallery). The gallery does not download the other renditions at all - unless the end user changes the size of their browser window such that a different rendition size should be used. The gallery does not real-time scale the images inside Flash - except in the case where the browser window is made too small for even the smallest rendition, in which case it will scale down the image in real time (this is why your "trick" works). In Beta 4, the gallery threw scroll bars on the images themselves if the window was too small. I think the 1.0 approach is much better.
Granted this takes up extra room on the web server, (pretty cheap these days though) but if there were only one rendition, it really should be a size that will fit on 800x600 monitors - which is still well over 10% of web users, which would mean it would need to be pretty dang small given OS chrome, browser chrome, headers, etc - and then if you had thumnails across the bottom... Is all this overkill? When I look at galleries like the one at http://www.computer-darkroom.com/antarctica_2007/index.html in a maximized window on my hi-res monitor, I grow to really love the multiple rendition approach.

Photo preview size of 1920

Hello,
When I go into Aperture -> Prefs -> Previews, in the list of potential preview sizes, an asterisk appears beside the "fit within 1920 x 1920" option. It thus looks like "Fit within 1920 x 1920 (*)"
Can somebody shed some light on the significance of the asterisk??
Many thanks!
H.

Aperture uses the asterisk to indicate the long dimension of your currently connected primary monitor. This is the recommended size for Previews, being large enough to display full screen and no larger.
This information is hard to find in the User Manual. The page it is on, however, is well worth knowing.
Aperture places asterisks (*) next to choices that match the resolution of your currently connected displays.
From the [User Manual|http://documentation.apple.com/en/aperture/usermanual/index.html#chapter=6%26sec tion=15%26tasks=true]
Message was edited by: Kirby Krieger

Should I match STD preview size to native screen resolution or the resolution I am actually using?

Similar Messages

Maybe you are looking for