I received the same error message and after reading other comments online, I realized that I had checked the box that asks if you want to rasterize the first page of your epub for use as the cover image. When I went into the export dialog and unchecked that box, the book went through without problems. I had also included a separate cover image through iTunes Producer, so I think iTunes was seeing two cover images and the one that Adobe delivered as rasterized was probably over the 4,000,000 limit -- you just don't see it in your image links or think of it as an image, so you can't locate it -- I hope this helps.
Small Town Gal
Check the dimensions of your mages.
For example, an images that's 1750px x 2500px would be 4,375,000px and therefore be rejected.
I did check all of my images and they were properly cropped except for the pdf file which I changed over to .png and sized to the appropriate dimensions. After checking all of the images and not finding any other ones that were not sized to appropriate dimensions, it finally dawned on me that the rasterized cover image that I had included was causing the problem and could not even be seen among the images that I was checking. Getting rid of that rasterized image in the export finally cleared up the error problem -- hooray -- and it might also be abbeyx3's problem.
Small Town Gal
Got the very same error code. Very annoying, indeed. My solution was to open the epub-file and resize some .png files which indeed were larger then 4 megapixel, and then re-package the files to .epub again.
My Step-by-step solution
1 - Crack open the .epub-file (using eCanCrusher) and look inside the "OEPBS > image" folder and find the images which are larger than 4 million pixels (for example 4267x2739 pixels).
2 - Downsize them in Photoshop to 2048 px width, and replace the orginals.
3 - Pack the folder into an .epub again with eCanCrusher.
4 - Open in iBooks and check the e-book.
4 - Validate the file using EPUB-Checker.
I found a lot of huge .png files which were automatically generated from inDesign CC 2015 during the EPUB3 Fixed layout export. In the inDesign-document they originated from semi-transparent background plates. I have absolutely no idea why inDesign generates such massive pixel sized images, even when the .indd-document is set up as iPad 1024*768 px. I cannot se any need for images larger than 2048*1536 px. (well except for 2732-by-2048 for iPad Pro). Must be a bug in the conversion algorithms going from inDesign-layout to html5/CCS3-code.
I tried many things, but what eventually worked was to change the resolution output from 300 dpi to 150dpi, which reduced the whole file size considerably.
There seems to be an "interesting" feature in ID, in which it creates a rectangular image file (png) for each text box. If the text box has a visible border and fill, ID creates this png file with those colors. If the text box has no border and no fill, ID creates a transparent image. To me, this makes no sense, but there it is.
When ID creates its png file for a text box, it increases the size of the box in pixels. Then, when the relevant page calls upon this image, it reduces the size, thereby making it the original size. Sort of... Increasing the size, say from 72ppi to 150ppi, creates an image that usually has a non-integral height and width. ID rounds these to the nearest pixel. Reducing the size for display (from 150 to 72) therefore produces an image that is not the same as the original. This doesn't matter much for transparent images, but does for those with borders and fills. Sometimes, the right or bottom border cannot be shown (placement is measured from the top left).
The increase in image size, at least in my epub that is currently driving me crazy, creates a transparent png file of 3967 × 2931 pixels for the main text box of every page. These images are above the 4 Mpx limit, and cannot be uploaded to the iBookstore. It is possible to unzip the epub, and edit the xhtml of every page by simply deleting the <div> ... </div> segments that call for these transparent images. Doing so has no effect on the display of the page. I suspect that deleting the call for the image must be accompanied by deleting the png file from the image folder as well as deleting the reference to the file from the manifest. This is a pretty silly workaround for a problem that should not exist, but we may be stuck with it until Adobe fixes this bug.
A side note: when I create a test ID document with a simple format, ID does not always create this huge transparent image for the main text box. But when I set the text box to produce 2 columns, as I have for my book, then ID feels compelled to create these transparent images and call for them twice on each page.
A plea to Adobe: please teach ID not to create transparent images that seem to be entirely unnecessary in the final epub! This is giving us all headaches.
1. deleted all transparent images references from the manifest
2. deleted all the transparent images from teh images folder
3. deleted all <div...</div> for transparent images in the xhtml
However, if I use ecan crusher to re-package my ePub and then upload that to iTunes Connect, there's a whole other host of issues that never show up in my original, exported from InDesign to e-pub. Also, the ecan crusher file is twice the size and my original was already 500M. Any other, cleaner repackaging options out there?