Quote:
Originally Posted by Jellby
The most important is: save and keep the PNGs, with the largest resolution and bit depth you can afford. It's always easier to re-create the compressed/reduced files from those than going back to the scans.
|
Oh yes, I agree. The comment goes back to the OP; this is a guideline in all cases, part of the standard routine.
Always get the source in, edit in, and save an archival copy in, max bit depth and max resolution and max color space (this last within reason / as appropriate) in a lossless format.
Quote:
|
That depends on the size and quality of the reader display too.
|
FWIW, I downloaded vol01 (text wrap) Roughing It and browsed through it on the PC and looked at image sizes, and then had a look on the Nexus 7 (resolution 1200 x 1920, portrait mode) and Moon+.
I saw the max image size is indeed about 100k, and limited by a max width of 600 pixels.
The images looked pretty nice on my Lenovo X220 (1280x800), Calibre viewer, at about my normal half-screen column width, about 650 pixels. They were displayed in the native image resolution, not enlarged. As I increased the column width, the image formatting showed wider margins, which start to look odd at some point. But overall, quite acceptable; IMHO, very nice images at that size.
The result on the Nexus 7 is less attractive. The high resolution means the images must be interpolated to fill the standard reading width (1200 pixels - margins). Some still look fine, but most already show softness at casual inspection, exaggerating the difference between the crisp text and the illustrations.
My request would be that you use images with larger dimensions as a first necessary step for display on what must be the continued direction of devices towards higher resolution displays.
I'd like to see images of at least 1100 pixels wide. If the book is four times the size, I care not one whit.
I suspect that larger scale images might tolerate some jpeg compression, if required.
Actually, I will widen that and say, that while manual compression methods like squeezing to 16 shades or shrinking images may be of use, my general preference would be to keep 256 shades (or 3x256+transparency) and sufficient resolution, and let the compression algorithm do the work. I would expect better results doing it that way more often, and it's going to be much faster.
To be specific about what I mean by "better results" and "manual compression", I would expect a 1kx1k image with 256 shades of gray, shrunk using the required jpg compression to give a certain filesize (say 100k), to give a better image than would be achieved by force-reducing the shades of gray to 16, force-reducing the resolution to 512x512, and again picking a level of compression to give the same file size, when displayed at full resolution. The "forced" operations I am calling manual compression.
Once the images fill the display, then I (or anyone) could compare the differences between a jpg and png, or 2 versus 16 versus 256 actual shades.
If you care to attach sample images to posts, I can put them in the book and have a look.
Last comment: the large patches of light in the images are glaring in Moon+ "night mode" (light text on dark background), but I don't know if anything can be done about that.