Jump to content

Help talk:Preparing for export

Page contents not supported in other languages.
Add topic
From Wikisource
Latest comment: 3 years ago by RaboKarbakian in topic tif vs png vs jpeg

problems with {{div col}}

[edit]

Kindle 5 does not do html5 columns.

Very sad.--RaboKarbakian (talk) 19:13, 7 January 2021 (UTC)Reply

EPUB engines in general don't generally do multiple columns well, as far as I know. The issue is this:
Item 1     Item 5
Item 2     Item 6
Item 3     Item 7
Item 4     Item 8
When rendered and then paginated for display:
Item 1     Item 5
Item 2     Item 6
-----------------  [page break]
Item 3     Item 7
Item 4     Item 8
This will be the same if you force the columns with a table or similar.
What you really want (and what was printed) is:
Item 1     Item 3
Item 2     Item 4
-----------------  [page break]
Item 5     Item 7
Item 6     Item 8
But I'm not sure that any layout engine knows how to do this. Inductiveloadtalk/contribs 19:30, 7 January 2021 (UTC)Reply
Amazon uses a propietary (enhanced) version "mobi". It "weighs" more.--RaboKarbakian (talk) 19:44, 7 January 2021 (UTC)Reply
I don't know a lot about the MOBI format, and less about whatever layout engine Amazon uses, but I imagine the considerations are somewhat similar. Inductiveloadtalk/contribs 20:00, 7 January 2021 (UTC)Reply

Known export failures to be reviewed after fixes

[edit]

tif vs png vs jpeg

[edit]

Here is a fine example of image file weights. This was a featured picture and the jpeg was used (I suspect) to allow the front page to load more quickly.

--RaboKarbakian (talk) 14:44, 24 February 2021 (UTC)Reply

This is an example of a photograph-style image where JPG is probably is indeed the right choice. In particular, the image/texture noise across the whole image is pretty incompressible by lossless means, and the reason JPG can compress it harder is that it is allowed to throw away small variations and/or allow artificial noise artifacts to creep in. If this has a flat background and no image noise, I suspect you would not see such a large size difference.
In particular, when re-scaled to 600px, the JPG is ~10 times smaller, probably because the scaling the noise down in JPG "smears" it and that makes it more easily compressible, whereas with PNG, because it's not smearing the data, the noise is still just as incompressible.
It's a matter of right tool for the job. Inductiveloadtalk/contribs 12:24, 26 February 2021 (UTC)Reply
It becomes second nature for an artist (truly, I can only speak for myself) to do the work starting with tif, png, or jp2, saving in the format native to the software, and exporting the final product to the best format for that purpose. Which includes scaling.
The very best here would be if the full size image could be uploaded as png and subsequent thumbnails could be generated into jpeg or gif (as svg gets generated into png) for page loading speed and for the efficient use of space, which is quite limited on dedicated devises.
Even nicer would be to also upload gray versions of color images so downloaders could toggle a choice. Two of my devices are monochromatic, one is color. I tried to determine a software method of grayscaling (off the top of my head I could name -- by name -- 8+ different single steps to do this) but there was not a single way to reliably get the best. Bumping the contrast and other tricks might help.
We can continue to discuss the best formats, but without knowing what the display hardware is the discussion is old and somewhat useless, meaning, you win.
Having an exporter that will optimize for size and improve images for monochromatic displays and/or artists who understand the needs of wikis not commons and encyclopedias -- now that is a new and more interesting discussion.
For any of my devices, the "qualities" gained by using png are not worth the space requirement. Having the jpegs each made once from an original png, tif or other lossless format is a plus (like virgin olive oil, from non-pressed pits) would at least cause me to think that the software writers knew what they were doing. A toggle for artist provided gray images or for thoughtfully contrast boosted, machine greyed images would be "Featured Book" quality and something brand new and cool.
Or, for sure, you can continue to lecture for png and against all else....--RaboKarbakian (talk) 14:36, 26 February 2021 (UTC)Reply
I did say in this case JPG is, indeed, better. What more do you want me to say? If you want the exporter to be able to transcode PNGs to JPG, that's a valid request (because, yes, a reader device probably isn't getting the most out a PNG anyway), as is an option to contrast-boost images somehow (CSS has filter: contrast(xxx%), but I doubt Kindles understand it). Both of these things belong at Phabricator. Have you considered turning the contrast up on your Kindle screen? However, deliberately trashing the informational content of the images on-wiki because they look better on an old Kindle doesn't seem ideal to be. Crashing the black levels is the image equivalent of the loudness wars. Turn your stereo up to compensate for rubbish speakers, but don't master the CD so it clips.
If you just want to rant about the "the software writers", then I think we can be done here. Inductiveloadtalk/contribs 15:13, 26 February 2021 (UTC)Reply

no images

[edit]

My mobi "download" is indeed lightweight, but it has no images at all!--RaboKarbakian (talk) 15:11, 19 May 2021 (UTC)Reply