Convert svg to b64 for gmic script?

How exactly would one go by doing what the title say? Cupid and heart are both svg, right?

I do not see any difficulty at all. I routinely open native SVG 1.1 files with gmic. It Just Works. See
gtutor_tileit for SVG files that I’ve rasterized simply through -input.

gmic -input ampersand.svg

leaves you with a ‘x’,‘y’,1,3 image on the list with channel data in [0,..255] ‘x’, ‘y’ dimensions come from the SVG file; tweak the SVG file with a text editor if you care to change image dimensions - or, quick and dirty, -r2dx. From there, -img2base64, no?

So, some of the base of shape images in gmic are already rasterized and all I need to do is to give it with enough resolution for most cases? Got it.

I wasn’t aware they were SVG. Only thought of them as base64 data. Makes sense though.

It just works for me, too. It seems to work by calling ImageMagick’s “convert”, which calls InkScape, which writes a PNG file and passes it to IM, and IM passes something to Gmic.

f:\web\im>%gmic% -input drop.svg
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'drop.svg' at position 0convert.exe: `%s' (%d) "inkscape.e
xe" -z "drop.svg" --export-png="C:/Users/Alan/AppData/Local/Temp/magick-689367OD
Ka6gMlfXw" --export-dpi="90,90" --export-background="rgb(100,100,100)" --export-
background-opacity="1" > "C:/Users/Alan/AppData/Local/Temp/magick-68936u9qFXStAs
t26" 2>&1 @ error/utility.c/SystemCommand/2029.
 (1 image 500x500x1x3).
[gmic]-1./ Display image [0] = 'drop.svg'.
[0] = 'drop.svg':
  size = (500,500,1,3) [2929 Kio of floats].
  data = (65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,6553
5,(...),65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535)
.
  min = 0, max = 65535, mean = 65016.9, std = 4726.46, coords_min = (249,98,0,0)
, coords_max = (0,0,0,0).
[gmic]-1./ End G'MIC interpreter.

I don’t know what would happen if Inkscape, and either ImageMagick or GraphicsMagick, were not installed.

Is there a way to have user utilize custom dpi size instead of using dpi builtin SVG. That on the line of what I was thinking of rather than rasterized image.

Something like a external SVG into base64, and then from the base64 data, ‘input’ would find that it’s a svg file, and the user would input dpi size and finally the rasterization is based from user input?

Code from G’MIC stdlib:

#@cli shape_cupid : _size>=0
#@cli : Input a 2D cupid binary shape with specified size.
#@cli : Default value: 'size=512'.
#@cli : $ shape_cupid ,
shape_cupid : check "${1=512}>=0"
  e[^-1] "Input a $1x$1 cupid binary shape."
  ir={round($1)}
  if !$ir 0
  else
    base642img[] \
"MiBzaG9ydCBsaXR0bGVfZW5kaWFuCjEgMjMwMSAxIDEgIzI2NDQKeJx1mOl3lEUWxm+n6aS7IUSQRQQEFA37FtkFVFAEBxHZEoKACwRQEUHU0fGM58y"\
"Zxa9z5i9AFBAhAZKwg8qACMM6CDgZIIQ9Kx0CmAHqzq/u2yR80A91nue5daveWm5tb2moNBSSkAiptCoq9RqToa6p3NVmMtyli2pzecp1IHWUke6R30"\
"wjyB9hfh0o97AMIw11D8kQ0mDXRga6VpLlWsoA10L6uQzpQ909XVy6u6hkulTp6lJkyamw1GhTGc33b2iGHHYR+RT8RVvIUReThKbI3+H/0wflGD512"\
"kT+oa3EaRt0M7mlEanFZ4X2QqdTLiLX8flK+5i+rWn36eb0MYqOyErT7eBp8rX2gz8Ej9H3iGww3Y5vZRg/QztvaqMuox13tAvpAdMX3JO0J+CX3AuG"\
"l904wytuvOFV9yLYF5wgG8Fy9xK6j1S4iWBvcBL23lLpXkH3kio3Bd1Tqt10sIdcczOkULtLws0Eu4GzwEypdbPJfxx8S3aC190i2aWPge+iu0idW4r"\
"uJDfcMvARuek+Ajsa7tT24O9lB33zuE3b4rdY1mtrw3zGPFtTZbm+K9/Qv+mM1Re6iPFKl2mM1Qp9R1Yxd1NJX8FXYptCDK2Ef0m5yfitgtcy7qsNMy"\
"i7iLY9IGsMW1Cvx5aylm94XGfYSgp0seF6w9aMyWLKt6HP76HbShFYCxaDCXCTYTvZqksYq4fp01KwA31dKjXE6ff6PthZ9uoyxrSL7AOr3KNyQD9gz"\
"B+Tg2CFe1yOGHaTf4Plrrv8BNYRq7eZi1OUqSN+7zJPJfCDGpJu6tdNXzmDPqRh6aHPShn8MDHXQ5+Ti8bD0l3HyiXa4u3ddZxcpT2ed9PxUtHAX5RK"\
"fA4Z/51UJXkmvJp+HYQ/Aa+BH2J8M3WCXKPfB+GPUzbgacYTxmNWNsGYHqSdmWb3vBn1jIcvop4IcZzKfKbKSdp1Td+2b9ajsyl/ClsC22H8/NrKoew"\
"p+pLQt8x2kzSDeT6lz1N2ofWjDlsue8hJ+p/QBeZXR30ziaEy2ndXx7BmA3st9le1JWPzstmOoBPYX2WNXzHbfPOrwT6LuKzQSazT+dbGauqaTcxW6S"\
"vUH/hVYZtDPNckbUewVZjtYeoNbEepqxzba8R/gvoCW4Q5iWLrQP3etoAYiMhlK8v60Yn2XW+7ZGUfZe+ZSPvyiJGIXKDOOdqVcXuJdr0hJ7CVYZvNG"\
"r3DHFToa4xRRErN70O+P0d+hp81/QHfno2OEEdpDboE/V+rY5lpz0tMv8/YzEJHrIzXl3Wm6VM2TkvJD/RJ00tMn0afsDFbgn8uuokct/F/j/wZfDsV"\
"nYZenNQROYYtlzi5ojmWf9Ri4B3ak2Nt9/P1BvFdT4xc1Wwr42NzHrFzhxgpT/p5W55+zDjk2Bj8i7RAPyHefX6EdRjoqqT/ftJC/QPzOMP8f2zQgf8"\
"+2vkW+lpS7yXf60SyfKA/RU+3Nv2zIT+Vto4z2+5knSU60vq2O9mGEh1h+rsGPczG8lvrwyeM21Cbi2+tn38iHoaY3kWb5uqf6fNg0ztIb+pf6GOjfl"\
"3/RhsCvd3m/nNibbDVv83m5nPiKsj3eib+9ejT6C2kHP0r6yf4ntfT9VvL22zzcMD4JvvuAfPZRB3zdCfnZ5rpYjAPfRheZHyH7QGFxrfbPN3j3mej8"\
"W3GN1hdW22drbe+brH59/xN3ZTkUfpY1GCfpRtsvRVYXwosnvLh2bqWtRTwV3QVa8jzKGdJAeOdZvbp1FkKrjP/rbae1uGTQ9sumD3K3rPL1uhaUo5+"\
"RwymwqP4f0+sRThfPP/B5t3bp+t+1nLApzJGt5I+U+D1ST4Jfsd4TCbC1fxj8rz+aPgcuA4co/usnjGmozIazDfcT39jhuvBZ8ENGpdnwI3oUfgVgk9"\
"RvhgcqLuZv7hk0eYt6CzdQ2x4/IEz2tv3c341Bc/JfwyvyDn24QFazvmSDlYRcxnST6tZHy05XyroV2swHuqhTUMlrPOpmh46Q53Z2jp0mTpytHPoOn"\
"t0rj4Rus39aoYOD03WJqGb+gTndkqoWjszJimh89QzWUOhMvZjj+eo/2VV5iVDxuovrLV0xuMW6yVOf2/anvU02IbUWuukhV6TGO2N6iVJ1YvSRM9Lm"\
"BTSUql3P8stt4+7Uzr3j48Z8xhzlsk5wz3PfWjzcZF23EDXOn9OtSD2s8kPs889wNqPc89qTmxPw5ZCrMe5fzWFT6P/IcY2Lhe5a966Tx/nPnXP99e4"\
"n4+fXHbSPyYnuHcFPjE56XIb/Eu4f93zP+3mWJu8zxn3GmUD/7PudePe55x7Ax74lLk3OTe9PSrn3dwkj9HWeQ38ksuDh83H8xtJ+xU3v4FfdQuMF+F"\
"T7hbCw2avuI9Xci+sS/r/Fq9yb8ODtnl+Pdn+Knxqf4VX41OL/+Yk93f0+/kWxqcGfs14jLhPI969DnM/8+unOfW8TaymmB5LTG1J6m2UHUfMbeXsqM"\
"bfr4Px+hD2Rj2BM3o7ugr/Hfjncj9u1DH2md7gQvbdMOsnxnnWp0Hvwn8W97VGHUP3x28BayiFPT3OHjwgqcOcAT7f6/nsLWHWoc/PQuex76SgfX6j3"\
"m35T1JvHudCmHPH5z9JvXnEclj2WHsGYl8g5/G/p/fR/zL0Xmv/IM7DRaZ/QOey3x/izC2l/I/W3zGss0Wm96NzuHuVcmafxX+/rfEXqHsxazKFemKs"\
"/Qj311Gc4Uuwhbn/xeUFzrxK7g1eH0I/j67mnnGaMofRY/BPcE/xdRxBP82ZeF0/Mv9j6BE6nJj5mG+G2cfjMpgz6iZno/c/jh5An3/hbPX+J9D90PW"\
"cx2dt7TaVPujb+kfrw8/oXui7+pn1we9xPbTYfE+zz3WDe78zdm8tMn4Wn65w7+/3wke10Ph59pLOcO9zEXtH3Wj8Mrw93Ptcxacd55Ln5fC2ut54Jb"\
"wV3PvXEKMtOYu8PQHP0Hzj19n30nWd8Trs8SS/RdlUzjTP6+Fh/cbafwcuugb+oDj3NdhCbrvVYHP2vlVgnHfLV2CU9fOl3V0qDbmPui/AJuxxcxmrI"\
"cYv2v4yyOo+z9vvBrHj+Tn2plp4Kd8/w15Ww3hudZPpU5Zs5s15mRgu5k16gVjf4J6hTD/Jd8MY676y1vVlzvvIN64r8dhb1vCe2swbdDXvsULePavY"\
"YwvAlbx91rLWVrgmvON6yATXm/MsLMvdAOI5zf4jrOQtvIc+3WF+VruBxHMz+5+wxg0iljvyrcGG+W4IeR2lwA1Fd6JNw5I4FHsnKXTDkziM+h4x3I1"\
"/Efj9fVgMfsd+UES5Xdzni8Gd3PWLqH8774BivreV/aOI72/WNobFnGVFtG0j+04h7d0AFoEFnCke19HeIpfFG7UZ5bN4z0bx6897N9X0cuZhEzgN36"\
"mkALNkiqX+Msn1I/WViYzPBNdTXuQdOc5lyljel8/x1hzN+/MZ0tOuk4wijWzA4J9K8D+lvf1PCf6ltLU0iPdvkO7Xngf/XIbw/r2H98r4fzD9eWf3Z"\
"u5GVv4foPOEnDEgMjAgMSAxICMzOQp4nHNn8GWIYmBgSGfIZchkSGaIZzCAQj0gLxMoms5QBZQHAHyqBfY="
    decompress_rle. r. $ir,$ir,1,1,5 if $ir>480 b. 0.2% fi >=. 40%
  fi
  nm. "[2D cupid shape]"

shape_cupid is a base64 encoded 1,2301,1,1 image generated by -compress_rle. That is, @David_Tschumperle or some person very much like him did gmic cupid.png -compress_rle. img2base64 -ot. cupid_b64.txt [Edit: not correct. -img2base64 returns the encoded base64 string as status. See followup post Real Soon Now… GRO] and then pasted the base64 string into gmic_stdlib.gmic and built -shape_cupid around it. Later on, -decompress_rle unrolls the decoded string back to a 480,480,1,1 binary image and resizes it via -resize per the numeric argument given to shape_cupid (cubic interpolation). If the argument requests a size greater than 480 pixels, then a slight blur is applied. In any case -ge 40% re-aligns the image to the [0…1] range and the results sits on the image list as a binary one-channel. the base64 encoded string which shape_cupid wraps around does not decode to a Structured Vector Graphics XML document at all.

Cupid appears to be the only -shape_* command based on a pre-defined raster. The others are procedurally drawn through various clever combinations of G’MIC commands.

How is it that base64 encoding/decoding has any sort of bearing on rasterizing Structured Vector Graphics? SVG is a high-level XML document. It is parsed and rasterized here (gentoo linux) via Gnome’s Librsvg library. G’MIC does not invoke this library directly, but uses ImageMagick/GraphicsMagick as a helper, very much like the hand-off @snibgo describes on his Windows machine. The hand-off here doesn’t involve Inkscape; ImageMagick is linked against librsvg directly. If I didn’t have Gnome’s SVG parser/rasterizer installed, I imagine ImageMagick would not possess an rSVG delegate and convert would just fail. Then, likewise, so would G`MIC.

As far as I can tell, when the hand-back to G`MIC from ImageMagick takes place, the SVG has been parsed and rasterized and looks like a .PNG stream. That’s all what -input “sees”; it, and G’MIC as a whole have no idea what an SVG file is and relies entirely on the ImageMagick black box to make an SVG file into a recognizable raster file format.

It would be nice if, somehow, G’MIC could pass on a -density argument to convert; but G’MIC’s -input argument signature doesn’t support the concept of raster density; it only really knows about rasters.

That is my point. All I see is the base64 and not a SVG file or XML.

Sorry all. Take two:

gmic -command mkb64.gmic -input encodeme.png -mkb64.  -output_text. encodeme_b64.txt

Where -mkb64.gmic is:

mkb64:
   -repeat $!
      -local[$<]
         -compress_rle. 0      # Compact long runs of identical bytes, etc.
         -img2base64. 0        # Base 64 encoded string is in status 
         foo=\"${}\"           # Make a text image from status
         ('$foo')
      -endlocal
   -done

So, encodeme.png:
encodeme

produces this text file encodeme_b64.txt:
encodeme_b64.txt (90.0 KB)