It produces a 75MB file. If I export directly from the editor, the file size is 7.5MB - this is the correct size. Can anyone suggest why this might be?
I tried your suggestion - no go. I've got access to the source SVG. It doesn't open in a standard editor but does in a coding editor; it seems the SVG is corrupted. I'll rewrite and try again. If I fnd out anything useful I'll update my post. Thanks chaps.
Just a follow up. I rebuilt the design. Same result. The fault is with Inkscape. There may be a clue in file size (MB) being 10 times the expected. For what it's worth: the design is 7 words converted to paths but left grouped as words, then these 7 groups, grouped together to make 1 object. I masked this group with a JPG (6MB) for a texture and added 1 filter (roughen). A very simple structure. I can't get access to the file again, soon, so I can't help with a useful bug report - polz.
The problem is fairly obvious. The command line export isn't grokking da grouping. It's seeing 7 basic groups plus 1 more group to harness those 7. That's 8 in all. Then it's multplying the mask at least 8 times which is bloating the export - it seems to be repeating this in a loop because the CL export is very slow. Like I said, I won't have access to the file for some time so I can't test whether it's a corrupted file or a straight bug. Tom Hanks for the help.
Okay... so I'm trying it on this machine (Ubuntu, but Inkscape 1.3 beta) and I created the svg file (attached). By default converting text to path apparently now gives a single path (so I split it and grouped it instead). I then masked and roughened as you explained. When performing the instruction... Inkscape crashed.
Some details I missed to reproduce: did you embed or link the bitmap? (not sure if it's even relevant - I embedded it)
(never mind previous comment - this was a bug when using a non-existing ID)
So the result is a 50 MB file in 1.4-dev and a 75 MB file in 1.2 (stable). The file is not exactly the same, so that's not the issue.
With a width of 10000px (and in my case a similar height), this becomes a 100 megapixel image. This is pretty big by all standards.
When setting the width to 5000px, it becomes 14MB, and to 2000px the file is 2.3MB.
When setting the width to 5000px, it becomes 14MB, and to 2000px the file is 2.3MB. Inkscape isn't the best in optimizing PNG
While a 5000x5000px image contains 25000000 pixels you get just 4000000px which means a 6,25:1 ratio and exact 14MB:2,3MB. And check out compression factor.
If you'll forgive me, you've missed the point. Export from editor = 7.5MB (seven and a half); export via CL = 75MB (seventy five), optimisation isn't the problem. Also when I removed the mask (yesterday) the discrepancy vanished - editor and CL were par.
Clearly. My settings are all default. But a 10x difference is nuts. This file and similar ones can't be uploaded because of server limits. So whether it's a literal or strategic bug, it's a bug.
I got a similarly structured/sized SVG and installed Inkscape (1.2). CL export generated a PNG of 75.1MB. I then compressed the PNG with OptiPNG (default settings) and the result was 68.1MB - a ~10% reduction. Normally I'd expect ~30%. The data in the PNG must already be compressed so the large file size doesn't seem to be explicable as lack of compression. I'm still going with repeated data. Here's the OptiPNG output for the file.
Actually I don't think the software is evolving backwards. It's getting more consistent (in that the result over the GUI and from the command line are the same).
Now, what would be nice, is that the preferences would contain some settings for PNG en JPG quality. This could then contain things that for example the GIMP dialog also shows.
Even if only the compression level (and optionally the Pixel format) could be available... this would allow for granularity on what quality vs size you prefer.
Or for JPG the quality slider.
We could even take it a step further, and have these as command line parameters (allowing you to tweak your quality settings on CLI exports). But maybe this might take us too far.
If you think this important enough, you could file a feature request in Gitlab... (feel free to use the images/screenshots if you want to)
Linux Mint 21, Inkscape 1.2
Hi.
I'm exporting a design from the command line using:
inkscape --export-type="png" --export-filename="core_eight.png" --export-id="ce" --export-width=10000 --export-id-only all_cores.svg
It produces a 75MB file. If I export directly from the editor, the file size is 7.5MB - this is the correct size. Can anyone suggest why this might be?
Thanks.
Could be there´s no compression taken into account. Default compression (6)=9,8MB, no compression=283MB
I'm using Ubuntu 22.04.2 LTS, Inkscape 1.2.2 (1:1.2.2+202305151914+b0a8486541)
I try to stick to using actions if possible as it's easier to keep track of things.,
inkscape --actions="export-type:png;export-filename:core_eight.png;export-id:ce;export-width:10000;export-id-only;export-do" ./randoms.svg
I've attached the sample .svg file ( named randoms.svg) that I used. The yellow blob in the bottom middle has the id of 'ce'. Exported png is 750kb.
Is the object you are exporting a vector object or an <image>, if the <image> is a jpg, probably gets resampled.
I tried your suggestion - no go. I've got access to the source SVG. It doesn't open in a standard editor but does in a coding editor; it seems the SVG is corrupted. I'll rewrite and try again. If I fnd out anything useful I'll update my post. Thanks chaps.
Just a follow up. I rebuilt the design. Same result. The fault is with Inkscape. There may be a clue in file size (MB) being 10 times the expected. For what it's worth: the design is 7 words converted to paths but left grouped as words, then these 7 groups, grouped together to make 1 object. I masked this group with a JPG (6MB) for a texture and added 1 filter (roughen). A very simple structure. I can't get access to the file again, soon, so I can't help with a useful bug report - polz.
If you are exporting to png, it should not make any difference - unless there are differences between the images.
Can you convert both files to bmp, then diff ?
The problem is fairly obvious. The command line export isn't grokking da grouping. It's seeing 7 basic groups plus 1 more group to harness those 7. That's 8 in all. Then it's multplying the mask at least 8 times which is bloating the export - it seems to be repeating this in a loop because the CL export is very slow. Like I said, I won't have access to the file for some time so I can't test whether it's a corrupted file or a straight bug. Tom Hanks for the help.
Okay... so I'm trying it on this machine (Ubuntu, but Inkscape 1.3 beta) and I created the svg file (attached). By default converting text to path apparently now gives a single path (so I split it and grouped it instead). I then masked and roughened as you explained. When performing the instruction... Inkscape crashed.
Some details I missed to reproduce: did you embed or link the bitmap? (not sure if it's even relevant - I embedded it)
(never mind previous comment - this was a bug when using a non-existing ID)
So the result is a 50 MB file in 1.4-dev and a 75 MB file in 1.2 (stable). The file is not exactly the same, so that's not the issue.
With a width of 10000px (and in my case a similar height), this becomes a 100 megapixel image. This is pretty big by all standards.
When setting the width to 5000px, it becomes 14MB, and to 2000px the file is 2.3MB.
Inkscape isn't the best in optimizing PNG.
Yup, the bitmap was embedded. I had no crashes, though, or any other swerves from Inkscape.
No, I didn't have a crash anymore either. I used a non-existing ID that I exported (forgot to set the ID in Inkscape).
I didn't save my edit on the previous comment - please reread.
While a 5000x5000px image contains 25000000 pixels you get just 4000000px which means a 6,25:1 ratio and exact 14MB:2,3MB. And check out compression factor.
If you'll forgive me, you've missed the point. Export from editor = 7.5MB (seven and a half); export via CL = 75MB (seventy five), optimisation isn't the problem. Also when I removed the mask (yesterday) the discrepancy vanished - editor and CL were par.
I don´t miss the point as per #2. Which compression factor is used? Probably CL and UI use different settings.
Clearly. My settings are all default. But a 10x difference is nuts. This file and similar ones can't be uploaded because of server limits. So whether it's a literal or strategic bug, it's a bug.
I got a similarly structured/sized SVG and installed Inkscape (1.2). CL export generated a PNG of 75.1MB. I then compressed the PNG with OptiPNG (default settings) and the result was 68.1MB - a ~10% reduction. Normally I'd expect ~30%. The data in the PNG must already be compressed so the large file size doesn't seem to be explicable as lack of compression. I'm still going with repeated data. Here's the OptiPNG output for the file.
--------------------------------------------------------------------------------------------
10000x9221 pixels, 4x8 bits/pixel, RGB+alpha
Input IDAT size = 74976985 bytes
Input file size = 75086924 bytes
Trying:
zc = 9 zm = 8 zs = 0 f = 0 IDAT size = 68136199
Selecting parameters:
zc = 9 zm = 8 zs = 0 f = 0 IDAT size = 68136199
Output IDAT size = 68136199 bytes (6840786 bytes decrease)
Output file size = 68136314 bytes (6950610 bytes = 9.26% decrease)
--------------------------------------------------------------------------------------------
Yes, I did miss that point indeed.
LOL... I have some crappy news for you... in Inkscape 1.4-dev both exports result in the same size... being 49MB for me.
This software is evolving backwards. Can't even paste accurately. Thanks anyway.
if you use jpeg files in the image, then it's usually just a case of them being resampled to png to avoid data loss when editing.
If you are happy to use optipng, in particular on Linux, then I would use that as post processing.
However, if you convert to bmp first, then all other variables are eliminated. There is no magic happening.
I suspect it's just simple jpeg > png resampling which causes the issue.
As a side note, for creating jpeg from bmp / png :
sudo apt install jpegoptim
Actually I don't think the software is evolving backwards. It's getting more consistent (in that the result over the GUI and from the command line are the same).
Now, what would be nice, is that the preferences would contain some settings for PNG en JPG quality. This could then contain things that for example the GIMP dialog also shows.
Even if only the compression level (and optionally the Pixel format) could be available... this would allow for granularity on what quality vs size you prefer.
Or for JPG the quality slider.
We could even take it a step further, and have these as command line parameters (allowing you to tweak your quality settings on CLI exports). But maybe this might take us too far.
If you think this important enough, you could file a feature request in Gitlab... (feel free to use the images/screenshots if you want to)