Du bist nicht eingeloggt! Möglicherweise kannst du deswegen nicht alles sehen.
  (Noch kein mods.de-Account? / Passwort vergessen?)
Zur Übersichtsseite
Hallo anonymer User.
Bitte logge dich ein
oder registriere dich!
 Moderiert von: mercury, Schalentier


 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 157 158 159 160 [161] 162 163 164 165 ... 215 nächste » letzte »
erste ungelesene Seite | letzter Beitrag 
csde_rats

AUP csde_rats 04.09.2021
OpenColorIO fails parsing configs with non-C locale

P o r t a b l e S o f t w a r e

$LANGUAGE war en_GB:en_US bei mir, $LANG en_US.UTF-8, nichtmal das funktioniert. Es braucht setlocale(LC_ALL, "C"), sonst geht es nicht.

e: Unabhängig davon ist das Locale-System in C/POSIX einfach komplett broken, es gab da letztens einen schönen Rant von wm4 (mpv-Maintainer).

https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe

 
stream_libarchive: workaround various types of locale braindeath

Fix that libarchive fails to return filenames for UTF-8/UTF-16 entries.
The reason is that it uses locales and all that garbage, and mpv does
not set a locale.

Both C locales and wchar_t are shitfucked retarded legacy braindeath. If
the C/POSIX standard committee had actually competent members, these
would have been deprecated or removed long ago. (I mean, they managed to
remove gets().) To justify this emotional outbreak potentially insulting
to unknown persons, I will write a lot of text. Those not comfortable
with toxic language should pretend this is a religious text.

C locales are supposed to be a way to support certain languages and
cultures easier. One example are character codepages. Back when UTF-8
was not invented yet, there were only 255 possible characters, which is
not enough for anything but English and some european languages. So they
decided to make the meaning of a character dependent on the current
codepage. The locale (LC_CTYPE specifically) determines what character
encoding is currently used.

Of course nowadays, this is legacy nonsense. Everything uses UTF-8 for
"char", and what doesn't is broken and terrible anyway. But the old ways
stayed with us, and the stupidity of it as well.

C locales were utterly moronic even when they were invented. The locale
(via setlocale()) is global state, and global state is not a reasonable
way to do anything. It will break libraries, or well modularized code.
(The latter would be forced to strictly guard all entrypoints set
set/restore locales, assuming a single threaded world.)

On top of that, setting a locale randomly changes the semantics of a
bunch of standard functions. If a function respects locale, you suddenly
can't rely on it to behave the same on all systems. Some behavior can
come as a surprise, and of course it will be dependent on the region of
the user (it doesn't help that most software is US-centric, and the US
locale is almost like the C locale, i.e. almost what you expect).

Idiotically, locales were not just used to define the current character
encoding, but the concept was used for a whole lot of things, like e. g.
whether numbers should use "," or "." as decimal separaror. The latter
issue is actually much worse, because it breaks basic string conversion
or parsing of numbers for the purpose of interacting with file formats
and such.

Much can be said about how retarded locales are, even beyond what I just
wrote, or will wrote below. They are so hilariously misdesigned and
insufficient, I can't even fathom how this shit was _standardized_. (In
any case, that meant everyone was forced to implement it.) Many C
functions can't even do it correctly. For example, the character set
encoding can be a multibyte encoding (not just UTF-8, but awful garbage
like Shift JIS (sometimes called SHIT JIZZ), yet functions like
toupper() can return only 1 byte. Or just take the fact that the locale
API tries to define standard paper sizes (LC_PAPER) or telephone number
formatting (LC_TELEPHONE). Who the fuck uses this, or would ever use
this?

But the badness doesn't stop here. At some point, they invented threads.
And they put absolutely no thought into how threads should interact with
locales. So they kept locales as global state. Because obviously, you
want to be able to change the semantics of basic string processing
functions _while_ they're running, right? (Any thread can call
setlocale() at any time, and it's supposed to change the locale of all
other threads.)

At this point, how the fuck are you supposed to do anything correctly?
You can't even temporarily switch the locale with setlocale(), because
it would asynchronously fuckup the other threads. All you can do is to
enforce a convention not to set anything but the C local (this is what
mpv does), or to duplicate standard functions using code that doesn't
query locale (this is what e.g. libass does, a close dependency of mpv).

Imagine they had done this for certain other things. Like errno, with
all the brokenness of the locale API. This simply wouldn't have worked,
shit would just have been too broken. So they didn't. But locales give a
delicious sweet spot of brokenness, where things are broken enough to
cause neverending pain, but not broken enough that enough effort would
have spent to fix it completely.

On that note, standard C11 actually can't stringify an error value. It
does define strerror(), but it's not thread safe, even though C11
supports threads. The idiots could just have defined it to be thread
safe. Even if your libc is horrible enough that it can't return string
literals, it could just just some thread local buffer. Because C11 does
define thread local variables. But hey, why care about details, if you
can just create a shitty standard?

(POSIX defines strerror_r(), which "solves" this problem, while still
not making strerror() thread safe.)

Anyway, back to threads. The interaction of locales and threads makes no
sense. Why would you make locales process global? Who even wanted it to
work this way? Who decided that it should keep working this way, despite
being so broken (and certainly causing implementation difficulties in
libc)? Was it just a fucked up psychopath?

Several decades later, the moronic standard committees noticed that this
was (still is) kind of a bad situation. Instead of fixing the situation,
they added more garbage on top of it. (Probably for the sake of
"compatibility"). Now there is a set of new functions, which allow you
to override the locale for the current thread. This means you can
temporarily override and restore the local on all entrypoints of your
code (like you could with setlocale(), before threads were invented).

And of course not all operating systems or libcs implement this. For
example, I'm pretty sure Microsoft doesn't. (Microsoft got to fuck it up
as usual, and only provides _configthreadlocale(). This is shitfucked on
its own, because it's GLOBAL STATE to configure that GLOBAL STATE should
not be GLOBAL STATE, i.e. completely broken garbage, because it requires
agreement over all modules/libraries what behavior should be used. I
mean, sure, makign setlocale() affect only the current thread would have
been the reasonable behavior. Making this behavior configurable isn't,
because you can't rely on what behavior is active.)

POSIX showed some minor decency by at least introducing some variations
of standard functions, which have a locale argument (e.g. toupper_l()).
You just pass the locale which you want to be used, and don't have to do
the set locale/call function/restore locale nonense. But OF COURSE they
fucked this up too. In no less than 2 ways:

- There is no statically available handle for the C locale, so you have
to initialize and store it somewhere, which makes it harder to make
utility functions safe, that call locale-affected standard functions
and expect C semantics. The easy solution, using pthread_once() and a
global variable with the created locale, will not be easily accepted
by pedantic assholes, because they'll worry about allocation failure,
or leaking the locale when using this in library code (and then
unloading the library). Or you could have complicated library
init/uninit functions, which bring a big load of their own mess.
Same for automagic DLL constructors/destructors.
- Not all functions have a variant that takes a locale argument, and
they missed even some important ones, like snprintf() or strtod() WHAT
THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT
THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK

I would like to know why it took so long to standardize a half-assed
solution, that, apart from being conceptually half-assed, is even
incomplete and insufficient. The obvious way to fix this would have
been:

- deprecate the entire locale API and their use, and make it a NOP
- make UTF-8 the standard character type
- make the C locale behavior the default
- add new APIs that explicitly take locale objects
- provide an emulation layer, that can be used to transparently build
legacy code without breaking them

But this wouldn't have been "compatible", and the apparently incompetent
standard committees would have never accepted this. As if anyone
actually used this legacy garbage, except other legacy garbage. Oh yeah,
and let's care a lot about legacy compatibility, and let's not care at
all about modern code that either has to suffer from this, or subtly
breaks when the wrong locales are active.

Last but not least, the UTF-8 locale name is apparently not even
standardized. At the moment I'm trying to use "C.UTF-8", which is
apparently glibc _and_ Debian specific. Got to use every opportunity to
make correct usage of UTF-8 harder. What luck that this commit is only
for some optional relatively obscure mpv feature.

Why is the C locale not UTF-8? Why did POSIX not standardize an UTF-8
locale? Well, according to something I heard a few years ago, they're
considering disallowing UTF-8 as locale, because UTF-8 would violate
certain ivnariants expected by C or POSIX. (But I'm not sure if I
remember this correctly - probably better not to rage about it.)

Now, on to libarchive.

libarchive intentionally uses the locale API and all the broken crap
around it to "convert" UTF-8 or UTF-16 (as contained in reasonably sane
archive formats) to "char*". This is a good start!

Since glibc does not think that the C locale uses UTF-8, this fails for
mpv. So trying to use archive_entry_pathname() to get the archive entry
name fails if the name contains non-ASCII characters.

Maybe use archive_entry_pathname_utf8()? Surely that should return
UTF-8, since its name seems to indicate that it returns UTF-8. But of
fucking course it doesn't! libarchive's horribly convoluted code (that
is full of locale API usage and other legacy shit, as well as ifdefs and
OS specific code, including Windows and fucking Cygwin) somehow fucks up
and fails if the locale is not set to UTF-8. I made a PR fixing this in
libarchive almost 2 years ago, but it was ignored.

So, would archive_entry_pathname_w() as fallback work? No, why would it?
Of course this _also_ involves shitfucked code that calls shitfucked
standard functions (or OS specific ifdeffed shitfuck). The truth is that
at least glibc changes the meaning of wchar_t depending on the locale.
Unlike most people think, wchar_t is not standardized to be an UTF
variant (or even unicode) - it's an encoding that uses basic units that
can be larger than 8 bit. It's an implementation defined thing. Windows
defines it to 2 bytes and UTF-16, and glibc defines it to 4 bytes and
UTF-32, but only if an UTF-8 locale is set (apparently).

Yes. Every libarchive function dealing with strings has 3 variants:
plain, _utf8, and _w. And none of these work if the locale is not set.
I cannot fathom why they even have a wchar_t variant, because it's
redundant and fucking useless for any modern code.

Writing a UTF-16 to UTF-8 conversion routine is maybe 3 pages of code,
or a few lines if you use iconv. But libarchive uses all this glorious
bullshit, and ends up with 3 not working API functions, and with over
4000 lines of its own string abstraction code with gratuitous amounts of
ifdefs and OS dependent code that breaks in a fairly common use case.

So what we do is:

- Use the idiotic POSIX 2008 API (uselocale() etc.) (Too bad for users
who try to build this on a system that doesn't have these - hopefully
none are left in 2017. But if there are, torturing them with obscure
build errors is probably justified. Might be bad for Windows though,
which is a very popular platform except on phones.)
- Use the "C.UTF-8" locale, which is probably not 100% standards
compliant, but works on my system, so it's fine.
- Guard every libarchive call with uselocale() + restoring the locale.
- Be lazy and skip some libarchive calls. Look forward to the unlikely
and astonishingly stupid bugs this could produce.

We could also just set a C UTF-8 local in main (since that would have no
known negative effects on the rest of the code), but this won't work for
libmpv.

We assume that uselocale() never fails. In an unexplainable stroke of
luck, POSIX made the semantics of uselocale() nice enough that user code
can fail failures without introducing crash or security bugs, even if
there should be an implementation fucked up enough where it's actually
possible that uselocale() fails even with valid input.

With all this shitty ugliness added, it finally works, without fucking
up other parts of the player. This is still less bad than that time when
libquivi fucked up OpenGL rendering, because calling a libquvi function
would load some proxy abstraction library, which in turn loaded a KDE
plugin (even if KDE was not used), which in turn called setlocale()
because Qt does this, and consequently made the mpv GLSL shader
generation code emit "," instead of "." for numbers, and of course only
for users who had that KDE plugin installed, and lived in a part of the
world where "." is not used as decimal separator.

All in all, I believe this proves that software developers as a whole
and as a culture produce worse results than drug addicted butt fucked
monkeys randomly hacking on typewriters while inhaling the fumes of a
radioactive dumpster fire fueled by chinese platsic toys for children
and Elton John/Justin Bieber crossover CDs for all eternity.

[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 07.08.2020 22:15]
07.08.2020 22:13:44  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
Der Rant ist pures Gold Breites Grinsen
07.08.2020 22:15:46  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GarlandGreene

Mod GIGN
drug addicted butt fucked monkeys randomly hacking on typewriters while inhaling the fumes of a radioactive dumpster fire fueled by chinese platsic toys for children are not amused.
07.08.2020 22:22:29  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
B0rG*

Gordon
 

Several decades later, the moronic standard committees noticed that this
was (still is) kind of a bad situation. Instead of fixing the situation,
they added more garbage on top of it.

(...)

So what we do is:

- Use the "C.UTF-8" locale, which is probably not 100% standards
compliant, but works on my system, so it's fine.

08.08.2020 0:13:25  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
MartiniMoe

AUP MartiniMoe 02.02.2019
 
Zitat von csde_rats

Scientists rename human genes to stop Microsoft Excel from misreading them as dates



08.08.2020 12:17:03  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
Those not comfortable
with toxic language should pretend this is a religious text.



Halbes Internet Breites Grinsen
08.08.2020 18:06:10  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
a1ex

a1ex_small2
Gut zur Belustigung, wenn jemand so eine Commit Message bei der Arbeit schreibt und nicht als Blogpost würde ich aber einen Bogen machen.
09.08.2020 13:09:32  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Farbkuh

farbkuh
Warum ist eigentlich der Thunderbird 78 noch nicht in den Debian Repos?

e: Ah, okay. Intensivere Recherche hat ergeben, dass ich 78 nur über experimental bekomme, dafür muss ich auf unstable wechseln. Das will ich dann irgendwie doch nicht. Dann installiere ich vong Hand.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Farbkuh am 09.08.2020 17:16]
09.08.2020 17:09:13  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Farbkuh

farbkuh
Gibt's ne Möglichkeit von meinem Debian System einen Bootstick mit Persitenz zu erstellen?
Weiterhin: Empfehlung für ein Backup-Tool unter Debian?
15.08.2020 14:52:16  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
MartiniMoe

AUP MartiniMoe 02.02.2019
 
Zitat von Farbkuh

Weiterhin: Empfehlung für ein Backup-Tool unter Debian?


Borg natürlich fröhlich
15.08.2020 15:34:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
+1 für borg.
15.08.2020 15:45:39  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Farbkuh

farbkuh
Habs mal installiert. Mit gui ist mir zwar immer lieber, aber da fuchs ich mich schon rein. Sonst hätte ich auch bei Windows bleiben können Breites Grinsen
15.08.2020 15:49:01  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Wayland beherrscht kein Color Management? Ernsthaft? Soll das ein Witz sein?

 

1. none of the key developers have the faintest idea what Color or Color Management is, and (worse):
2. they have no idea why it would be at all important.



-- Entwickler (gwgill) eines Color Management Systems für Linux

Bwahahahahaha

"Die Welt war, ist und bleibt sRGB. Basta!"

--Wayland, 2020.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 18.08.2020 18:53]
18.08.2020 18:48:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
a1ex

a1ex_small2
Holy fuck. Ich war irgendwie fest davon ausgegangen dass sowas drin sein sollte Breites Grinsen
18.08.2020 22:19:46  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
mYstral

Arctic
Bitte ELI5: was ist das und warum ist das wichtig. peinlich/erstaunt
19.08.2020 14:13:53  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
scheint aber auch in arbeit zu sein
HDR support in Weston
WIP: unstable: add color management protocol
19.08.2020 15:42:44  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
 
Zitat von mYstral

Bitte ELI5: was ist das und warum ist das wichtig. peinlich/erstaunt



Das Ziel von Farbmanagement ist es zu ermöglichen, dass wenn du und ich die gleiche Bilddatei betrachten, wir möglichst ähnliche Farbreize wahrnehmen, also "das gleiche Bild" sehen.

Die Methode ist, dass man Pixeln zuordnet, auf welchen Farbraum sie sich beziehen, wobei ein Farbraum schlicht definiert, welche numerischen Pixelwerte zu welchen Farben gehört. [2] Früher war das nicht so wichtig, weil Videos und Bilder idR 8-Bit sRGB waren, und Bildschirme eben auch nur 6 oder 8 bit sRGB darstellen konnten. Heute sind aber Bildschirme, die mehr als sRGB können ziemlich Standard ("Wide Gamut")[1]. Die verwenden dann Farbräume wie z.B. DCI P-3. Wenn jetzt aber das Fenstersystem gar nicht weiß, was "sRGB" oder "P3" sein soll, sondern einfach dumm die Pixel von den Anwendungen zum Bildschirm durchreicht, dann kommen dabei halt u.U. die falschen Farben raus. #123456 ist eine andere Farbe in P3 als in sRGB. Die andere Sache ist, dass man seinen Bildschirm evtl. kalibrieren möchte, d.h. mit einem Messgerät (~50-100 ¤) geht man hin und misst was da eigentlich für Farben rauskommen. Clevere Software berechnet dann quasi rückwärts, welche Pixelwerte man hinschicken muss, damit die richtige Farbe rauskommt. Das Ergebnis ist dann eine 3D-LUT / ein ICC-Profil. Und die Stelle, die dafür verantwortlich ist dieses Profil auf den jeweiligen Monitor anzuwenden, ist das Fenstersystem. Genauso muss es möglich sein für Anwendungen mitzuteilen, in welchem Farbraum ihre Ausgabe ist oder sein soll.


[1] Nicht vorhandenes Farbmanagement ist der Grund, wieso die Farben viel gesättigter aussehen, wenn man einfach hingeht und einen "Wide Gamut" Bildschirm im OSD auf "AdobeRGB" stellt und trotzdem mit sRGB füttert.
[2] Nahezu alle Farbräume sind in Bezug auf den "CIE 1931 XYZ"-Farbraum definiert. Grob gesagt ist man hingegangen und hat geschaut, welche Wellenlängen man so sehen kann, und wie eine Mischung von Wellenlängen gewichtet wahrgenommen wird. Das Ergebnis ist diese Fläche hier (XY-Ebene, Z ist Helligkeit)



Ein Farbraum, der via CIE XYZ definiert ist, wäre sRGB:



Man sucht sich xy-Koordinaten für die Rot, Grün und Blau Primärfarben (oder auch Cyan, Magenta, Gelb => CMYK) aus und definiert welche Intensitäten dazu gehören usw usf. ist in Wahrheit alles viel komplizierter, XYZ stellt auch nicht die Wahrnehmung dar, sondern nur, was man ungefähr so sehen kann (ins rote fehlen ein paar nm...). Es gibt "Perceptual Color Spaces", die sich im Grunde als Abbildung vom XYZ-Farbraum darstellen und dir einen Raum erzeugen, in dem z.B. die Distanz zweier Punkte proportional zu einer Wahrnehmungseigenschaft ist (z.B. "sieht doppelt so hell aus", "der Farbunterschied zwischen A und B sieht genauso groß aus wie zwischen B und C"). Die aktuellste dieser Abbildungen ist afaik CIECAM02 und der Raum hat plötzlich sechs statt drei Dimensionen (brightness, lightness, colorfulness, chroma, saturation, and hue).

tl;dr Farben sind wahnsinnig komplexe Gebilde.

99.9 % davon braucht aber Wayland nicht interessieren, im Grunde will man da nur eine API haben, wo Anwendungen abfragen können, welchen Farbraum das Display nominal hat, und eine API um dem Ding zu erklären, in welchem Farbraum man gerade seine Pixel ausgibt (mehr als 8 Bit pro Kanal wird Wayland wohl können, denn ohne das machen viele Dinge kein Sinn). Wayland selbst braucht dann eigentlich nur zwischen einer Handvoll Farbräumen konvertieren können (sRGB, P3, AdobeRGB1998, Rec.2020, Rec.709, was de-fakto sRGB mit echtem Gamma statt gestückelter Funktion ist) und am Ende ein ICC-Profil (~3D LUT) drauf anwenden.
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 19.08.2020 22:22]
19.08.2020 22:10:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
mYstral

Arctic
Sehr interessant, vielen Dank! Wenn ich die zweite Abbildung richtig interpretiere, "fehlen" dann sehr viele Farben bei sRGB?
20.08.2020 10:31:43  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Hätte jetzt auch angenommen, dass das schon drin ist, weil GNOME ja Farbprofile verwalten kann.

 
Zitat von csde_rats

Wayland beherrscht kein Color Management? Ernsthaft? Soll das ein Witz sein?
--Wayland, 2020.



Womöglich liegt es ja nur daran, dass der Herr Cain aus dem Panzermuseum Munster der Hauptsponsor von Wayland ist







https://aur.archlinux.org/packages/vmware-workstation/#pinned-760003]VMWare funktioniert mit Kernel 5.8 nicht.
 

Be careful: Linux 5.8 breaks compatibility with VMware Workstation. If you try to start a VM, your system will crash and probably reboot.


Es ist etwas mehr als nur wahrscheinlich.


Anwendung für MacOS signieren, notarisieren und anheften?
Kratzt nur am Problem. Die manuellen Schritte und Prozesse sind schlecht dokumentiert und die Werkzeuge von Apple sind auch nicht berauschend. Portieren von Quellcode geht, die Anwendung auslieferbar zu machen ist das größte Problem. So lange man alles mit XCode machen kann und muss sollte es soweit "okay" sein.
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 20.08.2020 16:24]
20.08.2020 14:10:05  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
 
Zitat von mYstral

Sehr interessant, vielen Dank! Wenn ich die zweite Abbildung richtig interpretiere, "fehlen" dann sehr viele Farben bei sRGB?



sRGB ist ein recht kleiner Farbraum, der für fast alles groß genug und sehr weit verbreitet ist.
Wenn du Photos drucken lässt, muss du dir schon Mühe geben, einen Dienstleister zu finden, der mehr als sRGB druckt.

AdobeRGB wurde eigentlich mal eingeführt, um den Farbraum von Druckern auszunutzen, heute druckt man aber fast immer nur Farben aus dem sRGB-Farbraum.

Monitore mit größerem Farbraum kann man heute zwar kaufen: https://geizhals.de/?cat=monlcd19wide&asuch=&bpmin=&bpmax=&v=e&hloc=at&hloc=de&plz=&dist=&mail=&fcols=11960&fcols=11961&fcols=11962&bl1_id=30&sort=-filter11962#productlist
wenn man das Geld dafür hat, nützlich sind sie aber nicht unbedingt.
Bilder auf Webseiten, Dekoelemente, Werbebanner, COmputerspiele etc*. sind idR für sRGB gemacht. Wenn du die auf einem Monitor mit größerem Farbraum anschaust kannst du entweder über ein Farbprofil (oder manchmal per Menüeinstellung vom Monitor) den Farbraum auf sRGB beschränken, was aber negative Nebeneffekte haben kann, oder dich auf auf viel zu knallig bunte Bilder einstellen.

 
ins rote fehlen ein paar nm...


Der Laser den man so um 800 nm rum tunen kann sieht schon interessant aus peinlich/erstaunt
CIE 1931 XYZ geht von 380 bis 770?

*Wie ist das eigentlich bei Netflix, Amazon Prime, Youtube?
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Rootsquash am 20.08.2020 14:18]
20.08.2020 14:15:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Die XY-Gamutfläche ist tatsächlich auch leicht irreführend, eben weil es kein perceptual space ist, die Distanz zwischen Punkten ist also wahrnehmungsmäßig bedeutungslos. Deswegen sind XY-Diagramme, wo mehrere Farbräume eingezeichnet sind etwas irreführend, weil die Flächenunterschiede keineswegs mit "proportional mehr/weniger Farben wahrnehmbar" korrelieren. Pi mal Daumen sind die Grüntöne in XY stark gestreckt, während Rottöne leicht und Blautöne im Vergleich stark "komprimiert" sind. Ein numerischer Unterschied im Grünbereich, den man gerade so wahrnehmen kann, wäre im blauen Bereich ein deutlicher Unterschied. Diese Tendenz kann man MacAdam-Ellipsen entnehmen:



Und damit im Hinterkopf dann nochmal AdobeRGB vs sRGB (und auch immer im Hinterkopf behalten, dass die Farben im XY-Diagramm symbolisch sind, weil sRGB jetzt nicht so viel von dieser Fläche ausfüllt):



Was Content angeht, richtiges HDR(-Gaming) findet nicht in 8-Bit sRGB statt. Youtube macht HDR-Videos mit Rec. 2020 und HLG soweit ich weiß. Ich glaub DisplayHDR 100 (oder 400?) war die Mogelpackung, die einfach ein normaler Bildschirm kann. Videoproduktion scheint der Fotografie technologisch voraus zu sein (was irgendwie eine Konstante zu sein scheint), siehe ACES-Konzept.

Wie viele Farben wollen sie haben?





Wobei das nicht der spannende Teil ist, sondern eher die Idee einen einheitlichen Scene-Referred Workflow (inkl. VFX/CG) zu haben.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 20.08.2020 16:47]
20.08.2020 16:45:26  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Rats verschmitzt lachen

Zeichne jetzt doch mal deinen Gamingmonitor da ein!
20.08.2020 17:47:42  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Kein Problem!



Alle drei Farben!
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 20.08.2020 17:55]
20.08.2020 17:55:11  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
 
Zitat von csde_rats

und auch immer im Hinterkopf behalten, dass die Farben im XY-Diagramm symbolisch sind, weil sRGB jetzt nicht so viel von dieser Fläche ausfüllt:



Damit man den unterstützten Farbraum korrekt sieht, müsste man den Bildern dieser Gamutflächen eigentlich einen riesigen Farbraum und als Intention wahrscheinlich "Absolute Colorimetric" zuweisen.
Zeichnet man dann auf einem System mit funtionierendem Farbmanagement den abgedeckten Farbraums ein, sollte selbiger Bereich (also z.B: das sRGB-Dreieck) dann am Rand gesättigt sein. Rundum sollten die Farben sich dann zum Rand hin nicht mehr ändern, da sie ja auch voll gesättigt sein sollten.


hoschi: https://i.rtings.com/images/reviews/monitor/benq/ex2780q/ex2780q-color-gamut-2020-large.jpg ? ach was weiß ich was rats gerade als Monitor hat.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 20.08.2020 18:00]
20.08.2020 18:00:24  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Aus dem neuesten Smith Film Gemini Man:
Die Guten haben einen Mac! Schon wieder. Aber Linux und GNOME!



Und endlich weiß ich, warum man im Terminal den Fenstertitel ändern kann. Nur gefallen mir leider die letzten Filme mit Will Smith nicht so, erinnert mich auch alles sehr an Assassins - Die Killer.




 
Zitat von csde_rats

Kein Problem!



Alle drei Farben!




Ist eine Optimierung auf schnelle Umschaltzeiten Augenzwinkern
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 20.08.2020 18:08]
20.08.2020 18:05:21  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
Gaming:

Bildbearbeitung:
21.08.2020 10:19:38  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Gerade Levenshtein verstanden. Mein Hirn hat die Wikipediaeinträge dazu erfasst, wollte das Vorgehen jedoch nicht validieren. Bei dem PDF habe ich es dann verstanden.

Manchmal braucht es wohl länger bei mir
Hauptsache im Hirn
21.08.2020 15:13:51  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
Lustiges Kontstrukt :icon14:
21.08.2020 15:40:39  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
chrome verursacht sehr viel last auf den DNS root servern

irgendwie check ichs nicht ganz, die chrome devs sind doch klug.
wenns denen nur um nen nxdomain geht, wieso checken die dann nicht einfach auf ein

<random>.random.google.com. -> alles unterhalb von random.google.com. kriegt nen nxdomain zurück?

und lassen so die dns root server in ruhe?
21.08.2020 16:16:45  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Habe jetzt auf beiden Laptops den Intel 2D Treiber (DDX?) entfernt. Bis jetzt merke ich keine Nebenwirkungen.

# pacman -Rns xf86-video-intel


Also macht jetzt Linux alles mit Kernel-Mode-Setting und obendrauf GLAMOR. Ein Entwickler von GNOME hatte mich darum gebeten, weil wohl praktisch niemand mehr etwas mit dem 2D Treiber von Intel testet.
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 22.08.2020 19:34]
22.08.2020 19:33:31  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 157 158 159 160 [161] 162 163 164 165 ... 215 nächste » letzte »

mods.de - Forum » Linux » 

Hop to:  

Thread-Tags:
gnu  linux 
| tech | impressum