Looking for Volunteers for New Chapters for Sigil User's Guide

[Ashjuk]

Originally Posted by KevinH

Great! Thank you! I will stay with your earlier versions that used
NotePad++ for the general "open with" images. I really only need PageEdit in the chapter dealing with the Preferred External XHtml Editor as that is where it is most likely to be used, whereas NotePad++ would be useful to a number users in open with

Kevin

You're welcome

As you say some reference to NotePad++ might be a good idea for those looking for a good external html editor.

Ashley

[KevinH]

Okay, pushed everything I have now to the sigil-user-guide repo. I have updated the src_updated_20210222_01.epub that is attached to the first post in this thread.

For future-proofing, I plan to convert this manual to an epub3 with backwards compatible ncx and guide so that all readers can benefit. This will allow me to add richer semantics and role info.

But that will only come after we have it updated and released.

[Tex2002ans]

For most screenshots, just save it as RGB.

One way to save space on these screenshots is to throw away the Alpha (transparency) layer. This will chop it from a 32-bit image down to 24-bit (~25% filesize savings).

Let's take this as one example:

cover.png



RGBA (261 KB) vs. RGB (205 KB) = ~78% of the size

The alpha was useless, so in this case the RGB image is EXACTLY the same.

- - -

Again, PNG is great because it's LOSSLESS.

When you then take something with millions/thousands of colors (RGB) though, and try to squash it into a <256 color box (Indexed), you'll be destroying lots of information.

(See more detail below.)

Originally Posted by KevinH

If you feel that some specific images in the user guide had gone too far in that tradeoff, please let us know.

Nearly all of them, which is why I questioned it.

- insert-file-main.png
- tutorial-load-html.png
- tutorial-saved-epub.png
- [...]

See the difference between:



I super zoomed into a section, and you can see how:

In the original PNG, the icons/text are still perfectly crisp/clean.

In the Indexed PNG, it looks like they were saved as a JPG 50.

Originally Posted by KevinH

As for colour depth, does setting max number of colours to anything other than a power of 2 make sense?

Depends on what type of images you're running it on.

Although setting "Maximum number of colors" at 256 won't stop GIMP from using less if possible.

Keep that setting on 256 or 128 and you'll probably be fine.

The fewer colors, the more repetition the image has = higher compression.

BUT, the fewer the colors, the more loss/distortion occurs.

Images That Already Have <=256 Colors

Indexing this type is a purely lossless conversion.

Take icons as an example.

Let's say your simple icon has 32 different colors in it:

You may have saved it as:

• RGBA (RGB + Alpha).
  
  • 32-bit image (8-bit R, 8-bit G, 8-bit B, 8-bit Alpha)
• RGB
  
  • 24-bit image (8-bit R, 8-bit G, 8-bit B)
• Indexed
  
  • 8-bit image (<256 colors, so every pixel can be stored within a single byte)

RGBA (411 bytes) vs. RGB (360 bytes) vs. Indexed (271 bytes)

Choosing Image > Mode > Indexed and setting "Maximum Number of colors".

GIMP will test the image, and see "Oh, this icon only had 34 colors", so it will create a palette that's exactly 34 colors large.

How do you see how many colors there are in your Indexed image?

You can see this in GIMP by going to:

Windows > Dockable Dialogs > Colormap

Images That Already Have >256 Colors

Indexing this type is LOSSY.

There are many different algorithms/dithering methods to try to do this (posterization)... some tools are good, most are awful.

The lower # of colors you allow, the more distortion occurs.

See the above zoomed in images.

And again, when you have simple images, like a menu item. Okay, great, you can REALLY chop down on the colors.

But when you have large, complicated, colorful screenshots like the entire Sigil window (icons and all)... trying to cut that down to 256 colors is going to be AWFUL.

Originally Posted by KevinH

Ie. why 17 colours for your equations? I could see space savings from using 16 colours each represented as 4 bit wide fields with two fields packed into a single byte, but non-powers of 2 would seem to drop colour range with no associated space saving. Or am I missing something?

Biggest being the "4-bit PNG rendering bug", and bad support for 2-bit + 4-bit PNGs in some programs:

See the 2013 thread, "Sony Reader for PC -- not rendering 16-color png".

(You can see the "zebra striping" that occurred in my+GrannyGrump's old pictures.)

17 colors still kept it as a (barely) 8-bit image, so you have no bugs AND you still get large filesize savings compared to a full 256 colors.

(Of course, that low # of colors only worked because it was simple shades of black/gray. Colorful/complicated pictures, you probably wouldn't want to go that low. )

Originally Posted by KevinH

BTW, I found a program on github called pngquant2 that seems to be using k-means cluster analysis on colours to determine true number of degrees of freedom represented by the colours actually used to determine the "best" set of palette colours to choose.

I'm really disappointed the guy who wrote pingo/ScriptPNG took down so many of his great image compression articles, but they can still be found via Archive.org:

https://web.archive.org/web/20161208...g-optimization
https://web.archive.org/web/20161003...ticles/truepng
https://web.archive.org/web/20161003...g-optimization

(There were many more, especially comparisons between all the different tools.)

I was able to recover this by visiting his website ~2016:

https://web.archive.org/web/20160601...ww.css-ig.net/

I think it was around 2018 that he "updated" his site to promote pingo, but he took down his entire article archive in the process.

[KevinH]

But can you and most people actually see a difference without "super zooming"? Seriously? I can not. And I really doubt anyone is going to be super zooming in on any of these images in Sigil's user guide. Given how easy it is to recreate these images as screenshots and how often they will need to be updated as gui interfaces change on each platform, if and when desktops go to 8k or 16k resolutions, we just recreate them.

The much much smaller file size with indexing and restricting it to a palette of 256 colours seems to be a very good tradeoff as smaller file sizes pays off in a multitude of ways when loading, and caching images in both an e-reader and in Sigil itself.
Especially when differences can only be seen when super zooming in.

I see no significant differences on a 4k+ retina display with these images at normal display sizes so the statement that at "nearly all of them" need to be reverted is just not something I can agree with at all.

So we must agree to disagree here.

[KevinH]

FWIW, I do understand about dropping the alpha channel, cropping, and restricting the number of colours and that it can end up being quite lossy. I understand that keeping high resolution images as originals is a smart idea and not using anything lossy until the final step makes great sense. And all of this makes even greater sense for print.

It is just that image file sizes on the web and in browsers trumps all of that for me as long as at normal display sizes no big differences are noticeable. Again, speed of loading, caching, reload, memory footprint, disk footprint, download size, bandwidth used all are greatly improved. Which is probably why Photoshop has a "save for the web" setting to begin with.

If this manual was destined for print, then I would agree with you. As it stands this user-guide will probably be viewed using Sigil and PageEdit in most cases as people play to learn and for that role, I think these images work well.

[Tex2002ans]

Originally Posted by KevinH

And I really doubt anyone is going to be super zooming in on any of these images in Sigil's user guide.

To read the text in the labels?

To read the text in the menus?

To read the text in the UI?

Look at the "Book.xhtml" text in the "super zoomed in" version.

It's as if you've rubbed your eyes in vaseline.

Originally Posted by KevinH

But can you and most people actually see a difference without "super zooming"? Seriously? I can not.

Yes.

And when you've converted hundreds of ebooks, and know where to focus (flat colors, edges of text), you can tell the fuzz/artifacts from miles away:

https://www.scantips.com/basics9jb.html
https://photo.stackexchange.com/ques...one-about-them

PNGs are lossless and excel at screenshots + charts/graphs/artificial images.

It's the reason why you want to use PNG >> JPG in this case!

Originally Posted by KevinH

So we must agree to disagree here.

It is just that image file sizes on the web and in browsers trumps all of that for me as long as at normal display sizes no big differences are noticeable. Again, speed of loading, caching, reload, memory footprint, disk footprint, download size, bandwidth used all are greatly improved.

We don't live in the age of Kindle 1 anymore.

Devices can now:

• "click-to-zoom" (to see the full quality image).
• have plenty of RAM.
• have plenty of space.

It would be like purposefully taking screenshots, shrinking them down to 800x600, blurring them... for absolutely no reason.

And we are talking 11 MBs... 11 MBs.

And 4 MBs of that was taken up by 1 4k + 1 2k image.

A single podcast is larger than this.

It's giving me flashbacks of the "Inline Greek JPG" + "Tables as Images" days when I first started making books.

I am back in Nam!

Originally Posted by KevinH

Which is probably why Photoshop has a "save for the web" setting to begin with.

That was because Adobe inserted a massive amount of metadata into the images.

You'd have a 1MB JPG with like 3MBs of garbage embedded in it.

"Save as Web" then removed the metadata + did some other potential settings (interlacing/progressive).

"Save as Web" for PNGs would also turn on higher compression instead of no/low compression + remove the Alpha channel if it's not used, etc.

Originally Posted by KevinH

But can you and most people actually see a difference without "super zooming"?

The "super zooming" was just to easily show the artifacts. And just how rotten/lossy Indexing the wrong types of images is.

Screenshots should stay PNG (RGB) throughout the workflow.

Lossless changes should be done (cropping, compression). Never destructive (resizing).

- - -

IF filesize then becomes an issue, then you go in descending order:

• Throw away the Alpha.
• + Losslessly compress.
  
  • PNG compression tools have gotten much better in the past 7+ years.
    
  • As you can see, I was able to compress another 3.2MBs (~22% drop) out of those PNGs.
    

If it's still an issue, then:

• Index (if possible, within reason).
  
  • Lots of text + little color? Yes.
    
  • Entire colorful screenshot of Sigil? No.
    

If the image is too complicated/ugly using that method, then go back to source and:

• crop to focus on relevant portion
• recreate at lower resolution
  
  • Like those original 4k images. Someone can re-screenshot at 2k or 1080p (or whatever).
    

If that's not possible, then:

• PERHAPS saving as a JPG.
  
  • Like the current cover may be smaller as a JPG.
    
  • PNG is usually larger for "photographic" images.
    
  • At least the JPG would still be millions of colors (vs. <256 Indexed PNG).
    

But always keep the original lossless source.

[Ashjuk]

Originally Posted by Tex2002ans

Throw away the Alpha.

As I said in a previous post there appears to be no Alpha channel to throw away in my images. (See attachment to previous post)

Originally Posted by Tex2002ans

Losslessly compress. PNG compression tools have gotten much better in the past 7+ years.

I don't know what application you are using but I downloaded what is supposedly the number 1 free lossless compression tool - PNGGauntlet - and running one of my uncompressed images through it resulted in an almost identical file size to the original.

I'm not saying you are wrong as you obviously have much more knowledge and experience than I, but following the above suggestions has not worked for me.

Edit:

I have just tried another compression tool - PngOptimizer - on the largest of the image files (tutorial-main-window.png) and the optimised file was approximately 10% smaller.
Whilst there has been some saving in my mind it is not that significant, and less than half of the ~22% you had mentioned.

_tutorial-main-window = prior
tutorial-main-window = post

https://www.mobileread.com/forums/at...1&d=1614079591

[KevinH]

@Tex2000ans, again I completely disagree. The maximum file size on MR attachments for epubs is 20meg and we were actually coming close with more images to come. File size does matter in any browser setting and engine and that is what Sigil is. You seem to be completely ignoring that in favour or things that typically can’t be seen.

[odamizu]

I am working on the Preferences chapter and need some help with the following:

• Under Appearance > Code View, the Mac preferences window has a Highlight Matching Tags option whereas the Windows screenshot does not have this. Is this option only available on Macs?
  
• Under Appearance > Main UI, what does High DPI Setting do? (Note: this setting is greyed-out on my Mac.)
  
• Under Appearance > Main UI, what's a good way to describe what Tweak Drag Distance does? (This is also greyed-out on my Mac.)
  
• In the Open Preferences Location section:
  
  • What's a brief description for what's inside the local-devtools folder?
    
  • I have a QtWebEngine folder in my Preferences folder. Is this a remnant from an old Sigil version? If it's relevant to Sigil 1.5.0, what's a brief description for what's inside?
    
  • I have a repo folder in my Preferences folder. Is this a remnant from an old Sigil version? If it's relevant to Sigil 1.5.0, what's a brief description for what's inside?

Muchas gracias for any assistance with the above

[Doitsu]

Thanks for updating the most difficult chapter of the User Guide!

Originally Posted by odamizu

Under Appearance > Code View, the Mac preferences window has a Highlight Matching Tags option whereas the Windows screenshot does not have this.

The Windows screenshot is outdated.

Originally Posted by odamizu

Under Appearance > Main UI, what does High DPI Setting do? (Note: this setting is greyed-out on my Mac.)

GUI controls of some apps aren't rendered properly on high resolution screens.
You can see an explanation of each option, if you hover the mouse cursor over the Detect dropdown box.

Originally Posted by odamizu

Under Appearance > Main UI, what's a good way to describe what Tweak Drag Distance does? (This is also greyed-out on my Mac.)

For more information see this post by DiapDealer.

Originally Posted by odamizu

I have a repo folder in my Preferences folder. Is this a remnant from an old Sigil version? If it's relevant to Sigil 1.5.0, what's a brief description for what's inside?

AFAIK, It's used for saved checkpoints.

[Ashjuk]

Originally Posted by odamizu

I am working on the Preferences chapter and need some help with the following:

Under Appearance > Code View, the Mac preferences window has a Highlight Matching Tags option whereas the Windows screenshot does not have this. Is this option only available on Macs?

Sorry about that - it must have been one that slipped through from the 1.4.3 screenshots that I originally started working on.

New version is here - https://drive.google.com/drive/folde...E03ldjIG-Cvks7

[KevinH]

- The local-devtools is a work folder generated when Preview's Inspector is used.
- The QtWebEngine folder is also a work folder that can cache and store things being used by Preview. Depending on version you may have a local-storage folder inside it as well.


Yes the repo folder is created to store Checkpoints and its contents should be managed via the Manage Repos checkpointing tool/menu.


Thanks!

[KevinH]

Both the local-devtools and QtWebEngine folders can be deleted safely when NOT running Sigil. They will be recreated automatically when needed.

repo and plugins should all be managed by Sigil itself. Users can edit things in plugin-prefs and it provides a place to store things that live on through a plugin being deleted and its new version installed (the update process).

[KevinH]

@Ashjuk,
One more change please. The image "preview-window.png" shows Preview showing on *old* version of the Metadata Editor and MetaData Icon in its image which is confusing since neither is in the most recent version of the manual.

So would you please recreate that image with Preview showing some other interesting image either from the current user-guide or the public domain Alice's Adventures in Wonderland epub used many tumes in the old user guide. I think you can download that epub here in MR's own repository. Otherwise I can post it as an attachment here. Just let me know.

[Ashjuk]

@Kevin,

Done.