Kis GIMP rant

Segédprogramok
Előre is elnézést, de ez most nagyon felhúzott. Ha valaki tud rá megoldást, szóljon! Szóval az van, hogy az nem újdonság, hogy a GIMP nem képes palettás PNG-t menteni, ezt mindig kijavítják, aztán újra elrontják. Amióta kijött a 3-as, azóta konzekvensen szar és nem működik ez a funkció (elveszíti az alfa csatornát). Szóval marad az, hogy true-color képeket exportálok. NA DE! Most már azt is elrontja! Palettaindexek hiányában a programom konkrét színkódokat néz, és azt vettem észre, hogy elkezdett nem jól működni. Fél napig debuggoltam, mire kiderült, nem is az én programomban van a hiba, hanem a GIMP-ben. Bizonyos esetekben bizonyos képeknél bizonyos pixeleket hibásan exportál (konkrétan néhány FF000000 helyett FF000100-t, FFD0D0D0 helyett pedig FFD0D0CF-et ment). Nem minden képnél, és adott képen sem minden pixelnél, csak bizonyosaknál. Bakker. Kínomban összedobtam egy xcf2png konvertálót, de hiába, a hiba akkor is jelentkezik, ha xcf-be mentek. Az egyetlen, amivel jól működik és nem szúrja el, az a Targa export, de ez akkor is rohadtul kényelmetlen, hogy minden betöltés után pixeleket kell javítgatnom a GIMP-ben az újabb exportálás előtt, mert az xcf-be is szarul kerülnek a színkódok... Szóval most az van, hogy az exportált Targát ImageMagick-el konvertálom png-évé. De ott sem fenékig tejfel minden... Eleve palettás Targát nem képes beolvasni (bár a palettás Targát jól menti a GIMP), csak true-colorral működik, és ha palettás PNG-nek akarom konvertálni "PNG8:" előtaggal, akkor az IM is elrontja a képet. Érdekes módon azonban, ha a true-color képen összesen kevesebb, mint 256 különböző szín van, akkor külön kérés és kapcsoló nélkül is palettás PNG-ként menti az IM, és ráadásul ilyenkor nem is rontja el, helyesen megmarad az egész alfa csatorna (jó PLTE és tRNS chunkok mentődnek). Ha több szín van, akkor még bejön egy pngquant lépcső is, de azzal még sosem volt bajom, eddig még mindig jól kezelte az alfa csatornás palettás képet (ha tudna Targát beolvasni, ki is maradhatna az IM lépcső). Na de visszakanyarodva a GIMP-hez: tudja valaki, hogy lehet rávenni, hogy pontosan azokat a pixeleket mentse, amiket rajzolok, és ne valami mást? Már annak is örülnék, ha az xcf-be az kerülne, amit rajzolok. Eleve önmagában már ez a kérdés is tök durván hangzik, de tényleg ez a kérdés...
  • 1043 megtekintés

( asch v | 2025. 10. 03., p – 15:11 )

Wut? Hogy lehet ezt reprodukálni? Csinálok egy új fájl, kézzel beállítom a pixelt arra amit írtál, elmentem PNG-be és szar lesz? Kipróbálom!

Pontosan! De nem minden képnél és nem minden pixelnél jön elő. Konkrétan van egy képem, amin minden FFD0D0D0-ból FFD0D0CF lett, és van egy másik, ahol csak két pixel cserélődött le, a többi nem. Úgy vettem észre, akkor jön elő nagyobb eséllyel a bug, ha a pixel környezetében majdnem ugyanolyan, de mégsem azonos más pixelek vannak (mondjuk FFB0B0B0 vagy FF909090 van körülötte). Legalábbis ez a tippem, nem tudom pontosan mi triggereli, mert kb. száz képből 2 rossz (mind ugyanannak az XCF-nek a rétegei egyébként). Először a PNG exportra gyanakodtam, de aztán kiderült, XCF-be mentésnél is elromlanak a pixelek (pontosan ugyanazok, ugyanúgy, ugyanott).
Ez nem lehet valami nagyon csúnya, billegő RAM hiba?
Akkor nem lenne konzisztens. Nem mindig ugyannál a képnél, mindig ugyanannál a pixelnél jönne elő.
Az is furcsa, hogy belementi a Projekt fáljba is, esetleg a projekt fájlt másik gépen kijavítani?
Nincs most nálam másik gép, de ez nekem is eszembe jutott, még próbálkozom ezzel.

( XMI | 2025. 10. 03., p – 15:47 )

Ez nem valami színprofil probléma lesz? Az nagyon meg tudja viccelni az embert. Volt kollégám aki felhasználói doksiírásnál futott bele, hogy lescreenshotolt valami UI-t, elmentette PNG-be, betette a doksiba, aztán a kék UI elemek lilák lettek (nem kicsit, majdnem magenta színű lett, pedig nem az a cég vagyunk). Az editorban (nem emlékszem pont GIMP volt-e) még látszólag jó volt, mindig a végleges doksiban a böngészőablakban romlott el.

Mint kiderült azon múlott, hogy éppen melyik monitoron volt az ablak, amikor a screenshotot csinálta, a képernyőkép megörökölte a monitor beállított színprofilját és vitte tovább png-ben. Aztán az editor (vagy GIMP volt, vagy nem, régen volt már) betöltéskor módosította a színeket a profilnak megfelelően, viszont benn is hagyta a profilt a png-ben. Így a végleges képen a böngészőben duplán volt alkalmazva a színprofil, ami már nagyon durván elhúzta a színeket.

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

Ez nem valami színprofil probléma lesz?
Gondoltam rá, de nem tudom hol és mit kellene állítani. Az "Image Properties" alatt csak olvasni lehet, ott azt írja: "Color space: RGB color: GIMP built-in sRGB", "Precision: 8-bit non-linear integer".
Aztán az editor (vagy GIMP volt, vagy nem, régen volt már) betöltéskor módosította a színeket a profilnak megfelelően, viszont benn is hagyta a profilt a png-ben.
Itt nem ez van, hanem az, hogy beállítom a színeket (kézzel d0d0d0 beír majd bucket fill), Picker-rel ellenőrzöm, az; rányomok a "File" > "Save"-re (vagy az "Export As" > "png név"-re) és egyből megváltoznak a színek a rétegen már szerkesztőben is (onnantól a Picker is d0d0cf-et vesz fel a képről). Szemmel nem is látható a különbség, ezért nem is vettem sokáig észre. Ja, az XCF egyébként eredetileg nem az enyém, neten találtam, de hiányos volt, ezért elkezdtem rétegeket hozzáadni, "Duplicate layer" vagy "New layer" és kijelöl + copy'n'paste-el. Aztán rárajzoltam Pencil, Bucket fill meg újabb copy'n'paste-ekkel. Alfa csatornához egyáltalán nem nyúltam, csak a színválasztót használtam manuális színkódbevitellel. Egy olyan bugba is belefutottam már, hogyha a kijelölés Eclipse, akkor mindenképp elcseszi a szélét, akkor is, ha a Hard edge be van kapcsolva (illetve 3-as óta Feather edges ki van kapcsolva), ezért ezt nem is használtam, csak a Rectangle-t, meg talán a Lasso-t egyszer-kétszer. Általában az a workflow-m, hogy [R], kijelöl, [CTRL]+[C], mellékattint (baromi fontos lépés!), [CTRL]+[V], [M], kurzornyilak vagy egér, [R], belekattint. Szopásnak hangzik? Az is, GIMP-et használni egyre inkább olyan, mint Zuzuval beszélgetni.

Szerintem ez valahogy úgy lehet, ahogy locsemege lejjebb írja: ez látszólag kerekítési hiba. És _szerintem_ valahogy oda majd vissza alkalmazza a színprofil transzformációs görbét, és ebből hozza össze az 1 bitnyi hibát a végén. 

Hogy teljesen le lehet-e tiltani nem tudom. Preferences / Color Management alatt van egy csomó beállítás. Image Display Mode nálam default "Color Managed display", esetleg "No color management"-re állítva talán jobb lesz. A "black point compensation" is default enabled és neve alapján gyanúsan hangzik. File open behavior asszem alapértelmezett "ask what to do", ennél nem biztos, hogy lehet itt jobbat választani.

Nyilván nem 100%, hogy pont ez van mögötte, de nekem ez a környék bűzlik.

Meg lehet próbálni esetleg debugolás jelleggel 16 bites képet menteni és megnézni ott mi történik a numerikus értékekkel. Illetve a Preferences / Default Image-nél "Gamma: Non-Linear" -> "Linear" is egy potenciális gyanúsított. Ha az eredeti képben már "8-bit non-linear integer" volt, akkor sajnos ezt a beállítást hozza magával.

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

( locsemege v | 2025. 10. 03., p – 16:28 )

A számokból, amit írtál, ez valami kerekítési hibának látszik. A png nem jpeg, mégis olyan, mintha ráfektetne egy intenzitás görbét majd egy resampling után a 0xd0-ból néha 0xcf, a 0x00-ból pedig 0x01 jönne ki.

Amúgy nem tudom, viszont ilyen típusú hiba okaként ezt tudom elképzelni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bzt | 2025. 10. 03., p – 18:54 )

Próbáltam képernyőmentést csinálni a dologról: https://ibb.co/1t6KSjYx Mentés előtt minden világosszürke egységesen d0d0d0. Kilépek a GIMP-ből, újraindítom és betöltöm az XCF-et, utánna a bal alsó pixel d0d0cf lesz, de a többi marad d0d0d0. Most azt hiszem sikerült megjavítanom talán: 1. jobb oldali panelen Channels fül, kikapcsoltam az Alpha-t 2. szín kijelöl, kitölt 3. Alpha Channel visszakapcsol 4. Mentés 5. Kilép, újraindít 6. Betölt Úgy tűnik, most jól tölti vissza... Ezek szerint pre-multiplied alpha vs. non-premultipled alpha lehet az ok, és a kikapcsolt kitöltés FF-el töltötte fel? Még jó, hogy hozzá se nyúltam az alfa csatornához, ezek szerint a Lasso-ba is hasonló bug került, mint ami az Eclipse kijelölésben van a Feather edges-nél? Próbálom reprodukálni, és nagyon olybá tűnik... Szemmel nem is látható, de a széleknél beillesztés után nem egészen FF az alfa. Mindesetre ez most megoldani látszik, most már a PNG export is jól működik erről a rétegről.

( hrgy84 | 2025. 10. 04., szo – 00:10 )

Engem rettenesen zavar az a mondat, hogy "ha palettás PNG-nek akarom konvertálni "PNG8:" előtaggal, akkor az IM is elrontja a képet."

Ez így libpng hibának tűnik, de nagyon. Ugye a GIMP és az IM is ezt használja ténylegesen a PNG fájl kezelésére, nem írták meg nulláról az egészet újra mindkét appban. Amit itt fentebb fejtegettek, hogy a képernyő színprofilját beveszi, az még passzolna a GIMP-re, de az IM-re nem, az egy - ilyen szmepontból - buta program, monitor nélküli szerveren is képes futni, sok weboldal is használja advanced képszerkesztésre.

Azt nézd már meg kérlek, hogy azonos verziójú IM, közel azonos verziójú gépen (szerveren) is elböki-e a konverziót? Erre tudsz egy DigitalOcean-os dropletet is indítani, vagy AWS-ben egy free tier-es EC2 gépet, bármit.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ez így libpng hibának tűnik, de nagyon.
Pedig nem, mert ha kevesebb, mint 256 különböző szín van a képen, az IM magától palettásnak menti, MÉGHOZZÁ JÓL. Én is használom a libpng-t sok proggimban, az a baj, hogy hibásan paraméterezi fel a "PNG8:" kódág. Amikor a kevés szín kódág fut le, ott meg jól, ezért helyes tRNS csonk kerül a kimenetbe. Hiába használja mindkét kódág ugyanazt a libpng-t, ez eltérést okoz a végeredményben.
Amit itt fentebb fejtegettek, hogy a képernyő színprofilját beveszi, az még passzolna a GIMP-re, de az IM-re nem
Ja bocs, nem fogalmaztam érthetően. Itt most ennél a képnél konkrétan nem probléma, de az IM PNG8-cal általánosságban az a baj, hogy 0/1-re redukálja az alfa csatornát. Szóval nem ugyanúgy rontja el a GIMP és az IM a kimenetet, ez nem volt egyértelmű a leírásomból, bocs. (Mondjuk számomra tök mindegy, hogy hogyan rontják el, ha elrontják, akkor nem jó.) Ha a GIMP-el "Image" > "Mode" > "Indexed..." opciót választod, akkor ugyancsak az a gond, hogy 0/1-re redukálódik az alfa csatorna, de ez általános hiba, nem PNG függő.

( bzt | 2025. 10. 04., szo – 19:14 )

Mégsem sikerült megoldani. Most úgy tudtam reprodukálni, hogy teljesen új rétegre csakis Pencil-el rajzoltam, ráadásul a hibás és a jó pixelek között nem is változtattam a színen! Ezúttal 707070-ből lett 717171, amikor legalább két szomszédos pixeljük csupa fekete 000000 volt. Szavakkal képtelen vagyok kifejezni, mennyire elképesztően idegesítő és irritáló az, hogy úgy kell nekem kézzel kijavítanom a rajzolóprogram pixelhibáit, hogy közben a GIMP-ben egyáltalán nem is látszik, mit kéne kijavítanom! Az nem kifejezés, hogy flusztráló. Jeleneg az egyetlen módszer, hogy végigmegy a kép a teljes pipeline-on, majd a legeslegvégén a felhasználói felületen tesztképpen átállítom a színt, és ha itt-ott szürke marad, na akkor ott látom, hogy már a pipeline legelején mely pixeleket baszott el a GIMP.
No problemo. Csak a trollokat nem szeretem, azért még soha senkinek nem haraptam le a fejét, mert tévedett. TLDR; egyébként hogy még érthetőbb legyen a frusztáltságom a GIMP-re, itt a teljes történet. A gyerekkel játékprogramot akarunk csinálni, hobbiból. Gondoltam megúszósra veszem a dolgot, és azt találtam mondtam neki, használja ezt a szprájtgenerátort a karakterei megalkotásához. Akkor még nem sejtettem, hogy emiatt tátott szájjal rohanok be a faszerdőbe. Az nyilvánvaló volt, hogy az LPC egy-az-egyben használhatatlan, mert össze-vissza számú animációs fázisokból áll és emiatt iszonyat pazarlóan üres a szprájtlapja. De gondoltam, majd egy kis ImageMagick szkripteléssel helyre pofozom. Csak hát kiderült, hogy az LPC szprájtlapok annyira el vannak cseszve, hogy képtelenség IM-el feldolgozni őket. Pixelhibák, elcsúszott képkockák, összevissza színek... Így kitaláltam egy szkriptnyelvet, írtam hozzá egy interpretert, és ebben a nyelvben írtam egy szkriptet, ami helyrerázza a szprájtlapokat és előállít nekem rétegenként egy ilyent. Mint látható, míg az LPC külön képeken tárolja a színvariációkat, én inkább lecserélem speciális grayscale színekre az átmeneteket, és a kép alsó sarkába rakom a palettát (ez az, amiért fontos, hogy precízen F0F0F0, D0D0D0, B0B0B0 stb. színek legyenek a képeken). Ez az egész végül a felületen így kattintgatható össze (ez egy kékszakáll-borostás kalóz-tünde-frankenstein épp :-) ). Namost a gyerek egyből egy kalózt próbált csinálni (mi mást), és mindjárt kiderült, hogy az LPC nemcsak itt-ott hibás, de rettenetesen hiányos is. Például nincs futás animáció a kampókézhez. Na itt jön a képbe a GIMP, amivel megrajzolnám a hiányzó részeket. És ha ez hibás színkódot ment, akkor azt csak azután látom, ha exportálás után lefuttatom a szkript interpreteremet, az összenyálazza az LPC képeket, átkonvertálja, ha hiányzik valami, akkor betölti a pótlást, és miután mindent megcsócsált kiköpi a rétegeket tartalmazó atlaszt, majd elindítom a proggit, betöltöm az atlaszt, kiválasztom a réteget és megpróbálom átszínezni, de az szürke marad... Ezt mind végig kell játszani, hogy kiderüljön a GIMP hibája. Szóval ebben az egészben a GIMP csak egy apró porszem, de képes a teljes végeredményt elcseszni nekem.

( asm v | 2025. 10. 04., szo – 22:06 )

Ennyi efforttal mar irhattal volna egy GIMP hibajegyet is.

( Gollam | 2025. 10. 06., h – 11:18 )

én simán visszatértem a 2-es gimp-hez (2.10.38), a hármas egy rakás.....