Hlavní navigace

Vkládání dat do kvantizačních tabulek formátu JPEG

6. 12. 2022
Doba čtení: 21 minut

Sdílet

 Autor: Depositphotos
Dnes si společně vysvětlíme, jak je navrženo vkládání dat do kvantizačních tabulek programem Jpeginsert. Poté vložíme celovečerní film do 180kB obrázku a podíváme se, jak si s ním poradí některé programy.

Ještě jednou ze specifikace JPEGu ITU-T T.81 [PDF]:

 


Autor: ITU

Jaká je režie?

Do souboru tedy musí program Jpeginsert vkládat navíc:

  • 0xFF 0xDB
  • 2 bajty MSB first, délka rovná 2 + n-násobek 65
  • n-krát 65 bajtů, z nichž 6 horních bitů toho prvního musí být nulové. Sem můžeme dát užitečná data. Já bit číslo 1 (váha 2) použiju tak, že 0 znamená plně zaplněná tabulka, a 1 znamená že 1. bajt z 64 je délka (0-63) a zbytek je pak blok dat který tak může být kratší než 64 bajtů a tak se může realizovat libovolná délka nesených dat:
            #define SMALL_PAYLOAD 64
    
    [...]
    
            special_byte=global_buf[0];
    
    [...]
    
            if (special_byte&2){
                    /* Length bit is set */
                    unsigned char len=global_buf[1];
                    if (len>SMALL_PAYLOAD-1) len=SMALL_PAYLOAD-1;
                    fwrite(global_buf+2,len,1,stdout);
            }else{
                    /* Full data */
                    fwrite(global_buf+1,SMALL_PAYLOAD,1,stdout);
            }
    
  • Rád bych přenesl 64 bajtů na tabulku, což je 1,34 × 10154 kombinací, jenže díky zákazu nul má každý ze 64 bajtů jen 255 možností, což je jen 1,04 × 10154 kombinací. Přidám k tomu proto ještě bit 0 (váha 1) z toho extra bajtu, čímž se počet kombinací zdvojnásobí na 2,09 × 10154 kombinací, a do toho se už informace obsažená v 64 bajtech vejde:
            read_in_digits255_lsd_added1(global_buf+1);
            mpz_mul_ui(base255, base255, 2);
            mpz_add_ui(base255, base255, global_buf[0]&1);
    

Každá kvantizační tabulka má 65 bajtů, největší 2 + n-násobek 65, co se vejde do 2 bajtů, je pro n=1008: 65522=2+1008×65, hexadecimálně 0xFFF2=2+0x3F0×0x41.

Máme kapacitu 1008 64bajtových bloků = 64512 bajtů. Každý velký blok má délku 65524 bajtů (65522 + 2 za 0xFF 0xDB), účinnost tedy 98,46%. Takových bloků může být v souboru neomezené množství, protože ve standardu se píše, že takovéto hlavičkové bloky se mohou neomezeněkrát opakovat.

Co by se stalo, kdyby kvantizační tabulky někdo paušálně filtroval?

Na rozdíl od EXIFu těžko tato data bude někdo filtrovat, protože kvantizační tabulky jsou důležitá součást obrazových dat JPEG souboru. Pokud je všechny odfiltrují, žádné defaultní kvantizační tabulky nejsou ve standardu definovány a soubor se nezobrazí. Když jsem tabulky v JPEG souboru smazal, ukázalo se, že JPEGy bez kvantizačních tabulek mezi softwary vůbec nejsou v módě a nefrčí. Chromium ukázalo šedivý obdélník, Links rozbitý obrázek, G'MIC napsal tohle:

[gmic]-0./ Input file 'noqt.jpg' at position 0terminate called after throwing an instance of 'Magick::ErrorCoder'
  what():  Magick: Quantization table 0x00 was not defined (noqt.jpg) reported by coders/jpeg.c:445 (JPEGErrorHandler)
Magick: abort due to signal 6 (SIGABRT) "Abort"...

ImageMagick (convert) napsal:

convert-im6.q16: Quantization table 0x00 was not defined `noqt.jpg' @ error/jpeg.c/JPEGErrorHandler/335.

GPicView nezobrazil nic a napsal tuto chybovou hlášku:

 


Autor: Karel Kulhavý

Sofistikovanější filtrování než je všechny smazat ovšem existuje - Jpegtran (bezeztrátová rotace) to dělá, i když ho požádáme o maximální zachování dat.

Rozlišení od legitimních tabulek

Hned za prvními dvěma byty JPEGu může být legitimní kvantizační tabulka DQT, ale tato nikdy nebude definovat víc než čtyři kvantizační tabulky najednou, protože JPEG má pouze čtyři. Takže pět a více (5-1008) kvantizačních tabulek najednou budou jasná vložená data. Je to možné udělat, protože každá tabulka v souboru obsahuje číslo cílové tabulky, čili můžeme jednu tabulku opakovaně přepisovat. Pokud bude dat příliš málo, přebytečné kvantizační tabulky nastavíme na délku 0 mechanismem který jsem již vymyslel, že se nastaví horní bit dvoubitového volného pole (čísla tabulky) a první bajt z 64 vložených binárních bajtů bude délka, tady 0.:

        n_tables=(n_bytes-2)/TABLE_LEN;
        if (n_tables<=4) return 0;

Testování celovečerními filmy

 

Z iPhonových aplikací budeme testovat AirDroid, Documents, EXIF Viewer LITE, Files, Photos, RCam, Safari

Autor: Karel Kulhavý

Vložil jsem 917 MB VP8 720p celovečerní film Noc oživlých mrtvol do JPEGu o velikosti 180 kB. Vkládání trvalo 36 sekund. Pouhé kopírování souboru filmu přitom trvá 12 sekund. Výsledek měl 931 MB, režie byla tedy 14 MB a účinnost 98,46%. O kolik se zpomalí různé programy když se pustí na tento 931 MB JPEG a další JPEGy, které jsem vytvořil vkládáním různých multimédií:

Legenda barev
Správná funkce nebo pouze spletení binárních a decimálních jednotek
Nelze provést z důvodu, za který aplikace nemůže
Správná funkce aplikace, ale neresponzivní během provádění
Nepřiměřeně pomalá funkce aplikace
Selhání aplikace chybovou hláškou o přektročení velikostního limitu, zobrazení uniformního pole nebo náhradní textová informace
Nelze provést vinou aplikace
Chybná funkce aplikace vč. chybové hlášky, která neříká že se jedná o překročení velikostního limitu
Spadnutí aplikace
Vytuhnutí aplikace
Chybná funkce operačního systému
DoS útok na systém
Zhroucení se operačního systému
Program Doba načítání JPEGu o výsledné velikosti
3,8 MB 529 MB 931 MB 2,5 GB 4,0 GB 31 GB
pv (pouhé přečtení a zahození souboru) 0,01 s 0,4 s 0,6 s 25 s 41 s 7 min 52 s
G'MIC0,8 s4,3 s7,0 s27 s45 s6 min 52 s
ImageMagick (convert)0,1 s3,6 s6,2 s24 s43 s7 min 6 s
GIMP2,8 s7,5 s5,5 s29 s56 s< 9 min
Chromium, preview při výběru souboru na upload 0 s. 10 s. Nepřekresluje okno, nereaguje na zavření. 16 s. Nepřekresluje okno, nereaguje na zavření. 49 s. Nepřekresluje okno, nereaguje na zavření. 1 min 15 s. Nepřekresluje okno, nereaguje na zavření. < 15 min
Firefox preview při výběru souboru na upload 1 s 1 min 48 s. Nepřekresluje okno, nereaguje na zavření. 3 min 12 s. Nepřekresluje okno, nereaguje na zavření. 8 min 59 s. Nepřekresluje okno, nereaguje na zavření. 15 min 40 s. Nepřekresluje okno, nereaguje na zavření. Zhruba 1 h 20 min. Nepřekresluje okno, nereaguje na zavření.
(Náš!) Twibright Links 0,6 s 18 s (během toho okno nepřekresluje a nejde zavřít) 25 s (během toho okno nepřekresluje a nejde zavřít) Selže: Error "Too large file" Selže: Error "Too large file" Selže: Error "Too large file"
GPicView 2 s 3 min 18 s 3 min 49 s 15 min 33 s 21 min 15 s 4 h 46 min
Chromium, normální zobrazení 1,7 s 17 s 31 s, obrázek zobrazí ale těsně potom napíše "Aw, Snap! [...] Error code: 64000". Při druhém pokusu nezobrazí nic a hodí Aw Snap 5. Třetí pokus zase zobrazil, ale hned Aw Snap 64000. 49 s, napíše chybu "Aw, Snap! [...] Error code: 5", chybový kód se nemění. Cca. 3 min, naalokuje 3 GB, učiní systém těžko použitelným (vylije jej do swapu), napíše chybu "Aw, Snap! [...] Error code: 5" a paměť 3 GB zase uvolní. 48 s, pak jsem ho musel zavřít: čte data z disku plnou rychlostí a alokuje je do paměti. Než RAM došla, Chromium jsem zavřel aby nedošlo k havárii systému.
Firefox, normální zobrazení 0,5 s 10,9 s 17,4 s 1 s a selže: "The image ... cannot be displayed because it contains errors." 1 s a selže: "The image ... cannot be displayed because it contains errors." 1 s a selže: "The image ... cannot be displayed because it contains errors."
Dillo0,6 s Nezobrazí, napíše "Huge file! (504MB)" (má být MiB) Nezobrazí, napíše "Huge file! (887MB)" (má být MiB) >32 min: čte soubor a naalokovává ho do paměti a zobrazuje počítadlo MB a překresluje okno. Až dosáhne 1023,5 MB (někdy 1007 MB), přestane číst soubor, přestane překreslovat okno a bere 100% CPU. >8 min: čte soubor a naalokovává ho do paměti a zobrazuje počítadlo MB a překresluje okno. Až dosáhne 1023,5 MB (někdy 1007 MB), přestane číst soubor, přestane překreslovat okno a bere 100% CPU. 0,5 s, pak napíše „Huge file! (1005 MB)“ a nezobrazí nic. Soubor přitom má 31 120 MB, nikoliv 1005. Je to zbytek po dělení 232, ale i to je špatně: je to 1005 MiB, nikoliv 1005 MB:
(31119549464%(2^32))/(1024^2)
1005
(31119549464%(2^32))/(1000^2)
1054
Facebook: preview URL postovaného v komentáři zda na něm není obrázek Objeví se Neobjeví se, místo obrázku je textová popiska, jejíž link vede na obrázek. Nestahují se data z Internetu na klientovi. Neobjeví se, místo obrázku je textová popiska, jejíž link vede na obrázek. Nestahují se data z Internetu na klientovi. Neobjeví se, místo obrázku je textová popiska, jejíž link vede na obrázek. Nestahují se data z Internetu na klientovi. Neobjeví se, místo obrázku je textová popiska, jejíž link vede na obrázek. Nestahují se data z Internetu na klientovi. Neobjeví se, místo obrázku je textová popiska, jejíž link vede na obrázek. Nestahují se data z Internetu na klientovi.
Facebook: preview URL postovaného na vlastní timeline zda na něm není obrázek Na klientovi se nestahují data z Internetu. Thumbnail se objeví. Jak obrázek tak textový odkaz se jménem souboru vedou přímo na JPEG. Thumbnail se objeví. Prohlížeč naalokuje 2,5 GB RAM (soubor má jen 0,5 GB!), systému dojde paměť a zadrhává se. Facebookový post se podaří, ale obrázek je překompresovaný ze 133 kB na 80 kB a neobsahuje vložená data. Na klientovi se nestahují data z Internetu. Thumbnail se neobjeví a to ani po postování. Na facebookové wall je prázdný rámeček a textový odkaz se jménem serveru, obojí vede přímo na JPEG. Na klientovi se nestahují data z Internetu. Thumbnail se neobjeví a to ani po postování. Na facebookové wall je prázdný rámeček a textový odkaz se jménem serveru, obojí vede přímo na JPEG. Na klientovi se nestahují data z Internetu. Thumbnail se neobjeví a to ani po postování. Na facebookové wall je prázdný rámeček a textový odkaz se jménem serveru, obojí vede přímo na JPEG. Na klientovi se nestahují data z Internetu. Thumbnail se neobjeví a to ani po postování. Na facebookové wall je prázdný rámeček a textový odkaz se jménem serveru, obojí vede přímo na JPEG.
Messenger: preview URL postovaného v konverzaci, zda na něm není obrázek Preview se zobrazí. Preview se nezobrazí, pouze jméno serveru a link, který vede přes Facebookové URL. Na klientovi se data nestahují. Preview se nezobrazí, pouze jméno serveru a link, který vede přes Facebookové URL. Na klientovi se data nestahují. Preview se nezobrazí, pouze jméno serveru a link, který vede přes Facebookové URL. Na klientovi se data nestahují. Preview se nezobrazí, pouze jméno serveru a link, který vede přes Facebookové URL. Na klientovi se data nestahují. Preview se nezobrazí, pouze jméno serveru a link, který vede přes Facebookové URL. Na klientovi se data nestahují.
Telegram: preview URL postovaného v konverzaci, zda na něm není obrázek Preview se zobrazí. Data se na klientu nestahují. Preview se nezobrazí, pouze „Getting Link info...“, data se na klientu nestahují. Po několika sekundách ze zobrazí pouze URL a přímý link. Preview se nezobrazí, pouze „Getting Link info...“, data se na klientu nestahují. Po několika sekundách ze zobrazí pouze URL a přímý link. Preview se nezobrazí, pouze „Getting Link info...“, data se na klientu nestahují. Po několika sekundách ze zobrazí pouze URL a přímý link. Preview se nezobrazí, pouze „Getting Link info...“, data se na klientu nestahují. Po několika sekundách ze zobrazí pouze URL a přímý link. Preview se nezobrazí, pouze „Getting Link info...“, data se na klientu nestahují. Po několika sekundách ze zobrazí pouze URL a přímý link.
iPhone: Obrazová galerie - zobrazení 0 s 0-3 s reakce na kliknutí. Zobrazuje šedé pole místo obrázku, obrazová galerie často spadne za 6 s Zobrazuje šedé pole místo obrázku. Předstírá, že tam obrázek není, když tam ve skutečnosti je. Předstírá, že tam obrázek není, když tam ve skutečnosti je. Nelze provést - na telefonu není dost místa.
ⓘ v obrazové galerii na iPhone 0,5 s. 0,5 s. 0 × 0 (špatně) 0,5 s. 0 × 0 (špatně) Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak ⓘ ani nelze zmáčknout. Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak ⓘ ani nelze zmáčknout. Nelze provést - na telefonu není dost místa.
Edit v obrazové galerii na iPhone 0,2 s Koláčový progress indikátor "Loading". Po 8-17 s někdy galerie spadne, jindy se po 3 s objeví chybová hláška "Cannot Load Photo: There was an error loading this photo." 2,5 s, potom chyba "Cannot Load Photo: There was an error loading this photo" Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak Edit ani nelze zmáčknout. Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak Edit ani nelze zmáčknout. Nelze provést - na telefonu není dost místa.
Otevření menu [↑] Share v obrazové galerii na iPhone 0,3 s 0-7s na reakci na kliknutí, galerie často po několika sekundách spadne, zejména hýbali-li jsme s menu nebo klikali na obrázek. 0 s Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak menu [↑] Share ani nelze otevřít Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak menu [↑] Share ani nelze otevřít Nelze provést - na telefonu není dost místa.
Smazání v obrazové galerii iPhonu 0,7 s 0 s 0 s Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak jej nelze smazat. Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak jej nelze smazat. Nelze provést - na telefonu není dost místa.
iPhone galerie: Smazání z galerie smazaných fotek 0,9 s 0 s, ale při smazání 3 kopií galerie za pár sekund spadla, nicméně smazání se provedlo. Galerie ale někdy padá po vstoupení do prázdného adresáře smazaných fotek. 0 s Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak jej nelze do galerie smazaných fotek ani dostat Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak jej nelze do galerie smazaných fotek ani dostat Nelze provést - na telefonu není dost místa.
iPhone galerie: Recover z galerie smazaných fotek 0,8 s 1 s 0 s Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak jej nelze do galerie smazaných fotek ani dostat Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak jej nelze do galerie smazaných fotek ani dostat Nelze provést - na telefonu není dost místa.
[↑] Share, Duplicate v obrazové galerii na iPhone 1 s Objeví se koláčový progress indikátor. Někdy galerie za 9 s spadne a duplikát se objeví. Jindy duplikace uspěje během 7 s. 8 s Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Duplicate nelze provést Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Duplicate nelze provést Nelze provést - na telefonu není dost místa.
[↑] Share, Save to Files v obrazové galerii na iPhone 0 s "Preparing", koláčový progress meter postupuje od 0% do 1%, pak se zasekne. Někdy galerie za 6 s spadne. Jindy za 28 s hodí chybu "Unable to Share: There was an error while preparing to share. Please try again later.". Vzácně se za 21 s objeví dialog zvolení cílového adresáře ve Files. Po potvrzení je uložení okamžité a úspěšné. "Preparing", koláčový progress meter postupuje od 0% do 1%, pak se zasekne. 38 s od startu operace chyba "Unable to Share: There was an error while preparing to share. Please try again later." Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Save to Files nelze provést Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Save to Files nelze provést Nelze provést - na telefonu není dost místa.
Obrazová galerie iPhone [↑] Share, Copy to Documents (by Readdle) 0 s Někdy 26 s úspěch, častěji 16-26 s pád galerie. V obou případech "Preparing", koláčový progress meter postupuje od 0% do 1%, pak se zasekne. Nakonec se soubor uloží nebo galerie spadne aniž by se objevil cílový soubor. Někdy se iPhone rebootuje delším rebootem s logem Applu. "Preparing", koláčový progress meter postupuje od 0% do 1%, pak se zasekne. 38 s od startu operace chyba "Unable to Share: There was an error while preparing to share. Please try again later." Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Copy to Documents nelze provést Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Copy to Documents nelze provést Nelze provést - na telefonu není dost místa.
Obrazová galerie iPhone [↑] Share, Airdroid 1,2 s 12-18 s úspěch. Z Airdroidu složky Files ho lze stáhnout webovým prohlížečem na PC. "Preparing", koláčový progress meter postupuje od 0% do 1%, pak se zasekne. Po 36 s po startu chyba "Unable to Share: There was an error while preparing to share. Please try again later." Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Airdroid nelze provést Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, Airdroid nelze provést Nelze provést - na telefonu není dost místa.
[↑] Share z obrazové galerie do "View Exif Lite" na iPhone 0,6 s Někdy galerie spadne okamžitě. Jindy se objeví progress indikátor koláčový diagram, který dopostupuje od 0% do 1% a tam se zastaví. Po 9-18 s zase zmizí a Exif Lite se nespustí, galerie se navrátí do otevřeného [↑] Share menu. "Preparing", koláčový progress meter postupuje od 0% do 1%, pak se zasekne. Po 25 s po startu chyba "Unable to Share: There was an error while preparing to share. Please try again later." Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, View Exif Lite nelze provést Galerie předstírá, že tam obrázek není, když tam ve skutečnosti je, a tak [↑] Share, View Exif Lite nelze provést Nelze provést - na telefonu není dost místa.
Exif Lite na iPhone z aplikace 0,4 s zobrazuje bílou plochu místo náhledu a informace o souboru, často ale 10 s po otevření souboru spadne (zmizí z obrazovky a restartuje se) zobrazuje bílou plochu místo obrázku a 0 × 0 (špatně). Exif Lite předstírá, že tam obrázek není, když tam ve skutečnosti je (špatně) Exif Lite předstírá, že tam obrázek není, když tam ve skutečnosti je (špatně) Nelze provést - na telefonu není dost místa.
Upload přes USB kabel bez použití sítě přes Apple File Conduit (služba pro přenos souborů mezi softwarem iTunes na PC a iPhonem) přes protokol usbmux, adresář /run/user/1000/gvfs/afc:host=(dlouhé hexa číslo),port=3/com.readdle.ReaddleDocsIPad/ zobrazuje se v pcmanfm file manageru pod popiskou "Documents on (jméno telefonu)" a rádoby-adresářem afc://(dlouhé hexa číslo):3/Documents. (Adresář aplikace Documents by Readdle) 0,27 s 118 Mbps, většinou se zasekne na 20, 60, 200, 300 nebo 400 MiB a po 60 s hodí chybu "Invalid Apple File Control data received" Adresář pak trvale selže, po reloadu se obsah nezobrazí a místo toho hodí chybu "Unhandled Apple File Control error(2)". Tento chybový stav se dá vyresetovat příkazem sudo systemctl restart ,usbmuxd.service, po kterém se v adresáři zobrazí nekompletní soubor. Někdy upload uspěje. 118 Mbps, zaseklo se u 284 MiB, po 27 s error "Invalid Apple File Control data received". Tento chybový stav se dá vyresetovat příkazem sudo systemctl restart usbmuxd.service, po kterém se v adresáři zobrazí nekompletní soubor. Podruhé se upload povedl. 118 Mbps, zaseklo se u 1,4 GiB. Po 60 s error "Invalid Apple File Control data received". Adresář pak trvale selže, po reloadu se obsah nezobrazí a místo toho hodí chybu "Unhandled Apple File Control error(2)". Tento chybový stav se dá vyresetovat příkazem sudo systemctl restart usbmuxd.service, po kterém se v adresáři zobrazí nekompletní soubor. Poté se upload 2× povedl. 118 MBps, proběhlo Nelze provést - na telefonu není dost místa.
Internet Archive thumbnailer Korektně vygeneroval Korektně vygeneroval Korektně vygeneroval Korektně vygeneroval Korektně vygeneroval Korektně vygeneroval
 


Autor: Karel Kulhavý

Firefox někdy při výběru souboru na upload až po dobu 1 h 20 min nepřekresluje okna na obrazovce a nedá se zavřít. Weinschenk a Barker, bod 15: vhodné tempo pro uživatele. Pro mě by byla vhodná reakce za 50 ms. Skutečné tempo je 96 000 krát pomalejší. Dále to porušuje bod 1 (nedá se zavřít), 8 (není předvídatelné že pouhé otevření dialogu výběru soboru může prohlížeč na 1 h 20 min vyřadit z provozu), 13 (uspokojující to rozhodně není), 20 (neinformuje, zda stav UI je zatvrdlý navěky nebo ne). ls vylistování souborů trvá pouhých 5 ms.

UX DAy - tip 2

Příkazovou řádku někdy používám nikoliv ze staromilství, ale protože je až 960 000 × rychlejší než grafické rozhraní. Tento DoS (Denial of Service) se může opakovat pokaždé, když otevřeme dialog na výběr souboru, i nesouvisejícího na nesouvisející website, pokud posledně uploadovaný adresář obsahuje velký JPEG na prvním místě.

RCam a Files

Program Doba načítání JPEGu o výsledné velikosti
3,8 MB 529 MB 931 MB 2,5 GB 4,0 GB 31 GB
Upload přes USB kabel bez použití sítě přes Apple File Conduit (služba pro přenos souborů mezi softwarem iTunes na PC a iPhonem) přes protokol usbmux, adresář /run/user/1000/gvfs/afc:host=(dlouhé hexa číslo),port=3 zobrazuje se v pcmanfm file manageru pod popiskou "RCam on (jméno telefonu)" a rádoby-adresářem afc://(dlouhé hexa číslo):3/RCam/Library. (/run/user/1000/gvfs/afc:host=(dlouhé hexa číslo),port=3/com.mm.RCam/Library) 0,27 s 120 Mbps. 126 Mbps netto. 126 Mbps netto. 117 Mbps netto. Nelze provést - na telefonu není dost místa.
Nahlédnutí obrázku v RCam 0,5 s 2 s a místo obrázku černé pozadí 2,5 s a místo obrázku černé pozadí 0,5 s a místo obrázku černé pozadí 0,5 s a místo obrázku černé pozadí Nelze provést - na telefonu není dost místa.
Info v RCam Pouze "JPEG" Pouze "JPEG" Pouze "JPEG" Pouze "JPEG" Pouze "JPEG" Nelze provést - na telefonu není dost místa.
Z RCam do fotogalerie: [↑] Save Image 0,9 s 0 s. Tváří se, jako by to něco udělalo, ale nic se nestane. 0 s. Tváří se, jako by to něco udělalo, ale nic se nestane. 0 s. Tváří se, jako by to něco udělalo, ale nic se nestane. 0 s. Tváří se, jako by to něco udělalo, ale nic se nestane. Nelze provést - na telefonu není dost místa.
Z RCam do fotogalerie: šipka do kytičky 0,2 s, "Failed to save", v galerii se obrázek objeví editovaný - s přidaným logem, tedy ztrátově překompresovaný a embeddovaná data jsou pryč. 0,2 s, "Failed to save", v galerii se nic neobjeví 1,2 s, "Failed to save", v galerii se nic neobjeví 0,2 s, "Failed to save", v galerii se nic neobjeví 0,2 s, "Failed to save", v galerii se nic neobjeví Nelze provést - na telefonu není dost místa.
V RCam editace (štěteček) 0,2 s 2 s, pak RCam spadne. 1,2 s, pak RCam spadne. 0,2 s, pak RCam spadne. 0,2 s, pak RCam spadne. Nelze provést - na telefonu není dost místa.
V RCam [↑] View Exif Lite 0,6 s Objeví se throbber a malá ikonka Exif Lite. Po 1 s se vrátí do menu, aniž by se Exif Lite spustil. Objeví se throbber a malá ikonka Exif Lite. Po 1 s se vrátí do menu, aniž by se Exif Lite spustil. Po dalších pokusech je navrácení již za 0,5 s. 1 s, ale obrázek se nesprávně zobrazí jako plný bílý obdélník a „0 × 0 (Zero KB)“ 0,5 s, ale obrázek se nesprávně zobrazí jako plný bílý obdélník a „0 × 0 (Zero KB)“ Nelze provést - na telefonu není dost místa.
V RCam [↑] Save to Files 0,2 s 0 s 0 s 0 s 0 s Nelze provést - na telefonu není dost místa.
V RCam [↑] Copy to Documents (by Readdle) 0,2 s 0 s 0,7 s 0 s 0 s Nelze provést - na telefonu není dost místa.
V RCam smazání 0,5 s 1 s 1 s 1 s 1 s Nelze provést - na telefonu není dost místa.
iPhone do Safari z PC přes HTTP z Busybox httpd serveru (podporuje několik spojení současně - testováno) a síť přes USB kabel (ipheth). Soubor se ukládá do aplikace Files iPhonu. 0,5 s Porušení dat při mnohonásobně přerušeném a pokračovaném stahování přes HTTPS+WiFi z Internet Archive z důvodu špatného připojení. 1/7 souboru se lišila, ověřeno vykopírováním z iPhonu na 3 různé způsoby vč. zazipování přímo v Safari v Downloads adresáři. Přes HTTP nepřerušovaně z PC se soubor stáhl správně. Downloaduje 136 Mbps brutto, na 105 (125, 104, 167) MB se download bezdůvodně samovolné ukončí aniž by spadl ipheth (dmesg) a iPhone se dá stále pingnout. Resume downloadu pak začíná vždy od 0 místo 105 (125, 104, 167) MB. Data v 1. případě poškozena nebyla, později jsem to netestoval. Jednou se provedl download bez toho, aby se sám od sebe přerušil. Downloaduje 136 Mbps brutto, na 123 (94, 194, 64, 62) MB se download bezdůvodně samovolné ukončí aniž by spadl ipheth (monitorováno v dmesg) a iPhone se dá stále pingnout. HTML stránka se přitom v pozadí downloadu reloaduje. Resume downloadu pak začíná vždy od 0 místo 123 (94, 194, 64, 62) MB. Jednou: "A problem repeatedly occured on "http://172.20.10.11:8080"", ač ipheth nemá problém, iPhone pingá a httpd funguje. Problém se dá workaroundovat tím, že do HTML napíšeme do <a> tagu slovo download a na link klikáme normálně (nikoliv jako na stažení). Pak se download samovolně nepřerušuje. 2×: žádná reakce po kliknutí na link a nahoře probleskla nějaká hláška "This webpage..." a stránka se refreshovala. Downloaduje 143 Mbps brutto Nelze provést - na telefonu není dost místa.
iPhone Files - zobrazení obrázku 0,7 s Obrázek se nezobrazí, místo něj je text jméno souboru, JPEG image, délka souboru Obrázek se nezobrazí, místo něj je text jméno souboru, JPEG image, délka souboru Obrázek se nezobrazí, místo něj je text jméno souboru, JPEG image, délka souboru Obrázek se nezobrazí, místo něj je text jméno souboru, JPEG image, 3,99 GB Nelze provést - na telefonu není dost místa.
iPhone Files [↑] View Exif Lite 0,4 s Objeví se throbber a malá ikonka Exif Lite. Po 1 s se vrátí do menu, aniž by se Exif Lite spustil. Objeví se throbber a malá ikonka Exif Lite. Po 1 s se vrátí do menu, aniž by se Exif Lite spustil. 0 × 0 (špatně), Zero KB (špatně) 0,5 s, místo obrázku bílá plocha, 0 × 0 (špatně), Zero KB (špatně) Nelze provést - na telefonu není dost místa.
iPhone Files [↑] Save Image 0,9 s 0 s, operace se neprovede. Files se tváří, jako by se operace provedla. 0 s, operace se neprovede. Files se tváří, jako by se operace provedla. 0 s, operace se neprovede. Files se tváří, jako by se operace provedla. 0 s, operace se neprovede. Files se tváří, jako by se operace provedla. Nelze provést - na telefonu není dost místa.
iPhone Files [↑] Copy to Documents (by Readdle) 0,3 s 0 s úspěch. Po chvíli se ale iPhone sám od sebe krátce rebootuje. 0 s 0 s 0 s Nelze provést - na telefonu není dost místa.

Příště dotestujeme Aidroid a Documents a popíšeme optimalizaci Jpeginsertu na rychlost.

Byl pro vás článek přínosný?

Autor článku

Karel Kulhavý vystudoval operační systémy, sítě a překladače na MFF UK a je autorem optického pojítka Twibright Ronja a spoluautorem textového a grafického webového prohlížeče Twibright Links.