Hlavní navigace

Názor ke článku Fenomén "... ja som nič nerobil..." od Hgr - [18] Inu, přemýšlel, ale tady na primitivním, chudém...

  • 14. 7. 2009 15:01

    Hgr (neregistrovaný) 85.70.62.---

    [18] Inu, přemýšlel, ale tady na primitivním, chudém a divokém severu o něco takového asi hned tak nezakopnu. :-)

    [23] Já nevím, jestli něco dělám nenormálně, nebo jestli prostě mám "smůlu". Uvedu příklad. Potřeboval jsem cosi provést s pár stovkami obrázků, a řekl jsem si, že si zkusím knihovnu IM, co se dá používat z Lua a co vypadala, že je docela malá, rychlá a šikovná. Potřeboval jsem vyříznout z každého obrázku dva výřezy (v zásadě šlo o rozdělení gray JPEG skenů dvojlistů na stránky a nějaké to zpracování - zjistit histogram, utnout kontrast, uložit do TIFF G4 - asi poměrně stupidní, ale to PDFko pak vypadá líp :-))

    Inu, jak udělám výřez z obrázku? Nu asi potřebuju funkci im.ProcessCropNew, která vezme starý obrázek, souřadnice xmin, xmax, ymin a ymax a vrátí výřez. A jéje, proč to vrací obrázky s tak divnou velikostí? To jsem přeci nechtěl. Po hodině a půl hledání chyby ve vlastním kódu a v dokumentaci ("takovou blbost by přeci nikdo neudělal, a přeci nejsem první, kdo něco takového zkouší?") mě napadne podívat se do funkce im.ProcessCropNew a zjišťuji, že nový obrázek (jako datová struktura) pro výřez se alokuje s rozměry (xmax - xmin) x (xmax - ymin).

    WTF? To jsem fakt první, kdo to používá? Ono se ukázalo, že im.ProcessCropNew je psaná v "pure Lua" - API téhle jinak moc pěkné knihovny se mírně liší v C a v Lua (v C API knihovny IM člověk musí dělat explicitní alokace cílových obrázků a všechny processing funkce přijímají argument "již alokovaný cílový obrázek") a možná jsem skutečně první, kdo v IM ořezává obrázek z Lua, ale vždyť číslo verze je 3.4.1...?

    No, mohl bych jim už konečně poslat ten patch. A zaptat se jich ještě, jestli *opravdu* chtějí, aby crop nedovoloval ořezávání pouze v jedné dimenzi (jestli si dobře pamatuju, protestovalo to, že cílový obrázek musí být menší v obou rozměrech, takže rozdělit něco pouze svisle na dvě půlky není tak jednoduché).

    No a dnes jsem třeba našel cosi shnilého v deserializaci regexpů v Ruby 1.9.1:

    hgr@lamarck:~$ cat testcase.rb
    #!/usr/bin/env ruby
    # coding: utf-8
    s = "kukačka"
    r1 = Regexp.compile s
    r2 = Marshal.load(Mar­shal.dump r1)
    p r1, r2
    p r1.encoding, r2.encoding
    p r1 == r2
    p r1.match s
    p r2.match s
    hagaer@laplace:~$ ruby testcase.rb
    /kukačka/
    /kukačka/
    #<Encoding:UTF-8>
    #<Encoding:UTF-8>
    true
    #<MatchData "kukačka">
    testcase.rb:10:in `match': incompatible encoding regexp match (ASCII-8BIT regexp with UTF-8 string) (Encoding::Com­patibilityError)
    from testcase.rb:10:in `<main>'
    hgr@lamarck:~$

    Opět jsem asi první, kdo se pokouší používat deserializovaný regulární výraz v UTF-8. :-) Vždyť ten r2 o kus výše tvrdí, že je v UTF-8? Ale na tohle se budu muset zanořit hlouběji, abych tu chybku našel.