I created a 8.5x11.0 inches image # a 300dpi setting in photoshop.
When i go to use this as a background image in report designer the image looks hugeee.
It's not fitting within the 8.5x11.0 page.
Is there a way to resize this image correctly so that it will fit correctly within a 8.5x11.0 letter size page?
Thanks in advance,
with the information you gave, i believe your problem is problably in the group Size/dpi
You saved an image of size 8,5 x 11 inches # 300 Dpi (dots per inch) that calculates to aproximately an image of 2550 x 3300 pixels.
Now if your "report designer" software looks only at the size in pixels and assumes a dpi value diferent then the one you used, say for example 72 dpi, your 2550 x 3300 pixels image would actually be something like 45,8 x 35.4 inches.
So, my advice is, find out what are the characteristics your solftware is especting, aparently it is not 300dpi.
If you can´t find the information, try commonly used dpis like 72dpi or 150dpi.
Related
I'm trying to create MATLAB figures to put into a paper. The paper has very specific sizing instructions for figures that I'm having trouble matching in MATLAB. The figures need to be no greater than 3.5" width, >300 DPI, with 8pt font.
In my code, I use the following to try to set the parameters:
set(gcf,'PaperUnits','inches');
set(gcf,'PaperPosition',[0 0 3.5 3.5]);
xlabel('x-axis label','FontSize',8);ylabel('y-axis label','FontSize',8);
set(gca,'FontSize',8);
print('-djpeg','-r300','filename.jpg')
This should be giving me a 300 DPI, 3.5"x3.5" JPEG image with an 8pt font size. However, when I import the image into Word, it becomes 6.5" x 6.5" and the font size is larger than Word's 8pt font. Even if I resize the image, the font size is still too large, though it should maintain the same DPI. Are the FontSize and PaperPosition parameters not working as I expect they should or is Word doing something strange for importing?
The font size issue was caused due to differing fonts used in MATLAB and Word. Once I learned about set(gca,'FontName'), the font size seemed to be correct when the image was manually resized to 3.5" x 3.5".
The image size issue seemed to be related to saving it as a JPEG. Once I swapped to PNG, the image was the correct size by default. Looking into the JPEG properties, it had the correct number of pixels for a DPI of 300 at 3.5", the sole issue was that it would have to be manually resized. Thanks for the comments that led me to finding a solution.
Here is the problem to change an image resolution from 300 dpi to 200 dpi or 600 dpi.
i am using matlab but how can i be. so for i have use the imresize function which down sample the image and up sample it.
imresize(image, scale ,interpolation).
how can down sample the image to reduce its quality too. so that i may check the difference between the original image and the down sampled image.
j= imresize(I,0.2,'nearest');
where I is the original image and j is the down sampled image. is this changing the dpi of an image.
Dots per inch (DPI) has nothing to do with the type of resizing done by imresize. In fact, changing the DPI does not even require changing the actual image data, just the metadata -- a property or label. DPI gives you the information needed to go from pixels -> inches (print size).
I have read a lot about BMP file format structure but I still cannot get what is the real meaning of the fields "biXPelsPermeter" and "biYPelsPermeter". I mean in practical way, how is it used or how it can be utilized. Any example or experience? Thanks a lot
biXPelsPermeter
Specifies the horizontal print resolution, in pixels per meter, of the target device for the bitmap.
biYPelsPermeter
Specifies the vertical print resolution.
Its not very important. You can leave them on 2835 its not going to ruin the image.
(72 DPI × 39.3701 inches per meter yields 2834.6472)
Think of it this way: The image bits within the BMP structure define the shape of the image using that much data (that much information describes the image), but that information must then be translated to a target device using a measuring system to indicate its applied resolution in practical use.
For example, if the BMP is 10,000 pixels wide, and 4,000 pixels high, that explains how much raw detail exists within the image bits. However, that image information must then be applied to some target. It uses the relationship to the dpi and its target to derive the applied resolution.
If it were printed at 1000 dpi then it's only going to give you an image with 10" x 4" but one with extremely high detail to the naked eye (more pixels per square inch). By contrast, if it's printed at only 100 dpi, then you'll get an image that's 100" x 40" with low detail (fewer pixels per square inch), but both of them have the same overall number of bits within. You can actually scale an image without scaling any of its internal image data by merely changing the dpi to non-standard values.
Also, using 72 dpi is a throwback to ancient printing techniques (https://en.wikipedia.org/wiki/Twip) which are not really relevant in moving forward (except to maintain compatibility with standards) as modern hardware devices often use other values for their fundamental relationships to image data. For video screens, for example, Macs use 72 dpi as the default. Windows uses 96 dpi. Others are similar. In theory you can set it to whatever you want, but be warned that not all software honors the internal settings and will instead assume a particular size. This can affect the way images are scaled within the app, even though the actual image data within hasn't changed.
While trying to create a repeated tile overlay, I've found many questions (like this one)
mentioning that repeated images in Cocos2d must have height and width dimensions that are powers of two.
This raises two questions. First, why is this a limitation? Second, and more importantly, how can I create a repeating, scrolling image that has dimensions that are not a power of two? What if I have a really wide background (say 4000 pixels) and I want it to repeat across the X axis. What should I do in that context? I can't believe the "correct" answer is to add an additional 96 pixels to the width, and increase the height of the image to 4096, as well. That's wasted bytes!
This answer has excellent info on why the need for power of 2 textures.
Why do images for textures on the iPhone need to have power-of-two dimensions?
As for your second question, the texture does not have to be square, just both the width and height have to be a power of 2. So you could have an image that is 4096x128 repeating as your background. Keep in mind also that textures, no matter what the size, are always stored in memory in an uncompressed power of two size. So an image with width of 4000 and and an image with width of 4096 are actually using the same amount of memory.
I've gotten some graphics files for buttons etc. from the designer. Most of the retina files have one or both dimensions odd, like 29 x 30 or 79 x 61, and then the dimensions of the corresponding non-retina files will be 15 x 15 or 39 x 31, for example. The dimensions of the UIImageView s that hold each image exactly match the size of the non-retina files they hold, so on a non-retina phone there is no distortion and everything looks fine.
On a retina phone, these images (icons and such) only look fine when the images happen to be even dimensions (like 30 x 30 or 46 x 80); when there's an odd dimension to the image, it gets distorted slightly.
Should the pixel dimensions of a retina image always be twice the size of the non-retina dimensions, and of the dimensions of the frame that displays it?
As the name (#2X) implies, it is indeed assumed that the retina-version is exactly twice the size of the non-retina version. Otherwise, as you have seen, there might be distortions.
On a side note, this has only indirectly to do with the displaying frame, e.g. think of scrollviews.
Ask your designer to always design the UI (not necessarily the components themselves) for the non-retina version first, and then just double up the sizes for the retina version. This way, you won't run into distortion-problems. If he designs for retina-first and then scales all components back to half their sizes, he will likely end up with odd dimensions.
Oh, and give your designer this link:
http://www.smashingmagazine.com/2010/11/17/designing-for-iphone-4-retina-display-techniques-and-workflow/
Yes, image files that have #2x appended should be exactly double the size of the 'non'-retina image. Thus should only have even dimensions.
It would appear so.
When you create a view which is 30 points by 30 points on a regular display the backing store (the data that gets drawn on the screen) will be created 30 pixels by 30 pixels.
On a retina display that backing store is simply multiplied by a scale factor. Currently that scale factor is 2 for iPhone 4 and iPhone 4s. This means that the backing stores on retina displays will always be a multiple of 2.
Your 30 point by 30 point view would have a 60 pixel by 60 pixel backing store. If your images aren't drawn properly for retina displays it would seem that the #2x image needs to be the full size of the backing store, and hence exactly double the size of the view in points.