Gradient werkt niet goed in Firefox op Windows.

[MoietyMe]

Goede middag!

Op mijn werk ben ik samen met een collega bezig met een website. Alleen lopen we tegen een probleem aan met Firefox. De gradient die we op de achtergrond hebben word namelijk niet correct getoond. In alle andere browsers (incl. Firefox op de Mac) toont hij het wel goed. Het is dus echt alleen Firefox (3.0) op Windows.



Iemand enig idee waar dit door komt en hoe dit op te lossen is?

Voor de geïnteresseerde: de gradient loopt van #507d9e naar #517e9d

[ Voor 7% gewijzigd door MoietyMe op 05-05-2009 11:22 . Reden: kleurcodes toegevoegd. ]

[RobIII]

Zonder relevante(!!) code (HTML/CSS) en/of een online (uitgeklede!) testcase kunnen we hier natuurlijk niets zinnigs op zeggen...

Edit:
Ik heb behoorlijk zitten turen naar überhaupt de gradient; het blijkt dus in de bovenste 3 pixels te zitten in de rechter screenshot (IE). In dat geval lijkt me in de linker een repeat-y van kracht die rechts niet van kracht is. Je ziet links ook wel "iets" van herhaling, maar ik moet (op matig tot goede schermen) toch behoorlijk staren om 't rechts goed te zien; ik zie dan ook weinig nut in die gradient. 't Voegt weinig toe.

[ Voor 69% gewijzigd door RobIII op 05-05-2009 11:30 ]

[Yoki1985]

Met de beste wil van de wereld, maar ik zie GEEN verschil tussen die blauwe vlakken

[RobIII]

yoki2007 schreef op dinsdag 05 mei 2009 @ 11:31:
Met de beste wil van de wereld, maar ik zie GEEN verschil tussen die blauwe vlakken

See? Dat bedoel ik. Op een gemiddeld scherm zul je deze "gradient" niet eens of amper zien; en omdat 'ie ook nog maar in de bovenste, what, 3 pixels ofzo zit is 't sowieso redelijk nutteloos met een dergelijk kleine verloop.



Links #507d9e en rechts #517e9d. En dan op een verloop van een paar pixels zoiets 'gradient' durven noemen vind ik wat ver gaan Ik zou haast roepen dat je een grap met ons aan 't uithalen bent.

[ Voor 26% gewijzigd door RobIII op 05-05-2009 11:43 ]

[Verwijderd]

Ik zie bij firefox wat dithering?

[begintmeta]

Recht zit het (minimale) verloop inderdaad in de bovenste pixels, links wordt dat verloop om de paar pixels weer herhaald.

Wat heb je eraan? De firefox-versie is tenminste te zien

[ Voor 20% gewijzigd door begintmeta op 05-05-2009 11:40 ]

[Verwijderd]

In de Firefox-versie zit veel banding. Tenminste, daar lijkt het op. Maar in werkelijkheid herhaalt zich een gradient van slechts enkele pixels hoogte, ongeveer om de 10 pixels. Deze lijkt niet identiek aan de gradient in de eerste pixels helemaal bovenaan.

[ Voor 74% gewijzigd door Verwijderd op 05-05-2009 11:47 ]

[MoietyMe]

Er zit wel degelijk een gradient in. Het is gewoon een plaatje van 530 px hoog geëxporteerd als PNG (als maakte het type niet uit voor het resultaat). Inmiddels hebben we trouwens besloten om het maar gewoon één kleur te maken.

Het ziet er in ieder geval naar uit dat Firefox niet overweg kan met kleine verschillen in een gradient.

@RobIII: wij krijgen het zo van onze designer, dus dan zullen we het ook zo moeten maken, maar na wat overleg mogen we het gelukkig veranderen. Gelijk even doorgegeven dat zulke kleine overgangen niet meer hoeven

[ Voor 24% gewijzigd door MoietyMe op 05-05-2009 11:48 ]

[Steephh]

Op mijn Samsung 2443 BW kan ik in de linker afbeelding horizontale streepjes zien, valt opzich best op. Rechterafbeelding lijkt egaal vergeleken met de linker.. Ligt dat nu aan mij?

[RobIII]

Good Fella schreef op dinsdag 05 mei 2009 @ 11:46:
Het ziet er in ieder geval naar uit dat Firefox niet overweg kan met kleine verschillen in een gradient.

Echt wel / nonsens. Je doet geheid iets verkeerd, maar again: zonder relevante code of een online testcase kunnen we niets zinnigs zeggen. Ik gooi 't (nog steeds) op een repeat-y.

Good Fella schreef op dinsdag 05 mei 2009 @ 11:46:
Het is gewoon een plaatje van 530 px hoog geëxporteerd als PNG

In 't voorbeeld dat je hier post zit de gradient in de bovenste 4 pixels en is 'ie zéker geen 530 pixels hoog (de gradient dus).

[ Voor 33% gewijzigd door RobIII op 05-05-2009 11:50 ]

[MoietyMe]

RobIII schreef op dinsdag 05 mei 2009 @ 11:47:
[...]

Echt wel. Je doet geheid iets verkeerd, maar again: zonder relevante code of een online testcase kunnen we niets zinnigs zeggen. Ik gooi 't (nog steeds) op een repeat-y.


[...]

In 't voorbeeld dat je hier post zit de gradient in de bovenste 4 pixels en is 'ie zéker geen 530 pixels hoog (de gradient dus).

Omdat je zo aandringt () even een testcase online: http://dev.agosto.nl/firefox-gradient/

offtopic:
In de echte website staat de css natuurlijk netjes in een eigen file..

[begintmeta]

Er zit niet echt een noemenswaardig verloop in de rechter hoor (of in je online-voorbeeld), kijk maar eens naar de kleurwaarden (met Digital Color Meter bijvoorbeeld), in de linker/win-ff zitten streepjes.

[ Voor 9% gewijzigd door begintmeta op 05-05-2009 11:53 ]

[Verwijderd]

Het IE screenshot en de testcase tonen bij mij een egaal vlak (Opera). Op de paar eerste pixels van het blauwe vlak na.

[begintmeta]

Ik denk dat iets mis is met 'bg-total.jpg' helaas kan ik firefox op windows niet even bekijken.

[RobIII]

Good Fella schreef op dinsdag 05 mei 2009 @ 11:50:
[...]

Omdat je zo aandringt () even een testcase online: http://dev.agosto.nl/firefox-gradient/

offtopic:
In de echte website staat de css natuurlijk netjes in een eigen file..

Begin eens met van de jpg een png/gif te maken...

Ik heb 't getest en met png/gif werkt het. Of er dan iets raars in je jpg zit ofzo... ik kijk even verder.
Er is iets met je jpg aan de hand. Ik zal mijn 3 versies (jpg/gif/png) even online zetten. Hier. Alle 3 werkend/goed.

[ Voor 28% gewijzigd door RobIII op 05-05-2009 12:01 ]

[apNia]

RobIII schreef op dinsdag 05 mei 2009 @ 11:54:
[...]

Begin eens met van de jpg een png/gif te maken...

Ik heb 't getest en met png/gif werkt het. Of er dan iets raars in je jpg zit ofzo... ik kijk even verder.

Als je http://dev.agosto.nl/firefox-gradient/bg-total.jpg los pakt vanuit FF dan zitten die lijnen er ook in. Ik denk dat er idd een fout in de JPG zit icm de manier hoe FF hem rendert.

[MoietyMe]

RobIII schreef op dinsdag 05 mei 2009 @ 11:54:
[...]

Begin eens met van de jpg een png/gif te maken...

Ik heb 't getest en met png/gif werkt het. Of er dan iets raars in je jpg zit ofzo... ik kijk even verder.
Er is iets met je jpg aan de hand. Ik zal mijn 3 versies (jpg/gif/png) even online zetten.

Hmm inderdaad. Ging er eigenlijk van uit dat mijn collega dat ook al had geprobeerd. Dat werkt inderdaad wel!

[RobIII]

Good Fella schreef op dinsdag 05 mei 2009 @ 12:00:
Ging er eigenlijk van uit dat mijn collega dat ook al had geprobeerd.

Assumptions are the mother of all fuckups

[apNia]

Good Fella, JPG lijkt me per definitie wel het juiste formaat voor het opslaan van non-transparante gradients (of heb ik het fout ppl?), waarin heb je het opgeslagen?

[MoietyMe]

@Roblll: dat blijkt wel weer. Volgende keer even wat beter communiceren In ieder geval bedankt!

@apNia: PNG is vaak kleiner dan JPG en behoud de ware kleuren.

[Verwijderd]

Zow ben ik met dit topic ook uit de brand geholpen!

Heb een soortgelijk probleem (streperige gradient) maar met het via Photoshop exporteren viel het al wat minder op.( gebruik Fireworks) Ik zou .png eens proberen.

Edit. En dat ziet er stukken beter uit!

[ Voor 14% gewijzigd door Verwijderd op 05-05-2009 12:49 ]

[MoietyMe]

Verwijderd schreef op dinsdag 05 mei 2009 @ 12:16:
Zow ben ik met dit topic ook uit de brand geholpen!

Heb een soortgelijk probleem (streperige gradient) maar het via Photoshop exporteren viel het al wat minder op. Ik zou .png eens proberen.

Dat had ik al gedaan, heb het ook even in de testcase gezet voor de mensen die daar nog naar keken.

Het is nu dus in ieder geval opgelost.

[Sebazzz]

apNia schreef op dinsdag 05 mei 2009 @ 12:02:
Good Fella, JPG lijkt me per definitie wel het juiste formaat voor het opslaan van non-transparante gradients (of heb ik het fout ppl?), waarin heb je het opgeslagen?

Jpeg comprimeert slechter, kan bij harde lijnen duidelijk lelijke artifacts kijken (kijk maar naar de screenshots in het RAID topic in OM, waar mensen al hun screenshots met Paint in JPEG opslaan), en PNG is gewoon zoveel beter

[begintmeta]

Sebazzz schreef op dinsdag 05 mei 2009 @ 12:19:
Jpeg comprimeert slechter, ...

Afhankelijk van de bitmap

[RobIII]

Sebazzz schreef op dinsdag 05 mei 2009 @ 12:19:
[...]

Jpeg comprimeert slechter

Bull; dat is nogal afhankelijk met welke compressieinstellingen en de afbeelding an sich is ook nog eens interessant. JPEG is, in feite, bedoeld voor foto's. Voor 'strakkere' afbeeldingen als illustraties/screenshots waarin veel minder kleuren en verlopen zitten gebruik je best GIF/PNG waarbij een GIF gelimiteerd is tot max. 256 kleuren.

Ik heb het niet helemaal gelezen (drukdrukdruk) maar dit lijkt me wel een relevant artikel: http://www.sitepoint.com/...jpg-png-whats-difference/ (let wel dat 't artikel stamt uit 1999 en dat de stand van zaken m.b.t. PNG inmiddels wel iets veranderd is qua ondersteuning e.d.)

[ Voor 32% gewijzigd door RobIII op 05-05-2009 12:50 ]

[apNia]

Sebazzz schreef op dinsdag 05 mei 2009 @ 12:19:
[...]

Jpeg comprimeert slechter, kan bij harde lijnen duidelijk lelijke artifacts kijken (kijk maar naar de screenshots in het RAID topic in OM, waar mensen al hun screenshots met Paint in JPEG opslaan), en PNG is gewoon zoveel beter

Omdat men opslaat met zware JPG compressie. Als ik in Photoshop een JPG opsla op 75% dan zie ik dit nagenoeg als lossless en kom ik toch wel beter uit als een PNG8 die een limiet heeft van 256 (toch?)

Net even getest op de image in de TS, en raargenoeg is PNG24 daar een kleiner bestand. Maar als ik een sterkere gradient maak waar de kleuren iets verder uiteen lopen wint JPG het overduidelijk. Zoals RobIII het zegt ligt het aan het aantal gelijke vlakken blijkbaar. Het is dus altijd een overweging.

Ik dacht omdat het om een gradient ging dat JPG de juiste keuze was, maar gezien het verschil zo achterlijk minimaal is, is PNG de juiste keuze

[MoietyMe]

@apNia: wat ik altijd doe is in Photoshop bij het exporteren kijken wat het kleinste is

[RobIII]

JPG gebruikt lossy compressie die, simpel gezegd, gegevens wegmikkert die 't menselijk oog "toch niet ziet" omdat de verschillen zo nihil zijn. GIF (mits binnen 256 kleuren) en PNG zijn lossless compressie methoden en zullen dus altijd weer 1 op 1 naar het origineel te 'decomprimeren' zijn. Ik snap niet dat mensen moeite hebben met deze concepten, zo heel moeilijk is 't toch ook weer niet als je je 5 minuten inleest?

Good Fella schreef op dinsdag 05 mei 2009 @ 13:27:
@apNia: wat ik altijd doe is in Photoshop bij het exporteren kijken wat het kleinste is

Dat is dus appels en peren vergelijken. Afhankelijk van compressieinstellingen (achterlijk hoge compressie bij JPG bijvoorbeeld maar met veel artefacts) kan dat namelijk nogal verschillen. Terwijl JPG (feitelijk "full color foto's") en GIF/PNG (feitelijk "illustraties en andere egale 'vlakken' of waarbij lossless vereist is) ieder hun eigen ("bedoelde") toepassingsgebied hebben.

[ Voor 74% gewijzigd door RobIII op 05-05-2009 13:33 ]

[apNia]

RobIII valt een JPG op quality 100 opslaan dan niet onder lossless? Lossless is toch compressie op basis van dingen die het oog niet ziet?

edit: ik heb bijvoorbeeld video's voor m'n werk opgeslagen met Lagarith codec.. dat is weer lossless
ik zie de nuances dan niet zo tussen RAW en lossless en JPG die kennelijk onder lossy valt

[ Voor 42% gewijzigd door apNia op 05-05-2009 13:46 ]

[Verwijderd]

apNia schreef op dinsdag 05 mei 2009 @ 13:42:
RobIII valt een JPG op quality 100 opslaan dan niet onder lossless? Lossless is toch compressie op basis van dingen die het oog niet ziet?

Bij lossless is sprake van geen verlies van informatie. Als je informatie weghaalt die je niet kunt zien of horen, is het gewoon lossy.

[RobIII]

apNia schreef op dinsdag 05 mei 2009 @ 13:42:
RobIII valt een JPG op quality 100 opslaan dan niet onder lossless?

Nee, want er is nog wel degelijk loss alleen minimaal (althans, zo even uit mijn blote bol; er zijn volgens mij wel lossless varianten van JPG, maar die zijn, AFAIK, zo goed als niet ondersteund door gemiddelde software als browsers of 'paint-achtigen').

quote: http://en.wikipedia.org/wiki/JPEG_2000#Features

Lossless and lossy compression: Like JPEG 1991,[1] the JPEG2000 standard provides both lossless and lossy compression in a single compression architecture. Lossless compression is provided by the use of a reversible integer wavelet transform in JPEG 2000.

apNia schreef op dinsdag 05 mei 2009 @ 13:42:
Lossless is toch compressie op basis van dingen die het oog niet ziet?

Nee, lossless is dat het gedecomprimeerde bestand 1:1 met het origineel overeen komt. Stel je voor dat een zipfile lossy zou zijn; dan zou een bestand na decomprimeren gewoon "beschadigd" zijn omdat er zaken 'verloren' zijn gegaan (hence: lossy). Zip, rar, png*, gif* etc. zijn dus lossless. MP3, JPG, MPEG etc. zijn lossy; zij mikkeren immers gegevens weg om 't bestand kleiner te maken en maken "misbruik" van menselijke beperkingen die je toch niet hoort/ziet (tenzij je de compressie natuurlijk te hoog zet).

* Mits je binnen de beperkingen blijft.

[ Voor 22% gewijzigd door RobIII op 05-05-2009 13:55 ]

[apNia]

Nou als ik lossless video opsla is er wel degelijk een verschil in filesize. Maar dat is dus blijkbaar compressie die op een andere manier comprimeert, net als RAR compressie, maar die de data dus intact houdt?

edit: OK duidelijk

[ Voor 5% gewijzigd door apNia op 05-05-2009 13:47 ]

[Sebazzz]

begintmeta schreef op dinsdag 05 mei 2009 @ 12:22:
[...]

Afhankelijk van de bitmap

Klopt, ik reageer toch ook op de "JPG lijkt me per definitie wel het juiste formaat voor het opslaan van non-transparante gradients (of heb ik het fout ppl?)"?

[Verwijderd]

In mijn geval heb ik met jpeg een slechtere output van lichte gradients dan met .png

[MoietyMe]

@RobIII: het ligt natuurlijk aan de afbeelding ja, maar op mijn werk moet JPG op 80% (Photoshop). Ik vind het belangrijk dat het er goed uit ziet. Dus ik zal vaak voor PNG gaan. Tenzij het een foto of iets dergelijks is.

[apNia]

Daar geloof ik echt niks van als je PNG24 opslaat of hoogste kwaliteit JPG. En in veel gevallen is met gradients JPG nog kleiner ook.

edit: in reply op jupjup

[ Voor 9% gewijzigd door apNia op 05-05-2009 14:53 ]

[RobIII]

Good Fella schreef op dinsdag 05 mei 2009 @ 14:52:
maar op mijn werk moet JPG op 80% (Photoshop)

Want Ook in PhotoShop kun je prima instellen welke compressie je wil en waarom die dan "volgens je werk op 80%" moet is me, los van een compressie-fetishist/nazi, dan ook een raadsel.

apNia schreef op dinsdag 05 mei 2009 @ 14:52:
En in veel gevallen is met gradients JPG nog kleiner ook.

Maar niet gegarandeerd 100% of "natuurgetrouw" met de originele kleur Bij JPG kan het zijn dat er "gerommeld" wordt met de kleuren Of je het ziet is een tweede; maar dat kan in bepaalde gevallen wel ja.

Again: JPG is lossy; een PNG(24) zal dat niet zijn. Los van bestandsgrootte zal de PNG altijd natuurgetrouw zijn waarbij dat bij een JPG (zeker bij subtiele gradients) altijd maar afwachten is.

[ Voor 81% gewijzigd door RobIII op 05-05-2009 15:01 ]

[MoietyMe]

@Robll: dat moet je niet aan mij vragen. Ik heb het niet verzonnen, ik heb me er alleen aan te houden.

[RobIII]

Good Fella schreef op dinsdag 05 mei 2009 @ 23:52:
@Robll: dat moet je niet aan mij vragen. Ik heb het niet verzonnen, ik heb me er alleen aan te houden.

En je voert dat braaf uit zonder even te informeren naar waarom zo'n (imho stompzinnige) regel ingevoerd is? Ik zou iig willen weten waarom ik geacht zou worden zoiets te doen. Als je nou eens zo nu en dan een betere kwaliteit kunt leveren door met de compressie op, zeg, 92% te zetten? En wie controleert het (en sterker: pin me d'r niet op vast maar volgens mij is achteraf de compressie niet eens meer te achterhalen)?

[ Voor 23% gewijzigd door RobIII op 06-05-2009 00:11 ]

[MoietyMe]

RobIII schreef op woensdag 06 mei 2009 @ 00:07:
[...]

En je voert dat braaf uit zonder even te informeren naar waarom zo'n (imho stompzinnige) regel ingevoerd is? Ik zou iig willen weten waarom ik geacht zou worden zoiets te doen.

Zal morgen eens informeren waarom dat precies zo zit. Al zijn we op zich best wel vrij, maar als het JPG is moet hij eigenlijk op 80%.

[crisp]

Good Fella schreef op dinsdag 05 mei 2009 @ 11:46:
[...]
@RobIII: wij krijgen het zo van onze designer, dus dan zullen we het ook zo moeten maken

Net als met de '80% compressie regel voor JPEG' geldt hier imo ook dat je als front-end developer af en toe best je eigen inzicht mag laten gelden hoor, of ben je echt alleen maar een codeklopper?

Als Femme hier weer eens aankomt* met een design vol gradients en dropshadows waarvan een aantal dusdanig subtiel dat het op bijna geen enkele monitor zichtbaar is dan ga ik daarover ook in conclaaf voordat ik de site volhang met overbodige background-images en onhandige HTML-constructies. Een designer die dat niet snapt kan zich beter enkel met print bezighouden...

* gecharcheerd, Femme weet doorgaans heel goed wat wel en niet handig is qua webdesign

[ Voor 5% gewijzigd door crisp op 06-05-2009 01:11 ]

[MoietyMe]

@crisp: Dat ben ik met je eens hoor. Alleen werd dit opgebouwd door een collega van mij. Het is alleen wel stom dat ik het niet meteen zag (dat de gradient eigenlijk nutteloos is). Na een kleine testcase in Photoshop was het verschil inderdaad zo klein dat we het weg gelaten hebben.

Wij geven onze designers ook nog altijd tips over wat wel en niet handig is, door fouten leert men is het niet?

[Verwijderd]

apNia schreef op dinsdag 05 mei 2009 @ 14:52:
Daar geloof ik echt niks van als je PNG24 opslaat of hoogste kwaliteit JPG. En in veel gevallen is met gradients JPG nog kleiner ook.

edit: in reply op jupjup

Dat jpeg kleiner is geloof ik meteen.

Werk altijd met jpeg maar in mn laatste project merkte ik onaanvaardbaar veel banding op bij een gradient. (jpeg 100 ook). Opgeslagen als .png en de banding was verdwenen.

Zoals gezecht gebruik ik normaal voor 99% zonder problemen jpeg maar nu liet die me dus wel in de steek..