Re: [dev] Xorg implementations

[sylvain . bertrand]

I did check alpine package web browsers: it's full of libgcc_s deps.

You can forget alpine as a no libgcc_s distro. At least, they do maintain the
patches required in order to compile many software packages with the musl
libc.

Regards,

-- 
Sylvain

Re: [dev] git://git.suckless.org not accepting connections

[Anselm R Garbe]

On 4 July 2017 at 00:36, Anselm R Garbe  wrote:
> On 4 July 2017 at 00:06, Michael Forney  wrote:
>> I noticed that git.suckless.org is no longer accepting connections
>> with the git protocol. HTTP still works though.
>>
>> Just pointing that out in case it wasn't a deliberate change.
>
> Nice spot, wasn't deliberate and is caused by the server relocation.
> I'll look into this.

Should be fixed now.

BR,
Anselm

Re: [dev] git://git.suckless.org not accepting connections

[Anselm R Garbe]

Hi Michael,

On 4 July 2017 at 00:06, Michael Forney  wrote:
> I noticed that git.suckless.org is no longer accepting connections
> with the git protocol. HTTP still works though.
>
> Just pointing that out in case it wasn't a deliberate change.

Nice spot, wasn't deliberate and is caused by the server relocation.
I'll look into this.

BR,
Anselm

[dev] git://git.suckless.org not accepting connections

[Michael Forney]

Hi,

I noticed that git.suckless.org is no longer accepting connections
with the git protocol. HTTP still works though.

Just pointing that out in case it wasn't a deliberate change.

-Michael

Re: [dev] Problems with farbfeld image editing tools

[Mattias Andrée]

On Mon, 3 Jul 2017 19:11:46 +0200
Mattias Andrée  wrote:

> On Mon, 3 Jul 2017 18:55:42 +0200
> Laslo Hunhold  wrote:
> 
> > On Mon, 3 Jul 2017 18:47:37 +0200
> > Mattias Andrée  wrote:
> > 
> > Dear Mattias,
> >   
> > > Perhaps farbfeld should specify that it should use linear sRGB, right
> > > now it specifies sRGB, which implies non-linear. It wouldn't make
> > > the format less complicated in my opinion, but it would be easier to
> > > implemented editing tools.
> > 
> > It would make it easier to implement the tools, however, this would on
> > the other hand force everybody trying to display farbfeld images to
> > make the transformations back to non-linear sRGB.  
> 
> Yes. However, if this is not done, the error is probably less than if
> multiple edits have been made to the image without considering this.
> 
> > As you already explained pretty well, the non-linear gamma curve is
> > there for a reason.
> >   
> > > The problem with treating non-linear colour models as linear is that
> > > the error accumulate. Whilst you may not notice the error after one
> > > edit unless you compare the image to the correct one, it will be
> > > noticeable if you apply multiple change.
> > 
> > This is correct, but only applies to cases where we need "exact"
> > transformations. Every non-integer arithmetic operation has the
> > potential to be erroneous. Given we have 16 bits per channel, the
> > accumulated error would be invisble in most cases, even for long
> > pipelines (if you don't do anything crazy).
> >   
> > > 50 % bright in the linear model is at 0.50, but at 0.74 in the
> > > non-linear model. The difference is almost 50 %, the difference is
> > > larger at darker colours.
> > 
> > When was the last time you needed to brighten up your picture by
> > "exactly factor 2"? Most of the time, people open GIMP and move the
> > slider until the brightness suits their taste.  
> 
> That was just an example to illustrate how manipulations should be
> applies. And indeed it is not common that you need exact changes.
> If you need exact colours you probably don't want to use farbfeld
> at all because it is restricted to colours in the sRGB gamut.
> 
> To avoid the problem with the transfer function, it is probably
> enough (since farbfeld uses 16-bit values) to add a tool applies
> the inverse transfer function and a tool that applies the transfer
> function. That way, the editing tools can be as simply as they are
> today, but you can get rather exact results if you need it.

I think some tools must still be aware of sRGB's non-linearity.
For example, if you make a tool that draws a gradient, you probably
want the colours in the gradient to increase linearly, so you have
to be that the colour model is not linear.

> 
> > 
> > With best regards
> > 
> > Laslo Hunhold
> >   
> 



pgpaWZSBBMnbR.pgp
Description: OpenPGP digital signature

Re: [dev] Problems with farbfeld image editing tools

[Mattias Andrée]

On Mon, 3 Jul 2017 18:55:42 +0200
Laslo Hunhold  wrote:

> On Mon, 3 Jul 2017 18:47:37 +0200
> Mattias Andrée  wrote:
> 
> Dear Mattias,
> 
> > Perhaps farbfeld should specify that it should use linear sRGB, right
> > now it specifies sRGB, which implies non-linear. It wouldn't make
> > the format less complicated in my opinion, but it would be easier to
> > implemented editing tools.  
> 
> It would make it easier to implement the tools, however, this would on
> the other hand force everybody trying to display farbfeld images to
> make the transformations back to non-linear sRGB.

Yes. However, if this is not done, the error is probably less than if
multiple edits have been made to the image without considering this.

> As you already explained pretty well, the non-linear gamma curve is
> there for a reason.
> 
> > The problem with treating non-linear colour models as linear is that
> > the error accumulate. Whilst you may not notice the error after one
> > edit unless you compare the image to the correct one, it will be
> > noticeable if you apply multiple change.  
> 
> This is correct, but only applies to cases where we need "exact"
> transformations. Every non-integer arithmetic operation has the
> potential to be erroneous. Given we have 16 bits per channel, the
> accumulated error would be invisble in most cases, even for long
> pipelines (if you don't do anything crazy).
> 
> > 50 % bright in the linear model is at 0.50, but at 0.74 in the
> > non-linear model. The difference is almost 50 %, the difference is
> > larger at darker colours.  
> 
> When was the last time you needed to brighten up your picture by
> "exactly factor 2"? Most of the time, people open GIMP and move the
> slider until the brightness suits their taste.

That was just an example to illustrate how manipulations should be
applies. And indeed it is not common that you need exact changes.
If you need exact colours you probably don't want to use farbfeld
at all because it is restricted to colours in the sRGB gamut.

To avoid the problem with the transfer function, it is probably
enough (since farbfeld uses 16-bit values) to add a tool applies
the inverse transfer function and a tool that applies the transfer
function. That way, the editing tools can be as simply as they are
today, but you can get rather exact results if you need it.

> 
> With best regards
> 
> Laslo Hunhold
> 



pgpxA9_5kvQ5H.pgp
Description: OpenPGP digital signature

Re: [dev] Problems with farbfeld image editing tools

[Laslo Hunhold]

On Mon, 3 Jul 2017 18:47:37 +0200
Mattias Andrée  wrote:

Dear Mattias,

> Perhaps farbfeld should specify that it should use linear sRGB, right
> now it specifies sRGB, which implies non-linear. It wouldn't make
> the format less complicated in my opinion, but it would be easier to
> implemented editing tools.

It would make it easier to implement the tools, however, this would on
the other hand force everybody trying to display farbfeld images to
make the transformations back to non-linear sRGB.
As you already explained pretty well, the non-linear gamma curve is
there for a reason.

> The problem with treating non-linear colour models as linear is that
> the error accumulate. Whilst you may not notice the error after one
> edit unless you compare the image to the correct one, it will be
> noticeable if you apply multiple change.

This is correct, but only applies to cases where we need "exact"
transformations. Every non-integer arithmetic operation has the
potential to be erroneous. Given we have 16 bits per channel, the
accumulated error would be invisble in most cases, even for long
pipelines (if you don't do anything crazy).

> 50 % bright in the linear model is at 0.50, but at 0.74 in the
> non-linear model. The difference is almost 50 %, the difference is
> larger at darker colours.

When was the last time you needed to brighten up your picture by
"exactly factor 2"? Most of the time, people open GIMP and move the
slider until the brightness suits their taste.

With best regards

Laslo Hunhold

-- 
Laslo Hunhold 

Re: [dev] Xorg implementations

[Bobby Powers]

Sylvain Bertrand wrote:
> For c++ retards and sub-humans

Delete your account.

Re: [dev] Problems with farbfeld image editing tools

[Mattias Andrée]

On Mon, 3 Jul 2017 18:25:23 +0200
Laslo Hunhold  wrote:

> On Mon, 3 Jul 2017 17:28:29 +0200
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> > Because if the limited number of values that can be stored in an
> > 8-bit integer and because humans don't notices small differences
> > between dark colours as well as small differences in bright
> > colours, sRGB encodes colours non-linearly so there are more
> > bright colours and fewer dark colours.  
> 
> yes, this is correct.
> 
> > However, looking at image editing tools for farbfeld I've found
> > that the tools do not take this into account. For example, making
> > a colour twice a bright, is not as simple as multiply the RGB
> > values with 2  
> 
> It is if you have linear RGB. If you make the proper transformation
> from sRGB to linear sRGB, it is perfectly valid.
> 
> > , rather the algorithm that shall be used is
> > 
> > x = F(2 ⋅ F⁻¹(x₀))
> > 
> > where F is sRGB's transfer function
> > 
> >⎧ -F(-t) if t < 0
> > F(t) = ⎨ 12.92 tif 0 ≤ t ≤ 0.0031306684425217108 [*]
> >⎩ 1.055 t↑(1/2.4) - 0.055  otherwise
> > 
> > [*] Approximate value. You will often find the value
> > 0.0031308 here, but this value is less accurate and
> > only good enough when working with 8-bit integers.  
> 
> How do you expect anyone to understand this? It's better to just work
> with linear sRGB. The transfer function is the inverse of the
> companding function and it honestly does not look very nice. The
> companding function gives more insight in how sRGB works and does not
> hide it behind closed doors.
> 
> sRGB is a pretty complex matter in my opinion. We don't just have an
> exponential gamma function, but one that is companded differently below
> a certain treshold. However, it's not nearly as complicated as general
> colour theory.
> If we have nonlinear sRGB-values V (where V is one of R,G,B), we can
> make the conversion to linear sRGB (v where v is one of r,g,b) via
> 
>   ⎧ V / 12.92V <= 0.04045
>   v = ⎨
>   ⎩ [(V + 0.055) / 1.055]^2.4else
> 
> Credit goes to Bruce Lindbloom[0] for creating this awesome collection
> of transformation formulae.
> 
> After all though, if you mistake linear and nonlinear RGB, you most
> likely won't see the difference anyway. In 99% of the cases, the tools
> work with an immediate visual feedback.
> 
> With best regards
> 
> Laslo Hunhold
> 
> [0]: http://www.brucelindbloom.com/
> 


Perhaps farbfeld should specify that it should use linear sRGB, right
now it specifies sRGB, which implies non-linear. It wouldn't make
the format less complicated in my opinion, but it would be easier to
implemented editing tools.

The problem with treating non-linear colour models as linear is that
the error accumulate. Whilst you may not notice the error after one
edit unless you compare the image to the correct one, it will be
noticeable if you apply multiple change.

50 % bright in the linear model is at 0.50, but at 0.74 in the
non-linear model. The difference is almost 50 %, the difference is
larger at darker colours.


pgphwMPa_GaBX.pgp
Description: OpenPGP digital signature

Re: [dev] Problems with farbfeld image editing tools

[Laslo Hunhold]

On Mon, 3 Jul 2017 17:28:29 +0200
Mattias Andrée  wrote:

Hey Mattias,

> Because if the limited number of values that can be stored in an
> 8-bit integer and because humans don't notices small differences
> between dark colours as well as small differences in bright
> colours, sRGB encodes colours non-linearly so there are more
> bright colours and fewer dark colours.

yes, this is correct.

> However, looking at image editing tools for farbfeld I've found
> that the tools do not take this into account. For example, making
> a colour twice a bright, is not as simple as multiply the RGB
> values with 2

It is if you have linear RGB. If you make the proper transformation
from sRGB to linear sRGB, it is perfectly valid.

> , rather the algorithm that shall be used is
> 
>   x = F(2 ⋅ F⁻¹(x₀))
> 
> where F is sRGB's transfer function
> 
>  ⎧ -F(-t) if t < 0
>   F(t) = ⎨ 12.92 tif 0 ≤ t ≤ 0.0031306684425217108 [*]
>  ⎩ 1.055 t↑(1/2.4) - 0.055  otherwise
> 
> [*] Approximate value. You will often find the value
> 0.0031308 here, but this value is less accurate and
> only good enough when working with 8-bit integers.

How do you expect anyone to understand this? It's better to just work
with linear sRGB. The transfer function is the inverse of the
companding function and it honestly does not look very nice. The
companding function gives more insight in how sRGB works and does not
hide it behind closed doors.

sRGB is a pretty complex matter in my opinion. We don't just have an
exponential gamma function, but one that is companded differently below
a certain treshold. However, it's not nearly as complicated as general
colour theory.
If we have nonlinear sRGB-values V (where V is one of R,G,B), we can
make the conversion to linear sRGB (v where v is one of r,g,b) via

⎧ V / 12.92V <= 0.04045
v = ⎨
⎩ [(V + 0.055) / 1.055]^2.4else

Credit goes to Bruce Lindbloom[0] for creating this awesome collection
of transformation formulae.

After all though, if you mistake linear and nonlinear RGB, you most
likely won't see the difference anyway. In 99% of the cases, the tools
work with an immediate visual feedback.

With best regards

Laslo Hunhold

[0]: http://www.brucelindbloom.com/

-- 
Laslo Hunhold 

Re: [dev] Xorg implementations

[sylvain . bertrand]

On Mon, Jul 03, 2017 at 05:33:14PM +0200, hiro wrote:
> I should, so there isn't any? I have alpine here ready and waiting...

Indeed, alpine is musl based (thx to the authors for all the patching, hope
upstream they were not *ss h*les and committed the patches).

For sane C code (or at least have a chance to be sane). The idea is to check if
alpine version of gcc C has no libgcc_s. Namely, C binaries and C shared libs
do not depend on libgcc_s, or compilation of a reasonably sized C binary or C
shared lib does not generate a dep on libgcc_s.

For insane c++ code (it will never be sane, ever), if I recall properly, that
pile of degenerated cr*p which is llvm uses c++ threading for gpu shader
compilation, hence mesa. If alpine has llvm shared libs and not llvm static
libs, the deps of those will have the shared libstdc++ as a dep. If alpine went
the static libstdc++ way, then we would look at libGL*. Namely, if there is a
dep on libgcc_s, it would mean that very probably, gcc libstdc++, even static,
needs a shared libgcc like the glibc.

For a static userland distro, a good thing would be to have only the ELF
dynamic loader and only the shared libs for the closed source binaries (...
dota2 and steam... coze I'm a gamer... nobody is perfect :) ).



For the record, I did ask the glibc maintainers about this sh*tty libgcc_s dep
of pthread_cancel: got a polite "f*ck y*u" (you can check their mailing list
archive, and if I recall properly, was not the only one in the world to ask).

-- 
Sylvain

Re: [dev] Xorg implementations

[hiro]

I should, so there isn't any? I have alpine here ready and waiting...

On 7/3/17, sylvain.bertr...@gmail.com  wrote:
> On Mon, Jul 03, 2017 at 02:53:30PM +0200, hiro wrote:
>> so if i'm on musl and tell gcc to link statically it should just work?
>> in that case i'll try and report.
>
> Meaning that, in theory, you can have a libc which does not require
> libgcc_s
> (coze of pthread_cancel) with musl.
>
> Namely, you should be able to have a "working" distro with a 'static gcc',
> namely
> which frontend statically links libgcc_eh.a and libgcc.a _only_ and _not_
> libgcc_s.so.
>
> For c++ retards and sub-humans, I fear that there are some libgcc_s.so hard
> deps in gcc libstdc++
> related to c++ threading (that would need investigation).
>
> --
> Sylvain
>
>

[dev] Problems with farbfeld image editing tools

[Mattias Andrée]

Because if the limited number of values that can be stored in an
8-bit integer and because humans don't notices small differences
between dark colours as well as small differences in bright
colours, sRGB encodes colours non-linearly so there are more
bright colours and fewer dark colours.

However, looking at image editing tools for farbfeld I've found
that the tools do not take this into account. For example, making
a colour twice a bright, is not as simple as multiply the RGB
values with 2, rather the algorithm that shall be used is

x = F(2 ⋅ F⁻¹(x₀))

where F is sRGB's transfer function

   ⎧ -F(-t) if t < 0
F(t) = ⎨ 12.92 tif 0 ≤ t ≤ 0.0031306684425217108 [*]
   ⎩ 1.055 t↑(1/2.4) - 0.055  otherwise

[*] Approximate value. You will often find the value
0.0031308 here, but this value is less accurate and
only good enough when working with 8-bit integers.


pgps98aZmwvZH.pgp
Description: OpenPGP digital signature

Re: [dev] Xorg implementations

[sylvain . bertrand]

On Mon, Jul 03, 2017 at 02:53:30PM +0200, hiro wrote:
> so if i'm on musl and tell gcc to link statically it should just work?
> in that case i'll try and report.

Meaning that, in theory, you can have a libc which does not require libgcc_s
(coze of pthread_cancel) with musl.

Namely, you should be able to have a "working" distro with a 'static gcc', 
namely
which frontend statically links libgcc_eh.a and libgcc.a _only_ and _not_ 
libgcc_s.so.

For c++ retards and sub-humans, I fear that there are some libgcc_s.so hard 
deps in gcc libstdc++
related to c++ threading (that would need investigation).

-- 
Sylvain

Re: [dev] Xorg implementations

[hiro]

so if i'm on musl and tell gcc to link statically it should just work?
in that case i'll try and report.

On 7/3/17, sylvain.bertr...@gmail.com  wrote:
> On Mon, Jul 03, 2017 at 01:45:39PM +0200, hiro wrote:
>> I have a related question. how can i statically link X11 programs
>> nowadays? Without dlopen obviously...
>
> AFAIK, you can statically link all of them... but it was a long time ago.
>
> The real culprit for static linking is in the gnu glibc: pthread_cancel
> _does_
> dlopen libgcc_s for "stack unwinding code" (just kill the stack, why unwind
> it??). This is how you can bootstrap a system build with a glibc which does
> not
> require an existing libgcc_s which depends itself on the libc (it breaks
> the
> circular dep). But gcc is doomed anyway as it goes c++.
>
> To summerize, you have any program which uses pthread_cancel, you MUST use
> libgcc_s, here dies the static libgcc distros.
>
> It seems musl lib has a pthread_cancel which does work with "libgcc_s
> dlopen
> free" static linking...
>
> --
> Sylvain
>
>

Re: [dev] Xorg implementations

[sylvain . bertrand]

On Mon, Jul 03, 2017 at 01:45:39PM +0200, hiro wrote:
> I have a related question. how can i statically link X11 programs
> nowadays? Without dlopen obviously...

AFAIK, you can statically link all of them... but it was a long time ago.

The real culprit for static linking is in the gnu glibc: pthread_cancel _does_
dlopen libgcc_s for "stack unwinding code" (just kill the stack, why unwind
it??). This is how you can bootstrap a system build with a glibc which does not
require an existing libgcc_s which depends itself on the libc (it breaks the
circular dep). But gcc is doomed anyway as it goes c++.

To summerize, you have any program which uses pthread_cancel, you MUST use
libgcc_s, here dies the static libgcc distros.

It seems musl lib has a pthread_cancel which does work with "libgcc_s dlopen
free" static linking...

-- 
Sylvain

Re: [dev] Xorg implementations

[hiro]

I have a related question. how can i statically link X11 programs
nowadays? Without dlopen obviously...