I'm creating a magazine to read on an iPad and am having problems with creating readable pages. What size (DPI and MB) should my files be? And I'm doing an export from InDesign, are there any suggested steps that should be taken here?
The iPad display is at 132 PPI.
The iPad display is 1024 x 768 - I'd recommend making your images that size.
That's right, the image size for iPad is by default 1024x768, but I recommend you to create your file in 1152x1536 px if you want to zoom-in in your image on iPad end keep a good quality of display.
Are you creating a pdf of the entire document or saving the pages as images? You may also want to consider the way users will be accessing the document (online, each page downloaded or as an application) If it is an application you will be able to have larger page sizes. If online, then download size will definitely become a factor in how it looks. If you shrink the quality too much, your rendered text will be the first thing on the page to suffer.
Have you done any research into what you find a comfortable to read text size (i.e., with popular science, wired, or project magazines? Another one to check is digital2.0 or the first of the RAW applications which was put out) These magazine apps use scrolling text regions in a lot of cases, but you can at least see how they use fonts and how comfortable they will be at different sizes.
Related
recently I made a website for my photography. htttp://www.simotamas.com
I am a newbie, so its not the best site but it works fine for me, I got only one problem, when a site is loaded on a device for the first time, the gallery loading time takes up to 1-2 seconds.
Could you guys please check if I mess up something with the code?
Or should I made the pictures even smaller?
Any way I could increase the loading performance.
I would be really thankful for any advice.
Some points you can consider
Use thumbnails for preview (low resolution) , while clicking load actual image.
Load images of only visible part first then load the images in bottom. (May affect user experience)
if you have cpu power , use any libraries like cache tools or compression tools like
https://nielse63.github.io/php-image-cache/ . benchmark it carefully.
use gzip if you are not using gzip compression for your server.
The fact your website doesn't wait for the image to load is considered a plus (look into asynchronous web page content loading for a good read) that said you should compress your images before uploading them.. tinypng.com is a nice tool for it... But if it's a photography website doing so would reduce picture quality... Try to play with Photoshop save settings to find your ideal compromise between quality and size with respect to "memory" size... Pictures are heavy.. high definition and resolution will obviously result in heavier files to download
Update: another thing you could do is actually display (smaller) thumbnail and only load the full picture on request. I.e: user clicks and image opens in new tab
It would help if you create smaller thumb versions of your images so the browser can initially load these ones for the overview and no need for scaling way to big images down while rendering the page. An image should always be downloaded in the dimension it's going to be presented.
In my app, I've a panorama-page which contains around 10 panorama items. Each panorama item has some path drawings, a list picker and few input fields.The problem i'm facing is that whenver i navigate to this page the navigation is very slow due to lot of content to initialize. If i comment the InitializeComponent(); the loading becomes fast.I thought of adding the XAML content in code, but the problem is that i've to access the input fields by their name in code, so it didn't worked.Any idea how i can speed up the navigation to the page.Thanks..
From the UI Guide:
Use either a single color background
or an image that spans the entire
panorama. If you decide to use an
image, any UI image type that is
supported by Silverlight is
acceptable, but JPEGs are recommended,
as they generally have smaller file
sizes than other formats.
You can use multiple images as a
background, but you should note that
only one image should be displayed at
any given time.
Background images should be between
480 x 800 pixels and 1024 x 800 pixels
(width x height) to ensure good
performance, minimal load time, and no scaling.
Consider hiding panorama sections
until they have content to display.
Also, 10 PanoramaItems seems like a lot since the recommended maximum is 4. You should either cut down on the number, or hide the content until it's required. Have a read of the best practice guide for Panoramas on MSDN.
I think you could improve page performance by creating usercontrols for the specific panorama items, add an empty panorama control to your page (with only the headers) and as picypg suggests load these usercontrols when they are needed.
Another way could be that you load the first page and show this one already to the user. In the background you could start loading the other panorama items.
My suggested approach would be for the first one. Using the lazyloading principle.
I woudl assume that your delays are due to the number of items on the page. This will lead to a very large object graph which will take a long time to create. I'd also expect it's using lots of memory and you have a very high fill rate which is slowing down the GPU.
Having input items/fields on PanoItems can cause UX issues if you're not careful.
That many panoItems could also cause potential navigation issues for the user.
This may well be a little of an open-ended question
The site I am working on requires to be optimised for performance. One of the key areas is to optimise the file sizes of the images used upon the site.
Unfortunatley these images are being created by employees who do not have the required knowledge for creating images for the web, and it is my job to produce a set of guidelines for them to use.
I was wondering whether there was any resource/guidlines/literature regarding typical images file sizes for images of different dimensions - as I would like to include something like this to aid them to ensure their images are being created properly.
Any info would be greatly appreciated.
Thanks in advance
I can't answer the opinion question, but I can suggest some guidelines that will keep your images smaller.
First off, if they're using Photoshop to edit their images, it's likely they're storing a whole bunch of crap in the headers (digital papertrail, EXIF data, and such). Also, folks will frequently save in too high a bit depth.
For novice users, trying to explain why they need to use "save for web" is more likely to confuse them. Instead, just point them at:
http://www.smushit.com/ysmush.it/
This site is rather handy - it will compress all the images on a page you specify, or you can upload the images.
You should strongly consider writing some guidelines about where images are stored as well. It's frequently very beneficial to have your static image content stored on several servers, apart from your dynamic content. Most browsers will only download a limited # of files at a time from any given website (usually it's 2).
Unless there's a good reason, all your images should be cached using one of the HTTP cache techniques (expires, etags, etc).
Good luck.
72 dpi as a resolution and either jpeg or png formats work best.
Try to use images at the exact pixel area size they will end up being displayed as. This is specified by the images height and width attributes.
You can set the output quality of a jpeg image which will also save file size although there is a trade off against image quality.
I hope this is of use.
I'm developing an app for WP7 (VS2010 Express for Windows Phone RTM and WP Emulator), but now im facing a big problem related to memory usage.
The app itself has like 12 views, and some of them are reused with different data. It's a newsreader, so the views are mostly listboxes (image thumbnail, stackpanels and textblocks).
The first view has a listbox with 30 items. This takes about 20MB of RAM, but as i navigate between views the current and peak RAM usage start to rise. Well the peak usage it's around 55MB which i think is OK, but the app has a gallery section in which after selecting a thumbnail it navigates to another view which displays a downloaded image (JPEG, 1131px × 1647px, ~486KB) but initially fit to the screen. Until here all good, but for scaling purposes i'm using Laurent Bugnion's Multitouch Behavior and the problem is that when i zoom in the image, the memory usage gets near 90MB (like 87MB last time i tested with the maximum scale size at 2.5).
Also after i navigate the views the current ram usage may permantly reach and stay at 35MB, which i beleive is due to the device caching some things.
So, as the title says, how can i avoid such huge ram usage?
Edit----
Also i'd like to ask if the fact that in my app one can navigate from any view to almost every other and that in between there's always a page transition animation (like the one for the phone list application template in the beta tools), may be contributing to the excessive memory usage.
Generally speaking you want to keep images as small as feasible (in dimensions and color depth, not necessarily file size). In order to display an image, the device must decompress it to an actual Bitmap, so in this case you're looking at a 1131x1647pixel image, let's say at 16bpp, means that you have a 3.7MB memory footprint for the image, not the 486k file size.
Depending on your zoom/rotate, there may be a second copy buffer, so you can effectively double that. It doesn't take long at that rate to get to 90MB. I'd certainly try either download smaller image files or try resizing them locally and then using the resized image.
Well maybe i should look into deepzoom (but when i first read about it, i thought it was for using it with the same image at different sizes, like google maps in satellite view), but yesterday i solved it by using a webbrowser inside my view, so if before i had:
<Image x:Name="imgPlaceHolder" delay:LowProfileImageLoader.UriSource="{Binding Path=ActualImageSource}" MaxHeight="800"
MaxWidth="480" >
<interac:Interaction.Behaviors >
<tbeh:MultiTouchBehavior x:Name="ImageMTB" IsScaleEnabled="True"
MinimumScale="0.4"
MaximumScale="2.5"
IsRotateEnabled="False"
IsDebugModeActive="False"
IsTranslateXEnabled="True"
IsTranslateYEnabled="True"
>
</tbeh:MultiTouchBehavior>
</interac:Interaction.Behaviors>
</Image>
I changed that to:
<phone:WebBrowser Source="{Binding Path=ActualImageSource}" x:Name="wbbigimage" />
It uses less memory and takes care of the zoom with no problems.
I'll wait a bit for someone with a better solution before checking this one.
A couple of things to note. First, make sure that you are clearing out any lists or images that you are using on pages durring the onNavigatedFrom method. The way WP7 Deals with images is "interesting". One of the things I have found to help is to null out the background of any panorama controls when the page is not being displayed.
As for your specific issue, have you considered using a MultiScaleImage (Deep Zoom) to cut down on memory?
http://msdn.microsoft.com/en-us/library/system.windows.controls.multiscaleimage(VS.95).aspx
We would like to display very large (50mb plus) images in Internet Explorer. We would like to avoid compression as compression algorithms are not what CSI would have us believe that they are and the resulting files are too lossy.
As a result, we have come up with two options: Silverlight Deep Zoom or a Flash based solution (such as Zoomify). The issue is that both of these require conversion to a tiled output and/or conversion to a specific file type (Zoomify supports a single proprietary file type, PFF).
What we are wondering is if a solution exists which will allow us to view the image without a conversion before hand.
PS: I know that you can write an application to tile the images (as needed or after the load process) and output them; however, we would like to do this without chopping up the file.
The tiled approach really is the right way to do it.
Your users don't want to download a 50mb file before they can start viewing the image. You don't want to spend the bandwidth to serve 50 megs to every user who might only view a fraction of your image.
If you serve the whole file, users will eventually be able to load and view it, but it won't run smoothly for most of them.
There is no simple non-tiled way to serve just a portion of an image unless you want to use a server-side library like imagemagik or PIL to extract a specific subset of the image for each user. You probably don't want to do that because it will place a significant load on your server.
Alternatively, you might use something like google's map tool to provide zooming and scaling. Some comments on doing that are available here:
http://webtide.wordpress.com/2008/08/27/custom-google-maps/
Take a look at OpenSeadragon. To make a image can work with OpenSeadragon, you should generate a zoomable image format which mentioned here. Then follow starting guide here
The browser isn't going to smoothly load a 50 meg file; if you don't chop it up, there's no reasonable way to make it not lag.
If you dont want to tile, you could have the server open the file and render a screen sized view of the image for display in the browser at the particular zoom resolution requested. This way you arent sending 50 meg files across the line when someone only wants to get an overview of the image. That is, the browser requests a set of coordinates and an output size in pixels, the server opens the larger image and creates a smaller image that fits the desired view, and sends that back to the web browser.
As far as compression, you say its too lossy, but if thats what you are seeing you are probably using the wrong compression algorithm or setting for the type of image you have. The jpg format has quality settings to control lossiness, and PNG compression is lossless (the pixels you get after decompressing are the exact values you had prior to compression). So consider changing what you are using as compression, and dont just rely on the default settings in an image editor.