Respect SVG transparency about timg

[hzeller]

ah, ok. The whole point of this function though is to provide a way for the user to specify the background color.
So I think we just need to extend it to not only understand #rrggbb but #rrggbbaa

[acxz]

@hzeller thanks for the fix!
Tested it on all the problematic SVG files linked in this issue and timg displays them correctly!

I believe this issue can be closed.

[hzeller]

Great to hear.
Fix was done by @lromor ; thanks Leonardo!

[hzeller]

We need to find how we can tell the API to background fill with none like the convert commandline does.

[acxz]

Maybe take a look at how icat does it?

icat on top, timg on bottom:

Ignore the scaling issue, icat doesn't properly scale images to the original aspect ratio.

[hzeller]

Looks like that program is using imlib2 . Can it read SVGs ?
Might be worthwhile experimenting with.

[acxz]

Actually did some digging into the timg codebase and honestly its just this fix right here:

timg/src/framebuffer.cc

Line 44 in 26b58c0

return {(uint8_t)r, (uint8_t)g, (uint8_t)b, 0xff};

- return {(uint8_t)r, (uint8_t)g, (uint8_t)b, 0xff};
+ return {(uint8_t)r, (uint8_t)g, (uint8_t)b, 0x00};

The only place ParseColor is used is the following:

timg/src/timg.cc

Lines 758 to 779 in cfd5f7a

	std::future<rgba_t> background_color_future;
	if (bg_color) {
	if (strcasecmp(bg_color, "auto") == 0) {
	#ifdef WITH_TIMG_TERMINAL_QUERY
	std::function<rgba_t()> query_terminal = []() {
	return rgba_t::ParseColor(timg::QueryBackgroundColor());
	};
	background_color_future = pool->ExecAsync(query_terminal);
	display_opts.bgcolor_getter = [&background_color_future]() {
	static rgba_t value = background_color_future.get(); // once
	return value;
	};
	#else
	const rgba_t bg = rgba_t::ParseColor("#000000");
	display_opts.bgcolor_getter = [bg]() { return bg; };
	#endif
	}
	else {
	const rgba_t bg = rgba_t::ParseColor(bg_color);
	display_opts.bgcolor_getter = [bg]() { return bg; };
	}
	}

and with the above proposed change we can simplify the logic of this codeblock. For example if we are using a transparent background no need to query the terminal for a background color.

This does remove user specified backgrounds though, since the opacity will always be hardcoded 0, but that can be changed with reading the opacity value properly in the ParseColor method.

I can make a PR on this soon.

[acxz]

Okay so basically I see two things here:

1. allow user to specify background opacity (new feature request)
2. fix proper use of background color with transparency (bug fix)

[acxz]

I do have a solution but currently it is not working with the kitty protocol.
Can you point me to where the color is rendered for kitty?

Edit: found the bug

[acxz]

@xeruf For me the resolution was to simply use timg as follows: timg -b none <filename>.

the default option -b auto will try to blend and cause all transparency in the object to be removed, both for PNGs and SVGs.

[acxz]

extend it to not only understand #rrggbb but #rrggbbaa

I attempted this however, intermediary opacity values do not work, i.e if aa is 00 then the background is transparent (same as -b none) and if aa is any other value than the background is completely opaque, resulting in the same backgroud as #rrggbb. Therefore, I believe there would be no point in adding such a feature for users to specify transparent backgrounds via rgba.

I believe this is a non-issue and can be closed or maybe I just don't understand the issue properly.
Unless we want to change the default background option to be -b none so that transparency is handled by default, instead of blending.

[acxz]

@hzeller can you provide comments to this issue?

What are the requirements to close this issue?

[xeruf]

interestingly, it depends on the SVG - some are rendered transparent, some with white background, even though all are theoretically transparent.
None seems to respect the -b flag though.

[acxz]

None seems to respect the -b flag though.

Can you show an example, as this did work for me.

If you post the actual SVG's which didn't work that would appreciated as well so that we can reproduce the issue.

[xeruf]

❯ timg --version
timg 1.4.4+  <https://timg.sh/>
Copyright (c) 2016..2021 Henner Zeller. This program is free software; license GPL 2.0.

Image decoding GraphicsMagick 1.3.38 (2022-03-26)
Openslide 3.4.1
Video decoding libav 59.16.100

This always shows a white background:

This never shows a background, regardless of the -b flag:

[acxz]

This always shows a white background:

Can confirm, the svg file always renders a white background. However, when I convert the svg the png using -b none properly has transparency.

This never shows a background, regardless of the -b flag:

Can also confirm, converting from the svg to the png does give nominal behavior and it is possible to change the background.

Looks like SVG's are just not being read in/operated on properly like png files are.
A temporary solution to this issue is to then convert svg files to png files.

it depends on the SVG

I wonder if the SVG has different specs?

[hzeller]

If auto is the problem, then maybe the query for your particular terminal does not work ? What is the terminal you're using ?

[acxz]

Other SVG files work on the same terminal. I am using termite.

as far as I'm aware of, transparency doesn't work with auto anyway, just none. auto is not the issue.

[hzeller]

So, this should work now, can you test on your favorite transparent SVGs ?