Manglende grafikvisning

[busstoptaktik]

Jeg prøver at vise skitsen til G.M.902. Kommandoen

fire grafik vis K-63-09946.png

åbner "windows photos" som meddeler at tmp_xxxxxx.png: we can't open this file.

[kbevers]

Jeg kan bekræfte fejlen. Jeg mistænker at filen der er lagret i databasen er i stykker.

Mon ikke du kan bruge en anden skitse til kurset? Fx fra BUDP:

fire grafik vis --db prod 1-13-00829.png

der i hvert fald ser ud til at virke fint her

[kbevers]

Næh... der er umiddelbart ikke noget galt med indholdet af databasen. Har lige hevet denne ud med DBeaver:

Jeg ved ikke lige hvad problemet er

[busstoptaktik]

Pudsigt. Jeg kan bekræfte at din workaround med at anvende et andet punkt virker. Men sidst jeg prøvede (for flere(?) måneder siden) var der flere punkter i træk der ikke leverede noget. Jeg har ikke prøvet andet end gm902 og BUDP i dag

[kbevers]

Der er jo nok et rigtigt problem gemt her et sted men jeg bare ikke hvad jeg skal lede efter

[busstoptaktik]

Vi kan jo bede FIRE-kursusdeltagerne om så vidt muligt også at hive skitsen ud, når de alligevel checker et punkt - og så rapportere her, hvis de støder på et der ikke virker.

Jeg overvejer også om vi måske skal have en (tilvalg) webbrowser.open(...) version af punktvisning: Det ville potentielt give et bedre overblik, og mulighed for at integrere skitsen i visningen - men det vil kræve en hel del formatteringskode (eller måske bare indlejring i <pre></pre> af det vi allerede viser på konsollen)

[krebslw]

Er kommet til at fixe den her i mit gode fredagshumør. Det har umiddelbart noget med skrivningen af den temporære fil i fire grafik vis at gøre:

ext = grafik.filnavn[-4:]
with tempfile.NamedTemporaryFile("wb", suffix=ext) as tmp:
        tmp.write(grafik.grafik)
        webbrowser.open_new_tab(f"file://{tmp.name}")
        # giv browseren tid til at starte inden filen fjernes igen
        time.sleep(5)

hvor filen sommetider ikke bliver skrevet til disken (se bonusinfo nederst), men beholdt i bufferen, hvilket af årsager jeg ikke helt forstår gør så andre processer, som fx webbrowser.open_new_tab( ... ) ikke kan åbne filen. (se også https://stackoverflow.com/questions/46004774/python-namedtemporaryfile-appears-empty-even-after-data-is-written). Man kan tvinge den temporære fil til at blive skrevet til disken på to måder:
Slå buffering fra:

...
with tempfile.NamedTemporaryFile(
    "wb",
    suffix=ext,
    buffering = 0, # buffer slås fra
) as tmp:
...

eller flushe filen til disk:

...
tmp.write(grafik.grafik)
tmp.flush()
...

Begge metoder løser problemet for alle de filer jeg har prøvet at åbne.

Har desuden lagt mærke til at nogle billeder bliver enormt grynede når man åbner dem med fire grafik vis, men når de gemmes og genåbnes bliver de vist fint. Prøv fx med G.M.363.jpg og 40-11-00004.png som bliver grynede og G.M.451.jpg som vises fint. Jeg er ikke ekspert i billed-formater og -viewers, men kan konstatere at billederne bliver vist fint når man gemmer dem og åbner dem på ny..
Programmatisk kan det gøres ved at man slår automatisk sletning af de temporære filer fra, lukker filen, og så selv sletter dem bagefter. (se https://stackoverflow.com/questions/15169101/how-to-create-a-temporary-file-that-can-be-read-by-a-subprocess og https://bugs.python.org/issue14243 ) Dette virker dog lidt kluntet, hvilket de også påpeger i ovenstående, men det virker dog:

with tempfile.NamedTemporaryFile(
    "wb",
    suffix=ext,
    delete = False, # lad være med at slette den midlertidige fil, når den lukkes
) as tmp:
    tmp.write(grafik.grafik)
# hop ud af context-manageren, så tmp-filen bliver lukket men ikke slettet
webbrowser.open_new_tab(f"file://{tmp.name}")

# giv browseren tid til at starte inden filen fjernes igen
time.sleep(5)

# slet filen igen
Path.unlink(tmp.name)

I python 3.12 (vi bruger python 3.11) implementeres et nyt flag delete_on_close som løser dette (se python/cpython#97015) . Med flaget kan man gøre så filen ikke slettes når man lukker den, men først når man forlader context-manageren. Dette er den pæneste løsning IMO og løser både problemet med filer der slet ikke kan åbnes og filer som bliver grynet når man åbner dem. Men det kræver som sagt en opgradering til python 3.12:

with tempfile.NamedTemporaryFile("wb", suffix=ext, delete_on_close=False) as tmp:
        tmp.write(grafik.grafik)
        tmp.close()
        webbrowser.open_new_tab(f"file://{tmp.name}")
        # giv browseren tid til at starte inden filen fjernes igen
        time.sleep(5)

Bonusinfo:

Fandt igennem flere tests ud af en sammenhæng mellem filens størrelse og hvorvidt denne fejl opstår. Små filer kan ikke åbnes, mens store filer godt kan åbnes (jeg ræsonnerer uden belæg, at små filer godt kan beholdes i bufferen, mens de større filer bliver skrevet til disk). Skellet går så vidt jeg kan se på min PC (måske er det afhængigt af hvilken maskine man kører det på?) ved filstørrelse på 8192 (2^13) bytes. (Man kan få størrelsen af en BLOB i oracle med funktionen dbms_lob.getlength :

SELECT dbms_lob.getlength(g.grafik), g.*
FROM GRAFIK g
WHERE filnavn IN ('44-20-00806.png', '81-02-00824.png')

Prøv selv med filen 44-20-00806.png på 8192 bytes som ikke burde virke og 81-02-00824.png på 8193 bytes som gerne skulle virke. Har endnu ikke stødt på tilfælde som modsiger den tese.

[kbevers]

Dette er den pæneste løsning IMO og løser både problemet med filer der slet ikke kan åbnes og filer som bliver grynet når man åbner dem. Men det kræver som sagt en opgradering til python 3.12:

Lyder som en oplagt anledning til at bumpe Python versionen til 3.12 :-)

Derudover, glimrende analyse af problemet. Tak for den!