M. Bashir Al-Noimi | 1 Feb 01:06 2008
Picon

Re: Fwd: Stupid question - object's dimensions

Tom Davidson wrote:

> Your method might work if the object were a polygon, but finding the
> bounding box of a path defined by bezier curves is not trivial.
> Thankfully, inkscape can do it for you using command-line options (see
> man inkscape for the details).
>
> So if you save your file to mban.svg  (I had to add </g> </svg> at the
> end to make it valid), you can then run:
>
> $ inkscape --query-width ~/tmp/mban.svg
> 1.6336524
>
> $ inkscape --query-height ~/tmp/mban.svg
> 1.6247816
>
> -Tom
>
> On Jan 31, 2008 11:01 AM, M. Bashir Al-Noimi <mhdbnoimi <at> gmail.com> wrote:
>   
>>  Rob Antonishen wrote:
>>  Is this using a python extension to inkscape, or in an external
>> application?
>>
>>  I'm using external application, so I'm asking you, because SVG file format
>> is the major format in Inkscape, and I couldn't find any info about my
>> question in w3c website.
>>
>>
>>
(Continue reading)

Lambisgoia | 1 Feb 01:47 2008
Picon

The interaction between anti-aliasing, transparency, and gamma-correction

Hi All,

This is my first post to this list, so I will keep things brief. First
of all, I love Inkscape, and this is the reason for the message.

My tests indicate that, when rendering, Inkscape implements
anti-aliasing and transparency directly in a gamma-corrected
color-space. Am I right? It is my opinion that these operations should
instead be performed in a linear color-space. Although it is now
probably too late to change the default behavior of transparency
(given that the artists used gamma-corrected blends as reference while
creating their content), it is not too late to modify the behavior of
anti-aliasing. Also, perhaps a tag could be used on future files to
identify that they were created under the assumption of linear-blends.

Jim Blinn has a very good article on the subject:

    Jim Blinn, 2003
    "A Ghost in a Snow Storm",
    Jim Blinn's Corner: Notation, Notation, Notation,
    Chapter 9, pages 133--146, Morgan Kaufmann

There, he explains the problems that arise from performing blends in a
non-linear space, in better words than I ever could. At any rate, I'd
be happy to give examples and to elaborate on the topic once I receive
a message that reassures me I am posting on the correct alias.

Kind regards and thank you for such a great tool,
Diego

(Continue reading)

Ted Gould | 1 Feb 02:00 2008

Re: LPE plugin framework

On Thu, 2008-01-31 at 21:53 +0100, J.B.C.Engelen@... wrote:
> I'd like to start working on building a *plugin* framework for the LPEs
> (for example, but maybe tools too? dunno, let's try with LPE 1st). My
> motivation is two-fold:
> 1. I'd like people to be able to create new LPEs without requiring a new
> Inkscape release, like the current python extensions
> 2. it seems a challenging task! :)

I would prefer to see the current effects that we have extended so that
they are all "Live".  I'm not sure if you're familiar with Adobe
Illustrator but they have a "Flatten" type command with effects.  What
this means is that you keep editing of your original objects even as you
change it.  So you could take a path, jitter the nodes, then brighten
the color, but still edit it in it's original form.

The hardest part about implementing this would be determining the deltas
created by the scripts as that's not currently passed.  The guys who
wrote Unison have an interesting tool which works for differences within
XML files that could probably be used.

If GSoC is a go, I'd be happy to mentor this.

		--Ted

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
(Continue reading)

bulia byak | 1 Feb 02:08 2008
Picon

Re: LPE plugin framework

On 1/31/08, Ted Gould <ted@...> wrote:
> I would prefer to see the current effects that we have extended so that
> they are all "Live".  I'm not sure if you're familiar with Adobe
> Illustrator but they have a "Flatten" type command with effects.  What
> this means is that you keep editing of your original objects even as you
> change it.  So you could take a path, jitter the nodes, then brighten
> the color, but still edit it in it's original form.

For jittering, that's what LPEs already do.

Personally, I would like to preserve the current Python extension
effects system as is, with some improvements but without any closer
integration. It's an advantage to be able to very qiuckly write some
simple script and then be able to run it both from Inkscape as well as
standalone.

On the other hand, of course a plugin system that would extend current
LPEs and make them more powerful and more pluggable is a great idea
too, for more complex things. But that would be the next tier and we
shouldn't force everyone to use it when something much simpler would
suffice.

--

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
(Continue reading)

bulia byak | 1 Feb 02:25 2008
Picon

Re: The interaction between anti-aliasing, transparency, and gamma-correction

On 1/31/08, Lambisgoia <lambisgoia@...> wrote:
> Hi All,
>
> This is my first post to this list, so I will keep things brief. First
> of all, I love Inkscape, and this is the reason for the message.
>
> My tests indicate that, when rendering, Inkscape implements
> anti-aliasing and transparency directly in a gamma-corrected
> color-space. Am I right? It is my opinion that these operations should
> instead be performed in a linear color-space. Although it is now
> probably too late to change the default behavior of transparency
> (given that the artists used gamma-corrected blends as reference while
> creating their content), it is not too late to modify the behavior of
> anti-aliasing.

AFAIK, we cannot really change the behavior of transparency because it
is defined by SVG standard.

As for antialiasing, we can change it, but it would be very difficult
to code because currently, pixel buffers for all objects are combined
for the display, and this code cannot know whether a pixel's
less-than-one alpha comes from an antialiasing edge or from the
object's native transparency. Or even from both.

--

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

-------------------------------------------------------------------------
(Continue reading)

Tom Davidson | 1 Feb 02:29 2008
Picon

Re: The interaction between anti-aliasing, transparency, and gamma-correction

Just for reference: a recent bug (eventually marked invalid) in our
tracker dealing with an interaction between color-correction and
antialiasing:
https://bugs.launchpad.net/inkscape/+bug/179283

On Jan 31, 2008 4:47 PM, Lambisgoia <lambisgoia@...> wrote:
> Hi All,
>
> This is my first post to this list, so I will keep things brief. First
> of all, I love Inkscape, and this is the reason for the message.
>
> My tests indicate that, when rendering, Inkscape implements
> anti-aliasing and transparency directly in a gamma-corrected
> color-space. Am I right? It is my opinion that these operations should
> instead be performed in a linear color-space. Although it is now
> probably too late to change the default behavior of transparency
> (given that the artists used gamma-corrected blends as reference while
> creating their content), it is not too late to modify the behavior of
> anti-aliasing. Also, perhaps a tag could be used on future files to
> identify that they were created under the assumption of linear-blends.
>
> Jim Blinn has a very good article on the subject:
>
>     Jim Blinn, 2003
>     "A Ghost in a Snow Storm",
>     Jim Blinn's Corner: Notation, Notation, Notation,
>     Chapter 9, pages 133--146, Morgan Kaufmann
>
> There, he explains the problems that arise from performing blends in a
> non-linear space, in better words than I ever could. At any rate, I'd
(Continue reading)

Martin Owens | 1 Feb 02:31 2008
Picon

Re: LPE plugin framework

On 31/01/2008, Joshua A. Andler <joshua@...> wrote:
> Couldn't editing barcodes (the bar portion, not any numbers or text) be
> done using a path with subpaths?

You want to calculate bar codes in your head? how can editing sub
paths help editing a bar code?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Josh Andler | 1 Feb 03:17 2008
Picon

Re: LPE plugin framework

Martin Owens wrote:
> On 31/01/2008, Joshua A. Andler <joshua@...> wrote:
>   
>> Couldn't editing barcodes (the bar portion, not any numbers or text) be
>> done using a path with subpaths?
>>     
Calculate in my head? No. I was talking about the bar codes themselves 
being subpaths, rather than a group of paths/objects (as that's how I 
gathered that it worked from your previous message).

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Martin Owens | 1 Feb 04:44 2008
Picon

Re: LPE plugin framework

> Calculate in my head? No. I was talking about the bar codes themselves
> being subpaths, rather than a group of paths/objects (as that's how I
> gathered that it worked from your previous message).

Nope barcodes are generated by the plugin to be a single group tag
containing a) the text field if any, b) black and while rectangle
objects (the while is important)

Your going to have to explain how you can induce the barcode logic
from a subpath, from where I stand you need to go back to the barcode
plugin, generate a new one and replace the context object with it but
using the same position and layering.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Lambisgoia | 1 Feb 04:57 2008
Picon

Re: The interaction between anti-aliasing, transparency, and gamma-correction

Hi,

> AFAIK, we cannot really change the behavior of transparency because it
> is defined by SVG standard.

I am not a specialist, but my reading of the SVG 1.1 standard is that
all input colors are specified in sRGB. The sRGB standard itself,
under section "Alpha Channel Masking and Computer Graphics
Compatibility", suggests that "effects such as alpha masking be
performed either prior to encoding or by decoding to a color
resolution greater than 24 bits and then converting into linear
intensity space."

Section 14.2 of SVG 1.1 defines the widely known pre-multiplied alpha
formulas for alpha blending. That section does not explicitly require
the involved colors to be in the non-linear space. Although it is a
bit of a stretch, if we were to follow the sRGB standard
recommendation, we would convert to linear intensities when the
element colors are determined, and convert back to sRGB before the
pixel values are written to the frame-buffer or to an image file.

In any case, it does not matter what the standard says. What matters
is what people have come to expect from it. I am therefore not
suggesting for anything to be changed abruptly. I am just pointing out
the issue, and suggesting that it be addressed in the future. I don't
know which software is the "de facto" standard for SVG rendering, but
I wouldn't be surprised if it is Inkscape. It is therefore suited to
lead the effort.

> As for antialiasing, we can change it, but it would be very difficult
(Continue reading)


Gmane