a gwenview nem a beágyazott jpg-t mutatja, hanem renderel :-(

Multimédia

Sziasztok!

A laptopomon nagyon régóta Fedora Linux van, a 36-ig úgy működött a gwenview, hogy ha egy NEF (RAW) képet néztem meg, akkor a beágyazott JPG képet mutatta.

Ám a 37-es óta megváltozott a működése, ha NEF képet akarok megnézni, pár másodpercig pörög a fogaskerék, pörög a CPU, majd a betöltött kép szemmel láthatóan pocsék minőségű, sokkal rosszabb, mint a gép által csinált JPG kép. Átnéztem a beállításait, még hasonló opciót sem találtam. A Fedora 38-ra lépéssel sem javult a helyzet.

Megnéztem egy szűz felhasználóval, ugyanígy viselkedik. Megnéztem a Cinnamon default képnézegetőjével, az még rosszabb, a NEF képet 160x120 pixel méretben jeleníti meg :-)

Van erre valami megoldás, hogy ne rendereljen, csak mutassa meg a beágyazott képet?

  • 1130 megtekintés

( ulysses v | 2023. 06. 23., p – 05:46 )

Azt írja az internet, hogy a NEF képek tartalmaznak egy beágyazott thumbnail TIFF-et is, és egy file bug miatt ezt ismeri fel MIME-típusként a Gwenview és társai. Elvileg javították is ezzel a committal. Mi a Gwenview verziója nálad?

persze, gondolom a gwenview függősége:

 

# dnf info kf5-libkdcraw
Az utolsó metaadat lejárati ellenőrzés ennyi ideje volt: 1:00:10, ekkor: 2023. jún. 23., péntek, 10:38:57 CEST.
Telepített csomagok
Név          : kf5-libkdcraw
Verzió       : 23.04.2
Kiadás       : 1.fc38
Architektúra : x86_64
Méret        : 116 k
Forrás       : kf5-libkdcraw-23.04.2-1.fc38.src.rpm
Tároló       : @System
Ezen tárolób : updates
Összegzés    : A C++ interface around LibRaw library
URL          : https://invent.kde.org/graphics/libkdcraw
Licenc       : GPLv2+ and LGPLv2 and GPLv3+
Leírás       : Libkdcraw is a C++ interface around LibRaw library used to decode RAW
             : picture files. More information about LibRaw can be found at
             : http://www.libraw.org.

Elérhető csomagok
Név          : kf5-libkdcraw
Verzió       : 23.04.2
Kiadás       : 1.fc38
Architektúra : i686
Méret        : 52 k
Forrás       : kf5-libkdcraw-23.04.2-1.fc38.src.rpm
Tároló       : updates
Összegzés    : A C++ interface around LibRaw library
URL          : https://invent.kde.org/graphics/libkdcraw
Licenc       : GPLv2+ and LGPLv2 and GPLv3+
Leírás       : Libkdcraw is a C++ interface around LibRaw library used to decode RAW
             : picture files. More information about LibRaw can be found at
             : http://www.libraw.org.

Ahogy utánaolvasok, ez nem is igazából Gwenview bug. Megvan számos képnézőben, és még csak azoknak sem a bugja. A net az írja, hogy a mime-adatbázis nem jó, azért azonosítja rosszul a file parancs is. Azt viszont nem tudom, hogy ezt az adatbázist hogyan kéne rendbetenni, mert onnantól kezdve az összes program, ami egyébként támogatja ezt a formátumot, jól jelenítené meg.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Raynes v | 2023. 06. 24., szo – 22:27 )

A megoldás engem is érdekelne, mert letöltve egy .nef raw sample képet, nálam sem jó, egy 212 pixeles előnézeti képet jelenít meg itt is. Pedig nem is Fedora + KDE + Gwenview-t használok, hanem Arch + bspwm + sxiv kombót (imv-vel is próbáltam, azzal is épp ilyen előnézeti képként jelenik csak meg). Szerintem a NEF kezeléssel lesz a baj, mert a többi RAW fotóformátum jónak tűnik, cr2, cr3, crw, sr2, srw jól jelennek meg, csak ez a .nef nem stimmel. Eddig még ezzel nem próbáltam, nem akadtam össze olyan képpel, ami ebben a formátumban lett volna.

Megnéztem dcraw-val is terminálban, hogy az azzal kikódolt nyers képet nyitom meg (vagy .tiff, vagy .ppm formátumban, akár fájlként, akár csak stdout-re írva, akkor jó, a dcraw megfelelően kódolja ki CLI-ben. A libraw fent van nálam is, a libkdcraw nem kell, mert nem használok KDE-t, Gwenview-t vagy Qt-t.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

De pont ez a baj, hogy nem a GUI a hibás, hanem már a CLI file utility is félreazonosítja a .nef mimetype-ját, így tty-os framebuffer-ben sem működne. Ezen a RPi sem fog segíteni. Ezen kívül a X és a Wayland is tud több monitort kezelni (úgyis csak 1 kijelzőt használok), meg a többi raw és nem raw képformátum jól jelenik meg, szóval nem a rendszerrel van a baj, csak ezzel az egy fájltípussal.

Az a baj, hogy a mime-hez olyan mélységében nem értek, hogy az adatbázisát meg tudjam javítani. Mert azzal egy csapással minden programban jól nyílna meg.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( msandor v | 2023. 06. 25., v – 10:42 )

Mutatok egy képet, amit még tavaly lőttem korán reggel a Nikon Z50-es vázammal. Ez a JPG változat, ez pedig a NEF. Mindkettő érintetlen.

Az én gwenview-m a NEF képből ezt mutatja (legalább teljes méretben, részletek nélkül).

Talán ezzel kellett volna kezdenem, így jobban érthető a problémám.

Telepítettem egy Fedora 38-at VirtualBoxban, hogy ugyanazt a környezetet lássam, mint te. Amikor Firefoxban letöltöttem a NEF-et, akkor TIFF-ként (MSA_2009.tiff) mentette el! Ezután Konsole-ban a file és a kmimetypefinder5 is azt mondta rá, hogy ez bizony egy image/tiff. De ha átneveztem MSA_2009.NEF-re, a kmimetypefinder5 már image/x-nikon-nef-et azonosított, és a Gwenview is az 5600x3728 felbontású teljes képet jelenítette meg.

Neked mit mond a NEF képekre a file illetve a kmimetypefinder5?

Köszönöm, hogy próbálsz segíteni!

$ file MSA_2009.*
MSA_2009.JPG: JPEG image data, Exif standard: [TIFF image data, little-endian, direntries=13, manufacturer=NIKON CORPORATION, model=NIKON Z 50, orientation=upper-left, xresolution=204, yres
olution=212, resolutionunit=2, software=Ver.02.20, datetime=2022:02:24 07:00:33], baseline, precision 8, 5568x3712, components 3
MSA_2009.NEF: TIFF image data, little-endian, direntries=28, height=120, bps=352, compression=none, PhotometricInterpretation=RGB, manufacturer=NIKON CORPORATION, model=NIKON Z 50, orientat
ion=upper-left, width=160

Nem ismerem a kmimetypefinder5-t, nekem nincs ilyenem.

Nálam is teljes méretben jeleníti meg a nef képeket, de valami nagyon gagyi algoritkussal renderelve, mert elmossa a részleteket, erről mutattam a png képet (kivágtam a holdat, az égbolt kékségében nem volt mit nézni).

Amúgy nem lehet, hogy a NEF file valójában egy TIFF? Hasonlóképpen, mint ahogy a DNG raw formátum is a motorháztető alatt valójában egy szabványos TIFF, csak hozzá van csapva egy csomó metadata tag. Ha az extra header-öket nem értő alkalmazás próbálja megnyitni, akkor sikerülni fog, de egy sötétszürke zagyva mocskot fog megjeleníteni.

Most nem kezdtem el felhajtani a NEF specifikációját, lehet, hogy tévedek. De az, hogy ugyanazt a file-t néha image/tiff-nek, néha image/x-nikon-nef nek azonositja, nekem legalabbis azt mondja, hogy igazából megkülönböztethetetlen a két formátum neki (legalabbis addig a pár header erejéig, ameddig belenéz), és kell a filevégződés, mint hint.

Régóta vágyok én, az androidok mezonkincsére már!

A NEF fájl gykorlatilag RAW fájl, csak "Nikonos". Nyers adatokat tartalmaz, a gyors megjelenítés miatt beágyaztak egy gyengébb minőségű (de teljes méretű) JPG fájlt. Nálam most ezt nem olvassa ki (gyorsan), hanem renderel egy fos képet (lassan).

Expozíciókor lementi a váz a nef képet, majd a beállításai alapján konvertál belőle egy jpg képet. Egy kép, kép fájl, kétféle képformátum. Egyik sem tiff.

Ugye a DNG is RAW, de mégis TIFF :) Voltak vendorok, akik nem nulláról kezdték a kereket feltalálni, hanem vettek egy meglevő formátumot és azt szabták át raw tárolásra.

A dcraw forrását elnézve kifejezetten gyakori választás volt a tiff. De mondjuk pont a NEF nem tűnik annak (packed_load_raw-t használja 8706.sorban, nem hív parse_tiff-et). Bár a franc tudja, vannak olyan részek ahol tiff header-öket parse-ol, és ott is előfordul if(!strncmp(make,"NIKON",5)). Persze komplikálja a helyzetet, hogy lehet NEF-ből konvertált DNG is, amikor ténylegesen Nikon kamerából származó raw file ténylegesen TIFF file-ba van átrakva. Amennyire ebből a spagettikódból bármit is meg lehet állapítani... borzalmas átláthatatlan az egész, globális változókon keresztül passzolgat paramétereket a függvények között, egyes változóknak megtévesztő a neve (pl tiff_bps adja meg a bitmélységet, függetlenül attól, hogy tiff formátumról van-e szó), az összes lehetséges formátum beazonosítása egyetlen végtelen hömpölygő if-else folyamban történik. Hát ezt a kódot sem tartanám szívesen karban...

És hosszas keresgélés után is úgy tűnik, hogy dcraw forrása az egyetlen publikus információforrás, amiből legalább valami kiderül a NEF file-ok szerkezetéről.

EDIT: azt a linket én is megtaláltam valami 1000 éves fórumposztban, amit Fisher megtalált, de nekem halottnak tűnik: http://lclevy.free.fr/nef/

Régóta vágyok én, az androidok mezonkincsére már!

> Egyik sem tiff.

miert nem? a TIFF ugyanugy egy altalanos container formatum mint az AVI / MOV (videokhoz) vagy a WAV (hanghoz), csak ez kepekhez valo. a headerben benne van hogy milyen a konkret file codecet hasznal, es azzal lehet a benne levo adatokat ertelmezni. ez lehet uncompressed vagy rle-compressed pixelek (ezt szokas .tif kiterjesztessel hasznalni) de lehet barmi egyeb tomorites/pixelformatum (pl. nikon raw) is...

Amúgy a képet elnézve szerintem jól azonosítja a típusát. Ha a raw file-t nyers pixeladatokként jelenítené meg, akkor egy szürke, szúnyoghálómintás (ez a bayer filter, csak kb ránézésre arra emlékeztet) valamit kéne látnod. Az, hogy egy jellegre helyes színes képed van az azt jelenti, hogy helyesen tudja demosaic-olni, tudja, hogy raw képpel van dolga, helyesen tudja a subpixelek szín-elrendezését, a pixelek bitmélységét, a kép felbontását stb. Az egyetlen dolog, amit nem stimmel rajta, hogy erősen túlexponált -> nem találja el (vagy legalábbis alapértelmezetten rossz guess-t használ), hogy a 12-14 bites lineáris színmélységet hogy képezze le 8 bitre.

Ez talán segít valamit debuggolásban.

Régóta vágyok én, az androidok mezonkincsére már!

Annyit elmond, hogy itt több kvázi-független probléma van.

Az első, hogy nem a beágyazott jpeg preview-t használja, hanem nekiáll feldolgozni a raw file-t.

A második, hogy ha már feldolgozza a raw-t, akkor rossz paraméterekkel teszi. Ennek tippre a dcraw default viselkedése az oka:

I shot a raw photo with no light. Why does it appear all noisy, when it should be solid black?
No matter how dark an image is, dcraw's auto-exposure stretches it so that one percent of its pixels appear white. The "-W" option avoids this behavior.

A holdas képednél pont ezt látjuk, mivel a kép kis %-án látszik a Hold és a kép többi része egyszínű és sötétebb, ezért túlexponáltra húzta a fénygörbét.

Vagyis innentől két megoldási irány van, az egyik, hogy megnézed lehet-e valahogy paraméterezni a raw feldolgozást az alkalmazásból, hogy kicsit realisztikusabb fénygörbével próbálkozzon.

A másik, hogy megpróbálod kideríteni, hogy mitől is tört el a jpeg preview kezelése.

Én ezt úgy szoktam csinálni, hogyha kb tudom mikor tört el (azt mondod kb 3 hónapja, van egy kiindulási pontod), akkor elkezdem megnézni a package manager logjait. Kb milyen libek/csomagok frissültek abban az időszakban, amikor eltört. Ezenkívül megnézem ldd-vel az alkalmazást, hogy milyen libeket használ. És utána jön a macerás kézi játék az 1-1 csomag verziójának rollbackelésével, és próbálgatással, hogy valamelyiktől megjavul-e. Nyilván ez nem lesz mindig egyszerű, ha valamelyik csomagra explicit verziót előíró függőség van. Nekem mondjuk Arch linuxon alapvetően segít, hogy a /var/cache/pacman alatt megvannak a régi letöltött csomagok is, meg kell nézni Fedora-n, hogy a yum vagy dnf nem tartja-e meg egy ideig a régebbi csomagokat. Ha nincs, akkor sajnos repóban kell kotorászni utánuk.

Én sajnos ennél egyszerűbb megoldási módszert nem tudok. Lehet célirányosabban debuggolni az alkalmazást, forráskódban kotorászni, strace, ltrace-t elővenni, de az mindig sokkal több idő és ráfordított munka.

Régóta vágyok én, az androidok mezonkincsére már!

Igen, ez mondjuk nem könnyíti meg a történetet.

Viszont ezt találtam:

https://userbase.kde.org/Gwenview/Hidden_Configuration_Options

BlackListedExtensions

A comma-separated list of filename extensions Gwenview should not try to load. This is useful to exclude raw files which are recognized as TIFF or JPEG.

Default value: nef,cr2,new

If you change this value, be sure to keep "new" in the list. This is necessary because this extension is used by Gwenview when it saves temporary files.

Note: It seems that this option is no longer present by default. You can still create it; it should work as expected. As to default values: If you have information about that please share

Nem azt mondom, hogy "megoldja" a problémádat, de legalább annyit látni, hogy a fejlesztők is tisztában vannak vele (és valószínűleg nem tudnak mit kezdeni vele).

Régóta vágyok én, az androidok mezonkincsére már!

Bebootoltam a KDE-s Fedora 36 live-ot, letöltöttem innen a képeket, és fasza! Pont úgy viselkedik, mint ahogy régen. Ha letörlöm a gwenviewt, és felteszem a Fedora 36-oshoz készítettet, akkor meg se mutatja a NEF képet.

Viszont most más képnézegetőket is tesztelek, a shotwell frankón mutatja a nef képbe beágyazott jpg képet. Csak szoknom kell a felületét, a gwenview billentyű kombóit ismerem, ezt még nem.

( bendit | 2023. 06. 27., k – 07:18 )

Szerkesztve: 2023. 06. 27., k – 07:31

Nálam is (Debian 12 XFCE, a kf5-libkdcraw tehát nincs telepítve) a Geeqie v2.0.1 160x120 méretű képet jelenít meg addig, míg át nem nevezem a kiterjesztést .tiff-ről .nef-re. Utána viszont már az említett teljes méretet látom, mint ulysses fórumtárs. Kipróbáltam .cr2-re átnevezve, akkor is teljes méretet látom. A betöltési idő szinte ugyan annyi, mint pl. egy Nikon D7200-es nyers fájl.

Szerk.:
A Firefox .tiff kiterjesztéssel menti a letöltött képet, míg a wget .NEF fájlként, viszont a wget kimenete is ezt mondja róla:
Hossz: 24648907 (24M) [image/tiff]