#55 SVG icon (redrawn)

[FeRD]

I'm putting this in "patches" for want of a better category, though it doesn't contain patches. (But I do have a Git branch I can open an MR from, on request!)

An incredibly, incredibly long time ago, a user asked after the SVG sources for the MComix icon, something I'd also been looking to track down. (I thought I'd mentioned it in some discussion here somewhere, but I don't see anything.)

Anyway, the response from Oddegamra back in 2011 was that the original artwork for the logo wasn't available, but oxaric might have it.

Those files never materialized.

So, I ended up recreating the icon from the ground up in SVG.

It didn't start that way. I was hoping I could just have Inkscape trace the (incredibly high-res) PNG file, "clean it up a little", and that'd be that. But it never worked out that way. Its traced features were far too complex, with thousands of path elements just to draw even a simple curve.

So, I started the process of painstakingly "tracing over" the bitmap using vector primitives, with minimal vertices, to reproduce the logo in as compact and optimized a form as possible. I'd work on it for a bit, then not touch it for months, eventually go back to it... off and on and off and on.

So, finally, three years and dozens of Inkscape crashes later, I finally have something that I'm not embarrassed to admit I'm responsible for. It's not a perfect reproduction of the original bitmap, but it's pretty damn close. I look at it and I mostly just see the flaws, of course. But I can finally admit that there are a few aspects that I like better than the original logo, to balance out the ways in which it's lacking.

Plus, and this is no small point: The filesize of the optimized version is 5.9 KB. The unoptimized SVG with all of the Inkscape "stuff" still in it is 16 KB.

The PNG is 2.3 MB.

Both files are in the artwork/ directory in the svg-icon branch of my fork, but I'll also attach the optimized, < 6 KB version here for examination and critique. Be brutal.

[FeRD]

I was really hoping that would just display right in the issue. Let me try again as an attached image.

Ugh. Well, since that apparently won't work, here's a link to the file in my Google Drive space. At least it's easily viewable there. https://drive.google.com/file/d/1BKKYDyq5OwcvJUozfWNKcT9VFVHN3r7U/view?usp=sharing

[Oddegamra]

That's simply awesome! It's easy to see that a lot of work went into this. Very much appreciated! Plus, this will make it easy to provide better application icons for higher resolutions.

I'd welcome a pull request. Unless you see a reason to keep the larger of the two SVGs, it would probably suffice to keep the optimized version. Feel free to add yourself in strings.py to ARTISTS as well.

[FeRD]

That's simply awesome! It's easy to see that a lot of work went into this. Very much appreciated! Plus, this will make it easy to provide better application icons for higher resolutions.

That is absolutely my entire thrust for doing this. Windows now supports application icons up to I think 1024×1024, a top size of 48px no longer remotely cuts it. And both macOS and Linux have long preferred straight SVG icons to bitmaps, period, so they can make UI elements freely scalable don't have to worry about hitting fixed size points.

Unless you see a reason to keep the larger of the two SVGs, it would probably suffice to keep the optimized version.

The only reason I can think of is in the interest of having the "original artwork" available, since there are elements in the Inkscape version that are lost on optimized export. (For example, the spirals in the inkscape version are actual spirals, which is a sodipodi shape primitive — #WHOKNEW? In the optimized straight-SVG version, all that parameter metadata gets dumped and they're just simple paths.)

So, there is (arguably) some detail worth preserving in the larger file, enough that I'd rather not be in possession of the only copy.

But it doesn't need to be in the main repo itself, agreed. One possibility: if you create a new branch in the project repo for "artwork" or whatever, I can submit a pull request to merge the larger version (or both versions) there, and a separate one to commit just the smaller file to the master branch. (Once I've addressed the issues @aaku brought up.)

[Oddegamra]

In that case, let's keep it simple and just keep both versions. Having a branch no one ever uses just to have an additional file there seems to be overkill. The "original" version could be renamed to "mcomix-vector.svg" and the smaller one to "mcomix-vector-optimized.svg" - or anything else you prefer, really, as long as the name allows to draw conclusions as to their origin/intended use.

[FeRD]

Sure, that works.

I was actually thinking just mcomix.svg, for the optimized version (that's how I have it on my branch, currently), since that's what it is, and that's also the name it should be installed under.

The original-artwork file we can of course name as descriptively as we like, and there's always the option to include a README_SVG.txt or whatever in the directory to explain in more detail.

[Ark]

Thank you for going into this issue. I few comments from my side, based on my own impression:

• Overall shape looks good.
• The color of the top fur should not get brighter towards the top, I think, because it lowers contrast, making the fur less visible and recognizable as fur (compared to the skin color). The original only gets darker towards the top, which is better IMHO, evening out the bright and dark parts of the image. (Compare the histograms in GIMP to see what I mean, you will notice that the original peak in the midtones really is closer to the center of the histogram.) Also, I like the hue of the fur in the original design a bit more for similar reasons.
• The hairline is not pitch black compared to the other outlines in the image, making it difficult to tell whether this is intentional or not.
• The respective two lines for each of the ears should be a bit closer to the original design, as I think that would make the ears look a bit … funnier.

[FeRD]

• The hairline is not pitch black compared to the other outlines in the image, making it difficult to tell whether this is intentional or not.

Huh... you're right, and that was entirely an error on my part. The outline and fill are one element there, and I'd set the opacity to 85% when adjusting the gradient — which, of course, affected the stroke color as well. I'll fix that.

• The color of the top fur should not get brighter towards the top, I think, because it lowers contrast, making the fur less visible and recognizable as fur (compared to the skin color). The original only gets darker towards the top, which is better IMHO, evening out the bright and dark parts of the image. (Compare the histograms in GIMP to see what I mean, you will notice that the original peak in the midtones really is closer to the center of the histogram.) Also, I like the hue of the fur in the original design a bit more for similar reasons.

You've hit on one of the last things I changed before posting this, and one of the aspects I was most on the fence about. I had a bear of a time with the interactions between the hairline, the coloring above it, and the outline(s) of the entire face. Mostly because I was trying to create the hair shading, as I said, as just one gradient fill laid over the upper parts of the face, tinting what was behind it to add the darker color.

I've finally admitted that's never going to work, so I've broken out the shading above the hairline into a separate element that's placed inside it, on top of the face circles. Actually, two of them, one for the hair, one for the darker inner-outline coloring around that area.

It's really tricky to get those all to come together correctly, especially where the hairline meets the black outline for the entire face. (In fact, if you notice, there are significant errors in the original at those spots, with one side having a random light-colored triangle nestled in there, and the other side a big black one.)

Anyway, I think I've finally got it, and that entire region is now much closer to the original (except for those errors). Screenshot attached, of the re-worked upper face in progress. How does that look?

• The respective two lines for each of the ears should be a bit closer to the original design, as I think that would make the ears look a bit … funnier.

You're referring to the two hairs sticking out (at least, that's how I've always interpreted them) in front of each ear? OK, I'll take another look and try for a closer match.

[Ark]

Thank you for incorporating some of the changes I proposed. The screenshot indicates that it is much better now.

FYI, I can download and open the SVG you attached at the top post just fine, so please continue attaching SVG files.

You're referring to the two hairs sticking out (at least, that's how I've always interpreted them) in front of each ear?

I think so, yes. Actually, I was thinking of them as hairs in the beginning as well, but at some point I started thinking of them as lines supposed to shape the auricles. Now, I am not sure anymore which interpretation is closer to the intended meaning. Anyway, the closer to the original, the better, whatever they are, I think.

Also, thank you for fixing the errors you caught, I noticed them as well but kind of got used to them … but not anymore, thanks to your effort!

[FeRD]

I've mostly got this finished, just two more things:

1. Take another pass at the ear-hair shapes, as mentioned
2. (I only just belatedly thought of this) I need to check what the artwork looks like when it gets scaled down to sizes like 48px or 32px. I may need to thicken some of the lines, if they don't show up clearly enough at those sizes. (Or I may need to thin some, if they should disappear when rendered that small.)

[FeRD]

OK, here's a new Google Drive link: https://drive.google.com/file/d/1arhgrGVvwngBfnsLLq5H0Ze_RRGAe9Ab/view?usp=sharing

For the file I'm also attaching here.

[FeRD]

And here are comparisons, against both black and white backgrounds, between the current set of icons, and new ones exported from the new SVG (at 16, 24, 32, and 48px), along with additional 64, 96, 128, and 256px icon sizes exported from the new SVG artwork.

[FeRD]

Shoot, I should've included mcomix/images/mcomix.png (the 212x159px version) in there.

[FeRD]

artwork/mcomix-redrawn.svg (original) and artwork/mcomix.svg (optimized) are updated on my branch, and I've added a README explaining each of the three files in the directory.

I haven't touched anything inside mcomix/images/ yet; the PNG exports I used to create the comparison images are just sitting on my local machine for the moment.

[Ark]

Nice, it looks much better now, even better than the original, in my opinion. There is one detail, though, that drives me crazy, and that's Face/R.ear/path995 (the main area for the ears, not the highlight part of the ears) which is too bright at the top. From what I can see in the SVG file, it is almost white (gradient stop color fffffeff), making it look as if some kind of grease accumulated there!

(Rant) This issue is more readily apparent if you use a uniform gray background instead of a black or white one. GIMP has gotten a lot better in recent years with respect to color stuff, where one of its improvements is using a gray theme by default which greatly helps evaluating colors. Also, for some reason, GIMP, unlike Inkscape, has no problems using my monitor's color profile. On top of that, SVG and/or Inkscape seems to perform color computations in nonlinear light instead of linear light, something which is wrong on so many levels. (See https://news.ycombinator.com/item?id=34816918 for starters.) However, that shouldn't matter too much here, as long as the result is pleasing to the eye. Anyway, as a result, I trust GIMP more than Inkscape to do the color stuff correctly, especially when it comes to scaling images or rendering images at different sizes, for that matter. (/Rant)

Luckily, there is an easy way to clean the monkey's ears. Face/FaceInner has a gradient stop at fddabdff, and replacing the almost-white stop color mentioned above with that one makes the grease go away.

Did I mention incorrect color computations when scaling? Yeah, I am not sure whether some SVG standard forces us to apply it, or whether every application is free to choose how it's done, in which case I would trust GIMP more than Inkscape to render raster images from vector images correctly.

Which is basically my next question. How do you render the PNG files? In case you do not already do it this way, I think one should render the PNG files at their respective target scales directly from the SVG files (instead of, say, rendering a huge raster image first and then creating PNG files by downscaling from raster image to raster image). And, as I said, I trust GIMP more than Inkscape to do this job correctly (although I have no proof).

[FeRD]

There is one detail, though, that drives me crazy, and that's Face/R.ear/path995 (the main area for the ears, not the highlight part of the ears) which is too bright at the top. From what I can see in the SVG file, it is almost white (gradient stop color fffffeff), making it look as if some kind of grease accumulated there!

Well, we can't have that!

...Kidding, I adjusted the gradient, though perhaps not enough for your liking. Take a look and see what you think.

I also made significant other changes, mostly out of necessity:

• Reworked the layer stack again, so that the drawing composes organically in a way that lets the strokes and upper layers hide a lot of the "seams" below, so things don't have to be exact.
• (As a result of the above, for example, the face is now a perfect circle, because its outline is literally that: Just a stroked, unfilled circle primitive, laid atop all of the shapes below it. Before it was connected to the inner "ring" for the face (which was provided by its fill), so a lot of other stuff was laid on top of it. Now it's at the very top of its layer.)
• The inner circle that makes up the face is now actually centered inside the outline. Before it was... not, let's just leave it at that. (Not so far off that the offset wouldn't average to 0 when the drawing was scaled down below ~200px wide, but I'D still know it was wrong.)
• Realized the hairline was crazy skewed, and reshaped it for better symmetry. I also reduced the path to just a pair of arches, so it's nothing but a really wide McDonald's logo now. (Before it connected with a copy of the upper skull outline, which was... decidedly not a perfect semicircle, as a result.)
• Had to re-shape the hair completely, to match both the new hairline angles and the face re-centering. And I had to completely re-do the gradient, because I stupidly still had it set to Multiply blend mode. (A relic of when I was trying to implement it as merely a tinting of the face's background features.) That meant that, even though it was at 100% opacity, you could still discern the "seams" at the edges where it overlapped (or didn't) the border between the inner face-circle and the "ring" around it. Now, the hair is an opaque radial gradient fill with no blending, so it's defined only by the shape of its path. But the colors are all slightly different, since they had to be changed to compensate for the loss of the Multiply blending.

I've now reached the point where I've done everything I want/need to do with this. So, from my POV the latest version (attached) is "finished". But that doesn't mean I'm not open to making further changes on request.

Also attached, an updated set of exported-icon comparisons (on gray — #666666, in fact, because it amused me — as requested), in an expanded set of sizes. (Though I again forgot to include the 256px version of the old icon.) The various-sized icons are also now committed in my branch, as /artwork/mcomix_<size>.png. Where <size> is just a 2-4 digit number. (I exported sizes from mcomix_16.png to mcomix_1024.png.)

...The rest of the discussion re: exporting, color, etc. I'll respond to separately.

[FeRD]

Which is basically my next question. How do you render the PNG files? In case you do not already do it this way, I think one should render the PNG files at their respective target scales directly from the SVG files (instead of, say, rendering a huge raster image first and then creating PNG files by downscaling from raster image to raster image).

Oh, no, they were exported directly from the SVG file of course. That's why they're so much sharper than the previous versions, which were clearly scaled down from the large PNG. No, I never go to pixels until absolutely necessary, because pixel artwork is evil and must be destroyed. (I can tolerate — grudgingly — bitmap textures in 3D modeling, but only because we're still waiting on the technology with enough power to render those obsolete as well.) Given that I'm a Linux user, once mcomix.svg is installed as the application icon I look forward to never seeing a fixed-size bitmap version of that image ever again.

And, as I said, I trust GIMP more than Inkscape to do this job correctly (although I have no proof).
[...]
Did I mention incorrect color computations when scaling? Yeah, I am not sure whether some SVG standard forces us to apply it, or whether every application is free to choose how it's done, in which case I would trust GIMP more than Inkscape to render raster images from vector images correctly.

I mean... you really shouldn't, since the GIMP isn't actually involved in the process at all.

Either application is just going to call out to its SVG plugin to interpret the code for the drawing. Whether it's Inkscape exporting, or GIMP importing, it just says, "Give me this artwork rendered on an X × Y grid of transparent pixels" and it either loads or saves whatever comes back. GIMP has no influence over the color processing of the render, because it never sees the individual vector components of the drawing, to have any influence over things like how colors are computed. It's entirely at the mercy of its svg importer, because all it gets handed is a two-dimensional pixel matrix.

GIMP's file-svg plugin is built using librsvg, whereas Inkscape's renderer is based on libpoppler. (Like everything else, they both use libpng16 to write the output file, naturally.)

In theory the choice of SVG rasterizer can lead to any number of differences, some potentially severe. But primarily — unless you're using QtSVG, which is shit at everything — major visual differences will tend to be in edge-case areas like font rendering and text layout. (And maybe blending, if you're dumb and leave some fill set to Multiply instead of Normal. But who's stupid enough to do that?)

In drawings that don't contain any text or blends, and are constructed entirely out of opaque-colored vector primitives (like the MComix logo), there's little chance of significant differences. One or the other library would have to be badly out of spec for that to happen, and they've both been in use long enough that that's not really a worry.

But if GIMP is any better or worse than Inkscape at anything to do with SVG rendering, it's entirely because librsvg is better/worse than Inkscape's raster engine.

Anyway, I did try a set of GIMP exports of the previous version of the artwork, and various image diff techniques confirmed they were virtually identical. The only discernible differences were due to the exports being slightly different sizes, but that was on me. The drawing was previously 3540px × 2650.667px, a truly weird size with an aspect ratio of ~1.3355129. (And the artwork on the page was slightly smaller still.)

When I exported from Inkscape the first time, I had it export the Drawing, which it scaled accurately, producing icon dimensions like 256px × 190px. GIMP's import, OTOH, used the entire page size, which rounded to 256px × 192px (a perfect 4:3). Once I corrected the document page size to 3540px × 2655px (also a perfect 4:3, both are multiples of 855px), and told Inkscape to export the entire page, it produced the same PNGs as the GIMP.

[FeRD]

Inkscape's renderer is based on libpoppler.

Sorry, no! Poppler is its PDF interpreter. Unsurprisingly given that it's the core function of the application, Inkscape uses its own internal SVG rasterizer.

[FeRD]

Plus, and this is no small point: The filesize of the optimized version is 5.9 KB. The unoptimized SVG with all of the Inkscape "stuff" still in it is 16 KB.

Those numbers have crept up slightly.

• The original Inkscape version is up to 19.8 KB, mostly attributable to the additional layers and groups, plus nearly a dozen guides I saved in with the file. which I added and used to align elements of the face and hair.

• The optimized version is up slightly to 6.2 KB, due to the extra groups created by the layer separations in the Inkscape file, plus added elements like the extra darker "ring" around the hair, or the fact that the face is now made up ofa separate filled circle and stroked circle, instead of a single filled, stroked circle.

[FeRD]

Well, I'm going to take the more than 2 weeks' silence (other than the sound of my own voice) to mean that everybody's basically OK with the version I posted a week ago on 2023-07-02, so I think it's time that I advance this branch into an actual PR against the main repo.

I propose that the PR...

1. Places both the optimized mcomix.svg icon and the "editable original artwork" versions of the redrawn icon SVG into the /artwork subdirectory.
2. Replaces all bitmapped versions of the icon (in /artwork and in /mcomix/images/) with same-size new ones exported from mcomix.svg, for a consistent visual appearance across the board.
3. Updates scripting and installable file configs to provide mcomix.svg as the primary/default form of the application icon, where applicable. (Basically, macOS and Linux.)
4. (Possibility: Also update the Windows icon assets to include the full set of default/dark/light theme variants — which for the application icon, at least, would all be the same icon. Apparently that's a permitted thing... a file just has to be provided for each of the three themes (determined by filenaming pattern), even if they're all the exact same file. Because Windows is dumb.)

[FeRD]

Oh yes, and also:

1. (Possibility: Use mcomix.svg as part of a new set of "document-style" MIME icons for the comic book archive formats, to replace the generic 'packing box' archive icons currently found in the /mime/ director(y/ies).)

While it's true that .cbr, .cbz, etc. files are technically archives, conceptually they're documents (and that's how the freedesktop mimetypes metadata categorizes them), so their icons should ideally reflect that.

Something like this (the generic GNOME "text/html" mimetype icon), but with the MComix logo and possibly an indication of the specific archive container format for each of the four types, would be more in line with the intent of the MIME database.

[FeRD]

WIP PR (that doesn't yet touch any MIME icons): https://sourceforge.net/p/mcomix/git/merge-requests/35/

[Ark]

I am sorry for the late reply, being busy and all. Yes, I do like the most recent version of your SVG ( https://sourceforge.net/p/mcomix/patches/55/#b904/329e ) the most.

Also, do not worry too much about that stuff regarding rendering details across different applications. I merely consider GIMP a black box for this kind of stuff. That is, even if GIMP happens to use an off-the-shelf rendering library, I would guess that their choice is better when in doubt. You kind of checked, so there is no need for guessing around anymore. The comparison PNG you have provided looks good enough, so let's just use the same rendering method you used there.

I will take a look into the PR in another post.

[FeRD]

Feel free to close this, since the discussion has moved to the MR. I don't see any major unresolved topics over on this side.