I am about to build a Retina rendition of our (photography) magazine. It is currently 526MB at1024 rendition and so will be considerably larger than this. I am interested to hear other peoples experience with Retina display and the files sizes of your published mags. Has there been any negative feedback regarding app downloads?
This is somewhat tangental but maybe you haven't considered it.
Being a promoter of the Social stuff, would love to see a socially shared version of a photo magazine because images and raster folios would great for this. If you stuck with the 1024x768 single rendition, you could share some articles unprotected and target both iPad2 and iPad3 and use the Web Viewer.
If you go to retina with all photos given your existing folio size it would be I think 4 times the size, so over 2gb. My personal experience is that I wouldn't want to have to download that unless I really really wanted the issue badly. I can obviously see why you'd want to try full res though.
I you publish a retina version and want to use the Social feature, at the moment iPad3 users will not be able to share articles that result in Web Viewer being displayed. This is because we can't make the association between the two renditions at the moment and pick the 1024x768 version if there are two renditions. We know this is pretty lame and it's being fixed for future release.
Thanks clloyd2006, really useful advice. I have wondered why Apple has created a super hires display that will quadruple file sizes without offering four times the storage on the iPad and as you point out requiring a massive download that will probably put many people off. That's why I am interested in what other publishers are doing.
Can we really claim to be publishing a Retina Ready app unless we make a higher res rendition?
Have you tried setting your article format to PDF and then publishing a 1024x768 folio only to see how that looks on the new iPad? The text will render nicely and everything else may simply be just fine.
If not, try using PDF for the article format and then creating a 2048x1636 folio. The file size won't be 4x the size of the SD iPad and will likely be acceptable.
Our guidelines for publishing SD and HD folios is at http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/d igitalpublishingsuite/pdfs/dps-ipad3-bestpractice-apr2012.pdf. If you haven't read through it I suggest doing so as it provides our best practices for targeting both device resolutions.
Thanks Neil, I have followed the guidelines and done tests at both resolutions. So far we have linked higher res images in ID but only produced a single 1024 PDF rendition (526MB). The text looks great and to be honest so do the images. But with a high end photography magazine we expect the reader to zoom into images so the higher res is attractive to us. Also Bob B has suggested elsewhere that it would be better for Folio builder to do the upscaling to 2048 rather than the iPad.
The "better for Folio builder to do the upscaling" really applies to overlays and interactive elements, rather than text. If you are planning on doing pan and zoom to enable a deeper look at the images then yes, you'll need to create a 2048 folio using high-res images. There really isn't any way around the increased file size there, unfortunately.
What magazine is it? I'm an avid photographer and would love to take a look
I found the best way to produce for retina was using 1024x768 source document with high resolution uncompressed pdf images ( mine were 4000x5000 pixels) then bundling in a 2048x1536 folio. This kept my folio sizes under 1gb. My last one was 700mb, quality was fantastic.
After much delay our 500mb regular rendition is 1.5gig in its Retina form. ID pages were setup as 1024 with high res images using PDF as the image format. It's a high end photography magazine so image quality is paramount but will readers accept a 1.5 gig download? I would really appreciate feedback on this from Adobe as well as forum members.
Its a pity we can't give iPad 3 users the option to download either rendition, I imagine that is not possible Bob B?
No, you can't give users the option to download one rendition or the other unless, I suppose, you publish both issues with different names so they aren't actually renditions. Then customers would see both in the store.
1.5GB seems large, and no, your readers likely won't be happy downloading that much content. For the images you have, are you restricting them to the actual size needed to display on the new ipad screen? Or are you going even larger and using the pinch and zoom overlay so people can zoom in and look at even greater detail?
I think your best bet is to do some experimenting and perhaps have a focus group or two with some impartial eyeballs.
There’s no way you’re going to sell this with files that huge, so by trying different settings and showing people with nothing invested (let’s face it, we’re all our own biggest critics)you may come up a happy medium.
Thanks again Bob but this issue does raise a fundamental problem with Adobe's approach. I am sure that files sizes would be a lot smaller with an HTML5 based engine and it may be the issue that finally forces us to part company with Adobe.
Am I right in thinking that using two orientations doubles the folio size? This would not be the case with HTML as the images would be linked not embedded. If I am wrong please let me know.
I just had a long chat with Colin about this. Graham, can you please provide some more details on how you are including images in your folio? Are they just being placed in? Are they inside overlays? If so, which overlays? Are you using videos?
If you are simply placing an image on the background of your page then the size of your image is irrelevant. It just becomes part of the background of the page, which is always the pixel dimensions of the folio. If you are including it in an overlay then, depending on the overlay, the size of the image may matter a lot.
If you are producing a horizontal and vertical version of your folio you will definitely see an increased file size, and honestly the easiest way to cut your size down for iPad is to only publish one orientation.
Neil we have about 230 full screen images (in each orientation), most of these in Object States many driven by thumbnails acting as buttons plus lots of smaller ones. My understanding is that images within Object States and Buttons will be resampled to the size of the rendition. We only have 3 videos and these are all 1024 and totalling around 100mb and I understand that these will not be resampled. We also have about 35 audio clips totalling less than 5mb.
This is a screen shot of a page with thumbnails, details of the screen shot actual size and a zoomed in area, still sharp in the Retina rendition.
Giving iPad3 users a choice whether to download 1.5gig or 500mb would be ideal. We are publishing in Newsstand so what if we offer two issues with slightly different names rather than two renditions using the same name, both would appear in iPad3 users Newsstand and they could make a choice, Is this a simple solution or am I missing something?
No not Pan and Zoom just a straight Object State (each with an audio button), but as a PDF folio the page is zoomable, so the image size is not relevant right (for the record this image is 1365 x 2048) ?
What do you make of my suggestion at 18?
I've never tried your suggestion on #18. It should work, but I'd rather you didn't have to do that
What's the file size (not pixel dimensions) of that image on disk? Couple of MB?
Ok, that info helps. For each image in those object states we will rasterize it to the size of the frame on the folio page when you add it to Folio Builder. So even though your source image is 3.7mb, they won't be that big when resampled for the folio.
My guess at this point is it's a combination of two things:
1) You have a lot of images. There's no way around the file size increase that brings with it, whether you're using DPS or something else. More images means more file size.
2) Your horizontal and vertical layouts aren't sharing the image assets.
To verify #2 try the following: go to one of your MSOs, change to a different image, and then rotate the device. If the MSO resets then asset sharing isn't happening.
Hi Graham, I had to take a step back and re-***** every overlay in my app before we went retina. Guitarist Deluxe was weighing in at around 500mb before retina so I shared the same concerns. However with some small changes and some HTML our current retina app stands at 640mb and we managed to shave off over 200mb off the sd version without loosing any quality or content.
How are you importing your articles into folio builder?
YC Our folios are all PDF. I think our problem is the large number of 2048 images, 230 in each orientation. I was confused by Neil's comment about sharing the same assets as we have only one set but as I understand it unlike HTML these are embedded within each orientation rather than linked and so double the size. Another thing that I would like clarified is our thumbnail images (buttons) also share the same assets, I assume that like the Object States that these too get resampled? If not resampling them would make a big difference, Neil?
PS As we had to "go to press" last night we have taken the decision proposed in Post 18 to offer two versions to iPad3 users assuming that this works. With a good wifi connection some readers won't be phased by 1.5 gig but if they are, they will have an alternative option.
In the longer term an HTML5 backbone must be the way to go, it will result in smaller file sizes and many more interactive options. The problem of course is that there is no other application that offers the same familiar workflow as InDesign. What we really need is an HTML5 based "folio" generated from an InDesign like application.
I will be away from the forum for a few days R&R but will check this thread when I return so please keep the advice coming even though my response will be delayed.
Ok, a few thoughts for you when you return from your R&R:
1) I was mixing up our ability to remember MSO states across rotation with asset sharing. Today it is not possible to create an MSO in horizontal and veritcal orientations and have the image assets shared. This means that by having two orientations, each with MSOs, you're going to get two copies of every image used, including two copies of each button image.
2) Regardless of the source size of your images, InDesign will resample them to fit the size frame you've placed on the page. Even if you're making them 2048x1536, if your frame is smaller than that on the page the images will get downsampled.
3) HTML5 will not necessarily result in smaller file sizes. HTML and PDF folios are essentially the same size in most cases we've seen. The real cost to your folio size is the images, and they will still be that size in HTML. Hosting the images on a server somewhere and loading them via image tags in HTML will certainly make for a smaller folio, but at the cost of offline readability.
Hi Neil, thanks for that.
I wasn't thinking of them being hosted on an external server rather that the "folio" would be like a local web page but downloaded as part of the app, rather like ePub. Then only one set of assets would be required. ID is the natural application for publishers to use as it is familiar and has a collaborative workflow. If it could generate the sort of "folios" that I have described I would have thought that would be ideal.