Firemonkey "kazí" obrázky nahrané v TImage

[age.new]

Kdybych to věděl, tak bych se neptal. Jen mi ještě nedochází kam se ten obrázek ukládá, když ne do dfm / fmx souboru?

[Stanislav Hruška]

Samozrejme, že sa ukladá do dfm/fmx. Ja sa v tom vôbec nevyznám. Prikladám ukážku uloženia jedného obrázka (DataModul). Ja akosi nevidím dôvod na také čachre-machre ako si tu popísal. To nič nemení na tom, že to nesmie mať vplyv na už uložené údaje.

Kód: Delphi [Vybrat]

1.   object icDBNavN: TImageCollection
2.     Images = <
3.       item
4.         Name = 'button_rounded_blue_first'
5.         SourceImages = <
6.           item
7.             Image.Data = {
8.               89504E470D0A1A0A0000000D49484452000000100000001008060000001FF3FF
9.               61000000097048597300000EC400000EC401952B0E1B0000010349444154388D
10.               63B4ABD81CC7C0C03085818181978134F09181812183858181611A0303033789
11.               9A19181818F819181866B290A91906F85828D0CCC0C0C0C08061C0963A770606
12.               0606069FA69D28E2AA527C0CFD299618E21806F072B2A2F0A584B818925DD519
13.               9CF4A51898181909BB000604B8D918E29C5419FCCCE41958599888F7020C2C2F
14.               7562E062271C443855FCFCFD973203A27AF63344D8293184D9283170B2E13608
15.               A7CCB79F7F18E6EDBEC5B0E1C44386446735062F1359061666CCB0C030E0E3B7
16.               5F28FC779F7F32F46EB8CCB0EAC83D86A999D6180630DA556CFE8FD37D4400AA
17.               A4C4EF0C0C0C9C64EAFFCCC2C0C050C0C0C030810C43BE323030E402002AA331
18.               398595F1EF0000000049454E44AE426082}
19.           end
20.           item
21.             Image.Data = {
22.               89504E470D0A1A0A0000000D4948445200000018000000180806000000E0773D
23.               F8000000097048597300000EC400000EC401952B0E1B00000201494441544889
24.               BD95314C136114C77FEF7AE56893DA5661C1868190D468A4C4BDC69030906010
25.               D4A00E0D717271305189713630EAE2647464C090C0C28830B9484888830B8321
26.               612046890B9AD8E7C0DDF1DDD76B0F6AE37F79FFF7BEBB77EFFFCF77DF27D5D9
27.               9522F05A446EAAAA0B2022A2AA6A7333B7A3B1F61B58109187EB73E33F5DE00D
28.               3009081036FA07A4811AE0003557446EF8CD111131278DE3666E478BDF016AAE
29.               AA0A1027B55D8B029E0670EDC95415558DE54024B7A331470837467E2237733B
30.               E2DB1D7EC094171455958DF9EB00CCBFDF62F5D36E643A114155B9776D90D1E1
31.               F3DC7FB561AE47FA452C8A436FBEBBA13632D4C7A389CBA41C21D3956AF97E83
32.               45C1844616D62EF6177976ABC2B99C47D6739B5978328B8EA1F4E6BB797E7B98
33.               72A940A62B155A0450AFABFDCEE92CBA32D0C3DDAB8389563443A245E55281AC
34.               D73847F08CE3B4B98B027CD9FD41B954C0735338CE71737FFF275B94A46073E7
35.               1B2F16B7783A55E142294F2E93EEAC0250F60F0E79FCF62397FA8B3C99AA7036
36.               E791CFA64FA6C09EBE153E7FFDCECCCB0FE17FA0C0195F5133245AB47FF0ABA1
37.               B6B6BDC7DAF61ED3D5014686FAECF5E8D1539D5DA99B9202A9E65E37B999DBD1
38.               4768D1FADCB89CCAA276F07F4FD30E5F387FE06817AD02636DE96F8D2538B268
39.               0678078C8988634E1AC7CDBCC99D5C0796810700A231D75C27F117824915763A
40.               B3E0CF0000000049454E44AE426082}
41.           end>
42.       end
43.       item
44.         Name = 'button_rounded_blue_previous'

Netuším, či aj pri klasickom TImageList je obrázok rozdelený na dve časti ako tu. Predpokladám, že áno. Jaj, ja tam mám 16x16 a 24x24 .
Nepoužívam FireMonkey, takže to nemôžem vyskúšať.

[pf1957]

Jelikož ze strany Embarcadero něpřišla žádná odpověď, vytvořil jsem postup, který by měl reproduktovat problém s TImage. Mimochodem, děje se to i v nejnovější Delphi verze 11.1. Zajímal by mě Váš názor.

Znovu jsem se dival na ten puvodni hexa dump s rozdily, ale ten ti nic nerekne, protoze na zacatku PNG formatu jsou shodne chunky: iHDR, iRGB, gAMA a prvni iDAT, ktery obsahuje kompresovany stream dat, ktery se lisi.

Pokud bys do toho chtel sam nejak proniknout, tak abys zjistil, co se presne deje, tak bys zrejme musel napsat nebo si upravit nejaky existujici dekoder resp. porovnavaci tool, ktery by ten soubor dekodoval a zobrazoval rozdily az na vyssi urovni. Taky jsme to delavali treba 3-cestne, kdyz jsme v ramci zpetneho inzenyrstvi lustili nejake cizi proprietarni formaty.

[age.new]

Samo o sobě je podezřelé, že první uložení PNG obrázku má nějakou datovou strukturu a restart Delphi tuto strukturu změní i co se týče velikosti. Je to navíc jediný ukazatel na problém se změnou grafiky PNG souborů, který je vidět pouhým okem - hlavně u poloprůhledných pixelů.

[pf1957]

Samo o sobě je podezřelé, že první uložení PNG obrázku má nějakou datovou strukturu a restart Delphi tuto strukturu změní i co se týče velikosti.

Podezrele... to by mohl byt ev. dusledek pouziti radkoveho filtru, ktery ma za ukol zlepsit kompresi viz treba https://www.root.cz/clanky/radkove-filtry-v-png/. Aby tomu tak nebylo, tak by se vzdy musela pouzivat filtrace None, coz nevim, jestli Delphi dela. Ale co se presne deje, k tomu bys potreboval dekodovat obsah puvodniho a deformovaneho obrazku, jak jsem ti psal.

Resenim na prasaka, kdy se nebude zjistovat presna pricina, je vyhnout se tomu, abys pri zmene formulare zapisoval take obrazek -> dat ho nekam do "ReadOnly" banky a odtamtud ho jen nacitat a renderovat, asi neco ve smyslu, co ti doporucoval Standa.

[JaroB]

No, na mě to dělá dojem, že ta bezztrátová komprese v PNG je trošičku ztrátová

[pf1957]

No, na mě to dělá dojem, že ta bezztrátová komprese v PNG je trošičku ztrátová

Neznam detailne vnitrnosti formatu PNG, ale zda se, ze filtrace kvuli zlepseni komprimace muze pusobit ztratove, coz by samo o sobe nemuselo byt na zavadu: vytvorim obrazek, ulozim ho se ztratovou "kompresi" a prohlednu si vysledek, jestli jsem s nim spokojen.

Ovsem u Delphi je problem, ze on obrazky nevytvari, jen nacte existujici a pak si je nekde schovava => to by mel delat vyhradne bezeztratove tj. s filtraci None, aby original jen verne prekopiroval. A pokud to nedela (nevim), tak je to z principu spatne a EMB by to mel zmenit.