Key order in SVG-PNG converting

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
Post Reply
ngoral
Posts: 3
Joined: 2016-03-22T05:57:48-07:00
Authentication code: 1151

Key order in SVG-PNG converting

Post by ngoral »

Hi!
I had two questions here :)
1) I've recenty read the guide for command-line arguments. Before it I've knew nothing about settings options and image operators and though all cmd keys are equal. So that I've remembered we had a prolem with converting from SVG to PNG with transparent background.
We realised that command

Code: Select all

convert in.svg -background transparent -depth 8 out.png
did not set background transparent, but reoder keys to

Code: Select all

convert -background transparent in.sg -depth 8 out.png
did the thing!
Can anybody, please, explain how does it work?
Also it's interesting to me: in man it's said that "-background" is an operator setting, so it should set the value to be used by the following operation. But where's the operation in my command?

And the second question:
2) It's also troubles with SVG to PNG converting. We has an image with a following code:

Code: Select all

<svg xmlns="http://www.w3.org/2000/svg" width="1440" height="200">
<rect x="0" y="20" width="1440" height="160" fill="rgba(222,222,222,0.5)"/>
<rect x="51" y="1" width="180" height="180" fill="tomato" stroke-width="2" stroke="gray" stroke-dasharray="10, 5" opacity="0.75" />
<circle cx="359" cy="91" r="90" stroke="gray" stroke-width="2" fill="lightblue" stroke-dasharray="10 5" opacity="0.75" />
<polygon points="160,199 250,43 340,199" fill="lightgreen" stroke="darkgray" stroke-width="4" opacity="0.75" />
</svg>
Actually writing

Code: Select all

 stroke-dasharray="10 5"
have no effect on svg-image, but after converting it with IM it sets dashes equals to spaces with length 10. If writnig

Code: Select all

 stroke-dasharray="10, 5"
everything's doing fine. Is it a bug or a feature? However, that's not a qusetion.
I converted image with two commands on my Win7 machine:

Code: Select all

convert -background none plate.svg -resize 50% -depth 8 plate1.png
and

Code: Select all

convert -background none plate.svg -depth 8 -resize 50% plate2.png
Then I just compare them using command

Code: Select all

compare plate1.png plate2.png -compose Src -highlight-color White -lowlight-color Black :| convert - -resize 1x1\! -format '%[pixel:p{0,0}]' info:
and it gives the result "gray(0)" that means images are equal.
But after that I do the same on an Ubuntu 14.04 headless Docker container and it sais that the difference is equals to "gray(7)".
Why it behaves so and what's the matter here?

I'll be happy to hear any sujestions and ideas you have. Thank you!
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Key order in SVG-PNG converting

Post by snibgo »

Code: Select all

convert -background transparent in.svg -depth 8 out.png
In this command, "in.svg" is an operation that reads the SVG file and rasterises it (makes a pixel image). Where there are no SVG objects, the background colour is used. So "-background" must be set first.

stroke-dasharray: the SVG specification (https://www.w3.org/TR/SVG/painting.html) says the numbers are "A list of comma and/or white space separated". Most people use commas, so perhaps the internal MVG processor expects them.

Code: Select all

-resize 50% -depth 8
Resizing a 16-bit image introduces some new colours. Then you round these colours to 8 bits.

A slightly different result will come from first rounding to 8 bits, then resizing.

To see this, think of ordinary arithmetic.

1.4 + 2.4 = 3.8 <== this is exact.

If we round to integers first, then add:

1 + 2 = 3

If we add, then round to integer:

1.4 + 2.4 = 3.8 which rounds to 4.

3 != 4.
snibgo's IM pages: im.snibgo.com
ngoral
Posts: 3
Joined: 2016-03-22T05:57:48-07:00
Authentication code: 1151

Re: Key order in SVG-PNG converting

Post by ngoral »

snibgo wrote:In this command, "in.svg" is an operation that reads the SVG file and rasterises it (makes a pixel image). Where there are no SVG objects, the background colour is used. So "-background" must be set first.
Great, thanks! I thought about smth like this, or like some operation is simply ommited.
snibgo wrote: stroke-dasharray: the SVG specification (https://www.w3.org/TR/SVG/painting.html) says the numbers are "A list of comma and/or white space separated". Most people use commas, so perhaps the internal MVG processor expects them.
I surely know about separators in dashes in SVG and that's the fact that IM do not convert it in the same way that surprised me.
But I've never heard about MVG before. Now I ran quickly throught its page and think I should study it better. Thank you!
snibgo wrote: Resizing a 16-bit image introduces some new colours. Then you round these colours to 8 bits.

A slightly different result will come from first rounding to 8 bits, then resizing.
I thought it could be so, but I also thought that all keys have a strict order and it's doesn't matter, in which order you write them, they'll be processed in other way. I mean they set some flags, put some values and then it somehow rocessed. And also the fact that my Win computer process them in the same way and Ubuntu -- in different -- confused me a lot. So, why then they are different on Win and Ubuntu?
And however when I use SVG only 8-bit depth images are allowed. Does it mean, that while converting it puts some other 16-bit-depth colors on the edges? I really don't see, when these "complex" colors can appear.
Now I see, it's very important to pay attention to the order. So it's interesting task :)

Anyway, thanks a lot for your detailed answer!
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Key order in SVG-PNG converting

Post by snibgo »

ngoral wrote:I also thought that all keys have a strict order and it's doesn't matter, in which order you write them, they'll be processed in other way. I mean they set some flags, put some values and then it somehow rocessed.
Older versions of IM sometimes ignored the order of some options in the command line. This was confusing.

Newer versions of IM are stricter about processing the options in the same order as they are given.
ngoral wrote:So, why then they are different on Win and Ubuntu?
You probably have different versions of IM on those computers.


Rasterising a vector image usually anti-aliases the elements, which reduces the jaggedness of boundaries. This introduces new colours. For example, rasterising your SVG and enlarging a portion:

Code: Select all

convert plate.svg -crop 15x15+261+68 +repage -scale 1000% plate_ps.png
Image
The SVG has only 5 colours here, but the PNG has many more.
snibgo's IM pages: im.snibgo.com
ngoral
Posts: 3
Joined: 2016-03-22T05:57:48-07:00
Authentication code: 1151

Re: Key order in SVG-PNG converting

Post by ngoral »

Thans you again! You answer so fast I don't event have time to aknoledge previous answer :)
snibgo wrote: You probably have different versions of IM on those computers.
Yes i do. But they both older than version 6: 6.8 on ubuntu and 6.9 on Win. And it seens to me ubuntu is doing better, cause I believe results should be different :)
snibgo wrote: Rasterising a vector image usually anti-aliases the elements, which reduces the jaggedness of boundaries. This introduces new colours. For example, rasterising your SVG and enlarging a portion
Sure! how hadn't I thouht about antialiasing. that's so usual and obvious thing.. oh.. May it be that I'm trying to find a bug for a three days and understand nothing that's goin on :)

Great! Many thanks again. I feel like I'm doing better! :)
Post Reply