Managing cover images in mobi/epub files

[steje]

First time Calibre user here... and trying to understand if Calibre is able to truly remove cover images embedded into various mobi files I have or not.

After adding some mobi files into Calibre, and then editing metadata, none of the changes are written out to the file that I actually added to Calibre, but are instead (I presume) saved in some kind of Calibre library database or index or something? The only way I see to write the changes out to file is by using the "Save to disk" feature... which appears to write the file out to a new file...

While title and author changes appear to be written out to the new file... the 'original' cover image(s) are still all present and not actually removed. Any 'new' cover image I add in Calibre is saved to a JPG file, and not embedded in the mobi file.

I want to achieve TWO things:

1.) Make sure any and all 'existing' cover images embedded in the mobi file are stripped out...
2.) Make sure any 'new' cover image I add in Calibre gets embedded in the file I Save to disk...

I will also be 'converting' some of the MOBI files and saving them as EPUB along with newly modified MOBI, as I want to put the same books on my wifes iPad as well as my kindle... and while I am not familiar with EPUB format conventions - I'm assuming it's valid to want the cover image embedded into resulting EPUB file that I want to save off to disk as well...

Can someone offer guidance...?

[dwig]

The cover image in both MOBI and EPUB resides in the core portion of the file. It is not "metadata", and therefore can't be changed without rebuilding the file.

To change the cover in a MOBI you must convert it, generating a completely new file. With calibre you can do a MOBI to MOBI conversion to accomplish this.

EPUB files are actually just specially organized ZIP archives. You can change the cover image by converting in calibre (either MOBI > EPUB or EPUB > EPUB). You can also change the image by opening the archive (using calibre's Tweak EPUB function or by changing its extension to ZIP and viewing the contents).

If you do the latter, you need to replace the existing cover image(s) with new images of matching size(s) in the archive. Do not extract the archive components and then attempt to rebuild an archive. Rebuilding the archive from scratch is somewhat tricky.

[DoctorOhh]

Originally Posted by steje

I want to achieve TWO things:

1.) Make sure any and all 'existing' cover images embedded in the mobi file are stripped out...
2.) Make sure any 'new' cover image I add in Calibre gets embedded in the file I Save to disk...

I will also be 'converting' some of the MOBI files and saving them as EPUB along with newly modified MOBI, as I want to put the same books on my wifes iPad as well as my kindle... and while I am not familiar with EPUB format conventions - I'm assuming it's valid to want the cover image embedded into resulting EPUB file that I want to save off to disk as well...

I don't use mobi but I think the only way to ensure the cover is embedded in the book is to do a mobi to mobi conversion.

When you convert the mobi to epub the new cover will be embedded in the epub. Also if you have epubs from some other source you can embed the cover using the modify epub plugin (beta).

Good Luck.

[steje]

Thanks to both of you... the mobi to mobi conversion seems to do the trick. And the info about the epub format is good to know, I will mainly be converting from mobi to epub (for "now") and will have gotten the cover image sorted out before conversion. Thanks again... would never have suspected mobi to mobi conversion as being necessary.

[steje]

Actually, I was mistaken... converting from mobi to mobi does NOT remove existing cover images (for instance, if you REMOVE the existing cover image in calibre, then convert mobi-to-mobi)... the images remain.

What DOES work, is if you assign a NEW cover image, then convert mobi-to-mobi, then the 'new' image is properly set as the cover image (properly adjusted offsets or whatever) but all of the existing images remain as well.

This is all kind of counter-intuitive. I'd expect that if I assign a new cover, and then save to disk, that calibre should do whatever is needed (convert mobi to mobi acrobatics) in order for that cover to actually be saved in the file so that it is visible when I copy that file to a device...

The only way I have found to properly "clean out" these unwanted images... is to convert the original mobi to OEB folder/HTML, then add the resulting HTML file back to calibre, redo all the metadata tags, convert HTML/ZIP back to MOBI, and then I have a pretty "clean" mobi file with JUST the cover image I've specified in calibre.

Gotta say that's a rather disappointing series of hoops to have to jump through to do something I'd have thought is a mundane action on an ebook (stripping unwanted cover images and replacing with a desired cover image).

If there's an easier way... that would be real nice. I'm already converting original mobi to OEB folder/HTML from the command line tool, maybe some older VB scripts I wrote to use the mobiperl tools can be modified to do all the rest of the work I'm struggling with using the calibre cli instead of the gui.

[dwig]

Originally Posted by steje

...

The only way I have found to properly "clean out" these unwanted images... is to convert the original mobi to OEB folder/HTML, then add the resulting HTML file back to calibre, redo all the metadata tags, convert HTML/ZIP back to MOBI, and then I have a pretty "clean" mobi file with JUST the cover image I've specified in calibre...

One the occasions that I need to significantly massage a MOBI file I've found that a calibre MOBI>EPUB conversion, an edit in Sigil, and then EPUB>MOBI in calibre is the easiest workflow. Using Sigil avoids the issues of the loss of metadata, allows for proper TOC management, makes setting chapter breaks easy (caution with the new v0.4.0!!, I use 0.3.4), and allows decent image control.

[DoctorOhh]

Originally Posted by steje

This is all kind of counter-intuitive. I'd expect that if I assign a new cover, and then save to disk, that calibre should do whatever is needed (convert mobi to mobi acrobatics) in order for that cover to actually be saved in the file so that it is visible when I copy that file to a device...

This seems to be caused by mobi's archaic standards. The cover is not easily identified from the basic html code. If you were dealing with epub the cover is easier to identify and often will be updated during save to disk or send to device and as dwig has stated Sigil is a very easy tool for basic changes to any epub book.

Have you tried checking "Remove first image" under Preferences - Common Options - structure detection? This will remove the first image in a book during conversion, usually the cover.

That's the extent of my vast knowledge.

Good Luck.

[steje]

@dwanthny: well, I can't attest to the archaic-ness of mobi's standard :-)... though if you can store an image and then display it - it would seem to me to operate based on rules that should allow the same to be removed and any offsets adjusted. My understanding is that the "cover" image can be stuck into a mobi file in one of several ways - one where it is identified in some header data as "the" cover image, with associated offsets, etc... vs the other way (which I think you alluded to) being just "an" image like any other referenced in the actual HTML of the book content - like any other chapter header images and other in-story images.

re: that last - I dabbled with the "Remove first image" option you mentioned, but it appears I have some mobi files that have the cover image listed OTHER than as the first image, etc... Sigh.

At this point - from a workflow perspective, the most consistently useful method for me is to just convert to html, clean out any references to any existing cover image, then re-convert to mobi (and epub as well for that matter). Since I "am" converting to epub now as well - I'll see if converting straight to epub first instead of html, then making my mods in sigil, then final convert from epub to mobi works ok (ta dwig)...

Thanks all for the thoughts and information - you guys are quite responsive and welcoming to newcomers. Much appreciated!

[dwig]

Originally Posted by steje

...
re: that last - I dabbled with the "Remove first image" option you mentioned, but it appears I have some mobi files that have the cover image listed OTHER than as the first image, etc... Sigh.
...

MOBI cover images are not placed in the body of the ebook. It is common, though, for an EPUB to have both a true cover image and a second copy placed at the beginning of the book data.

When these EPUBs get converted to MOBI the resulting file has a true MOBI-style cover and a matching image at the beginning of the book itself. Often this second image displays at a different size on a Kindle as the Kindle zooms the true cover to fit the screen and the second copy is treated like any other image in the book and displayed at its native size or that spec'd in the <img> tag. Calibre's "remove first image" can remove the extra copy from the book data but does not touch the true cover image.

[HarryT]

Originally Posted by dwanthny

This seems to be caused by mobi's archaic standards. The cover is not easily identified from the basic html code.

I must respectfully disagree. The cover, in a Mobi book, is not in the HTML at all; it's identified (and very clearly identified) in the OPF file. There's nothing "archaic" about it .

[DoctorOhh]

Originally Posted by HarryT

I must respectfully disagree. The cover, in a Mobi book, is not in the HTML at all; it's identified (and very clearly identified) in the OPF file. There's nothing "archaic" about it .

I defer to your obvious experience with the mobi format.

Thanks for the info.

[kovidgoyal]

Originally Posted by HarryT

I must respectfully disagree. The cover, in a Mobi book, is not in the HTML at all; it's identified (and very clearly identified) in the OPF file. There's nothing "archaic" about it .

In an actual MOBI file the cover is stored in an arbitrary Palm DB record. Properly created MOBI files have a field correctly set in their headers that gives the record number of this record, but just as with epub, there are tons of MOBI files out there that do not have this field in the header set.

[HarryT]

Originally Posted by kovidgoyal

In an actual MOBI file the cover is stored in an arbitrary Palm DB record. Properly created MOBI files have a field correctly set in their headers that gives the record number of this record, but just as with epub, there are tons of MOBI files out there that do not have this field in the header set.

Thank you for the clarification, Kovid. I always think in terms of the source files used to create a Mobi book.

[steje]

Originally Posted by kovidgoyal

...there are tons of MOBI files out there that do not have this field in the header set.

In such a case, would Calibre even be displaying a cover image in the edit metadata view though...?

In any case, I would have expected that if Calibre can identify and display a cover image in an existing MOBI file, that "removing" that cover image, then saving to disk should result in a mobi file that no longer contains that image. period... Perhaps it was doing so, but the resulting re-saved or converted MOBI file that I then looked at still had the 'other' image embedded in the HTML without having used that "Remove first image" option. Not sure - I'd have to go back and compare my starting MOBI vs a re-saved and converted mobi with and without that option set.

While it's time consuming, I'm content for now with converting to html, cleaning out any unwanted images (sometimes that's more than just a very bad cover image... but sometimes other ugly images included in the html, which I remove references to), then reconvert to both MOBI and EPUB after I've found better looking covert art.

[kovidgoyal]

Because in that case calibre assumes the first image is the cover, a safe assumption since even if calibre is wrong, there is no great harm done. Which is obviously not the case when replacing an image.