- From: Benjamin Denckla <bdenckla@alum.mit.edu>
- Date: Thu, 6 Nov 2014 13:42:32 -0800
- To: Paul LeBeau <paul.lebeau@gmail.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAG7dtv+kGKEf1Ln-Na9tUrG5NLyY1eBfZYYS9pdd0=uwggGK1g@mail.gmail.com>
Even neater! That is a lot closer to what I had envisioned: I think there
are only two issues left.
1. I think the inversion has quantized the image to bilevel, i.e. it has
lost grayscale information.
2. This implements transparent inkscale ("t-inkscale" for short?), but for
completeness perhaps opaque inkscale ("o-inkscale"?) should be available as
well. I don't have a use case that would require o-inkscale. I just have a
vague feeling it represents an important complement to t-inkscale. To
implement o-inkscale might be tricky or impossible though, since it seems
there is no analog to currentColor for the current background color.
Regardless of what can be done about #2 (o-inkscale), if t-inkscale can be
implemented using existing primitives, I would still like to see it
available as a new pre-canned filter, since it seems to me a common/normal
thing to want to do.
Can it be submitted for consideration as a new pre-canned filter?
Ben
On Thu, Nov 6, 2014 at 1:07 AM, Paul LeBeau <paul.lebeau@gmail.com> wrote:
> It can be made to work with any background by tweaking the filter a
> little. We just need to use the original (well, inverted) image as a mask
> at the final step.
>
> <svg width="0" height="0">
> <defs>
> <filter id="filter-inkscale" x="0" y="0" width="100%"
> height="100%">
> <!-- invert the image so black on white becomes white on
> black -->
> <feColorMatrix in="SourceGraphic" type="matrix" values="-1
> 0 0 0 1
> 0
> -1 0 0 1
> 0
> 0 -1 0 1
> 0
> 0 0 1 0" result="inverted"/>
> <!-- create a mask so we can later blend with the
> background -->
> <feColorMatrix type="luminanceToAlpha" result="mask"/>
> <!-- convert image to 'currentColor' by multiplying the
> inverted image
> with an feFlood of the correct colour -->
> <feFlood flood-color="currentColor"/>
> <feBlend mode="multiply" in2="inverted"/>
> <!-- finally, mask out the result with the inverted
> original image -->
> <feComposite in2="mask" operator="in"/>
> </filter>
> </defs>
> </svg>
>
> Updated demo here: http://jsfiddle.net/py9q6z98/1/
>
> Paul
>
>
> On 6 November 2014 18:17, Benjamin Denckla <bdenckla@alum.mit.edu> wrote:
>
>> Neat! Only works for a black background, though.
>>
>> On Wed, Nov 5, 2014 at 2:48 AM, Paul LeBeau <paul.lebeau@gmail.com>
>> wrote:
>>
>>> Benjamin
>>>
>>> Perhaps I am missing something, but the effect you are after seems
>>> achieveable with SVG filters. <feFlood> can take currentColor. For
>>> example:
>>>
>>> <svg width="0" height="0">
>>> <defs>
>>> <filter id="filter-inkscale" x="0" y="0" width="100%"
>>> height="100%">
>>> <!-- invert the image -->
>>> <feColorMatrix in="SourceGraphic" type="matrix"
>>> values="-1 0 0 0 1
>>>
>>> 0 -1 0 0 1
>>>
>>> 0 0 -1 0 1
>>>
>>> 0 0 0 1 0" result="inverted"/>
>>> <feFlood flood-color="currentColor"/>
>>> <feBlend mode="multiply" in2="inverted"/>
>>> </filter>
>>> </defs>
>>> </svg>
>>>
>>> Which AFAICS gives the desired effect described in the article you
>>> linked to.
>>>
>>> Demo here: http://jsfiddle.net/py9q6z98/
>>>
>>> If you change the value of color in the CSS for the div, the image
>>> color changes to match the text color.
>>>
>>> Paul
>>>
>>>
>>>
>>> On 5 November 2014 19:19, Dirk Schulze <dschulze@adobe.com> wrote:
>>>
>>>> Hi Ben,
>>>>
>>>> On Nov 4, 2014, at 7:17 PM, Benjamin Denckla <bdenckla@alum.mit.edu>
>>>> wrote:
>>>>
>>>> > Thanks Dirk, for your response.
>>>> >
>>>> > Indeed "bitonal" was a poor word choice. I'm now using "inkscale"
>>>> instead. See
>>>> http://dencklatronic.blogspot.com/2014/10/more-on-bitonal-inkscale-images.html
>>>> .
>>>> >
>>>> > Indeed inkscale could be described as a gradient map with two color
>>>> stops.
>>>> >
>>>> > Perhaps Greenblatt could provide an example use of gradientmap.js
>>>> using the CSS currentColor variable?
>>>> >
>>>> > If that is possible, that could be used to implement transparent
>>>> inkscale.
>>>> >
>>>> > Opaque inkscale would require the background equivalent of
>>>> currentColor, which, oddly, does not seem to exist.
>>>> >
>>>> > Even if all that could be done, I do not feel inkscale should require
>>>> Javascript, in the long run.
>>>> >
>>>> > For one thing, this would prevent it from being used in the most
>>>> popular ebook format: Kindle. Javascript is not allowed in Kindle books,
>>>> nor would I expect Amazon to allow it anytime soon.
>>>> >
>>>> > For another, admittedly more vague thing, it feels like Javascript
>>>> should be used only as an "escape hatch" if you're doing something weird or
>>>> interactive. Inkscale is certainly not interactive. As to whether it is
>>>> weird, that is of course subjective. But I wonder if there is an analogy
>>>> with transparency. What if web standards were missing transparency, and
>>>> someone proposed a way to implement it in Javascript? That would be a great
>>>> workaround until the new standard was propagated to a reasonable percentage
>>>> of the installed base. But ultimately we would want to see transparency
>>>> available without Javascript.
>>>>
>>>> I first wanted to know if I understand you correctly. A JS prototype
>>>> can help to demonstrate issues. We will discuss adding this feature to the
>>>> next level of Filter Effects.
>>>>
>>>> Allowing currentColor for this kind of feature will have security
>>>> requirements. feColorMatrix would get one of the tainted filter primitives
>>>> and the filter can not be used cross origin. We have this problem with
>>>> feFlood, feDropShadow and other primitives[1] already. I do not see this as
>>>> a problem with that though.
>>>>
>>>> In your blog post you mentioned access to foreground and background
>>>> color. currentColor only can represent one color. How would you access the
>>>> other color? Also, currentColor represents the value of the ‘color’
>>>> property on an ancestor. ‘color’ is used to style text in HTML and could
>>>> have unwanted affects to text there. A solution could be CSS Custom
>>>> properties[2] of course or the latest approach of "brand color” on WHATWG
>>>> mailing list.
>>>>
>>>> Greetings,
>>>> Dirk
>>>>
>>>> [1] http://dev.w3.org/fxtf/filters/#security
>>>> [2] http://dev.w3.org/csswg/css-variables/
>>>>
>>>>
>>>>
>>>> >
>>>> > Ben
>>>>
>>>>
>>>>
>>>
>>
>
Received on Thursday, 6 November 2014 21:43:01 UTC