ugrás a tartalomhoz

Responsive Images and Web Standards at the Turning Point

Joó Ádám · 2012. Május. 19. (Szo), 15.51
A rugalmas képek hányatott sorsú szintakszisa
 ■
1

progresszív jpeg?

szabo.b.gabor · 2012. Május. 20. (V), 19.13
miért nem lehet ezt úgy megoldani, hogy van egy darab kép, ami olyasmi mint egy progresszív jpg, tehát ahogy töltődik le egyre nagyobb a felbontás.

a kliens pedig eldönti magának, hogy mennyit akar letölteni magának. aztán viszon'látásra.

mit kell ezzel ennyit kavarni?
2

támogatás, minőség

Poetro · 2012. Május. 20. (V), 21.04
A progressive jpeg támogatása a régi böngészőkben rossz. Ezen kívül egy weboldalon nem feltétlen csak jpeg képek vannak (leginkább nem), hanem inkább png, a feltöltött fotók kivételével. Azaz ha te valahol minőségi képeket akarsz felrakni, mondjuk grafikonokat, vagy más ábrákat, akkor biztosan nem fogsz jpeg-et használni. Ezen kívül a progressive jpeg felbontás szabályzása ugye igazából nem jól szabályozható, a leggyakrabban csak váltott soros (interlaced) képet jelent, ami ugye csak függőlegesen skálázódik, de például negyed / nyolcad akkora kép esetén is le kell tölteni ugyanakkorát, mint feleakkora kép esetén, valamint a progressive jpeg eleve nagyobb, mint a nem progressive változat.
4

ha jól tudom a progresszív

szabo.b.gabor · 2012. Május. 21. (H), 12.10
ha jól tudom a progresszív jpeg mérete épp hogy kisebb. nem tudom hogy a blogban leírt megoldást mennyire támogatják a régebbi böngészők.

mindenesetre akkor is azt mondom, hogy ahelyett, hogy ezzel szívatják magukat, inkább ki kellene találni egy 'veszteséges' és egy 'veszteségmentes' (ez ugye kicsit viccesen hangzik) képformátumot, ami a letöltött adatmennyiség arányában skálázódik, valamint a böngészőket ehhez igazítani.

így a dpi különbségekből fakadó problémák is, valamit a különböző szélességű képek problémája is megoldható lenne. és nem kellene rossz megoldásokat keresni egy meglévő problémára.

valamint az sem mellékes, hogy valószínűleg egy ilyen kép helyigénye kisebb lenne, mint az összes legenerált változaté (szerveren azért csak tárolni kell), valamint egy letöltött bélyegkép információi használhatóak lennének a nagyobb kép megjelenítésénél is, a böngészők automatikusan tudnának low-res módba váltani ha pl sávszélességet akarok spórolni, stb...
5

PNG

Poetro · 2012. Május. 21. (H), 13.04
Most, hogy elolvastam a PNG specifikációját, abban is van lehetőség progressive kiszolgálásra, sőt a GIF JPEG is elég "okos" ezen a téren. Ezzel foglalkozik többek között a PNG: The Definitive Guide, ennek is a 1.2.3. Interlacing and Progressive Display és 8.6. Interlacing and Progressive Display fejezetei. Ahogy látható a JPEG renderelésén, azért már elég korán van használható információ progressive kép esetén, PNG és GIF esetén kicsit később kapunk egyáltalán használható információt (első oszlop a GIF a többi a PNG különböző interlaced / progressive módjait mutatja).

Természetesen ehhez a böngészőket is fel kell készíteni, hogy a fenti képformátumokból csak annyit töltsenek le, amennyi tényleg szükséges, és még elégséges információ (hogy ezt ki határozza meg, jó kérdés). Például a progressive JPEG megjelenítése az Internet Explorer régebbi változatainak nehézséget okoz, és az Windows 7 előtti változatok csak a teljes kép letöltése után képesek megmutatni a képet.
6

wow :) ezek szerint Te is

szabo.b.gabor · 2012. Május. 21. (H), 13.37
wow :)

ezek szerint Te is járható útnak tartod a felvázolt ötletem (nem néztél volna utána), valamint 'csak' a böngészőket kellene felkészíteni, hogy kezelni tudják ezt a módot.
3

Sebesség

Hidvégi Gábor · 2012. Május. 21. (H), 09.51
Szerintem az jobb lenne, ha valamilyen módon megoldanák a kapcsolat sebességének mérését (például az utolsó tíz perc átlaga alapján), és a böngésző az alapján tudna választani a felsorolt képek közül.
7

Írtam a listára, ez a válasz

szabo.b.gabor · 2012. Május. 22. (K), 11.49
Írtam a listára, ez a válasz jött (:

On Tue, May 22, 2012 at 12:39 AM, Gábor Szabó wrote:
why don't we keep the current markup and use progressive images. this way
the browser could decide what resolution he needs, and when to stop
downloading. this would solve the problem
-----------

This doesn't work. You can't stop a TCP download on a dime, due to TCP windowing, and aborting a download kills pipelined transfers, which ruins performance. You'd need to know in advance how many bytes to download to receive a given number of JPEG passes, which complicates things a lot; you'd need to inline a pass count/byte range index, which creates a harsh data dependency.

JPEG quality is also a different axis of quality than changing resolution; if you want to drop the resolution by 1/2x or 1/4x, you often really do want to use an image authored at a lower resolution rather than using a lower-quality image, especially for non-photographic art like icons. It doesn't really work for PNG, either, since partial interlaced PNGs are too low-quality to be of much practical use (at least JPEG gives a reasonable quality--but no alpha).
8

Lehetne csinálni a képeknek

Hidvégi Gábor · 2012. Május. 22. (K), 14.32
Lehetne csinálni a képeknek egy tárolófájlt, aminek az elején van egy index, aztán pedig maguk a képek bemásolva. A böngésző elkezdené letölteni ezt a fájlt, feldolgozná az indexet, meghatározná a felhasználó beállításai alapján, hogy melyik képre van szüksége, és a megfelelő pozícióról letöltené.
9

Egyszerűbb lenne a kép

Joó Ádám · 2012. Május. 22. (K), 20.26
Egyszerűbb lenne a kép MIME-típusokhoz definiálni paramétereket, amelyeket az aktuális elvárásnak megfelelően a böngésző fűzne hozzá egy Accept fejléchez, és a kiszolgáló döntené el, hogy mit küld a válaszban.
10

Még jobb.

Hidvégi Gábor · 2012. Május. 22. (K), 20.37
Még jobb.