T O P I C R E V I E W |
zerob |
Posted - Oct 02 2024 : 09:48:13 Export formats like PNG still have unneeded bloat ghostdata exported, which blows up the size and also has security implications)
Things like PNG are no temporary work in progress formats like PSDs, with a need to later freely change my mind and therefore the need to retain certain stuff for later re-edits. Unneeded, hidden data does in my mind, not have to be preserved and exported into the export format, but purged from the file. ImageEn does export the whole image data and simply hides it with alpha channels.
I've done a demo to show this in a intentional manner, to point to this. I added a colorful image with the full dimensions of the canvas 1912 x 1014 pixels, Then i've dawn a tiny star (TIEShape.iesStar5) to the alpha channel. Then i did a ImageEnView1.LayersSaveMergedTo(bitmap) And a bitmap.SaveToFile('test.png') with max compression and all filters.
Then i loaded that PNG again, filled the alpha with white and saved it to a new PNG to restore the hidden data. (which surprisetly shows the whole initial image)
Then i loaded it again and blackened out all Alpha = 0 pixeldata in two separate ways to compare the filesize once with clBlack and once with Proc.GetDominantColor(dom,[clBlack]); on the blackened file, to just calculate the colors in the star and not introduce a fresh color, if black wasn't there already. (as i thought the dominant color would compress better than black, which it didn't)
And then i just took black instead of the dominant color as my best result.
My results: 1540 KB (1.500MB!) Normal ImageEn PNG 1363 KB (1.300MB) Alpha restored initial data from PNG (alpha channel whitened) 10 KB (0.010MB) Hidden data replaced by dominant color of the non hidden data 8 KB (0.008Mb) Hidden data replaced by black (much better compression)
I think either hidden data has to be removed by default in export formats that arent intended to restore and alter the original content, or the save param of these formats could have a Purge unneeded data param. In my mind only editing formats like PSD should include hidden data, and not exporting formats like PNG, WebP, Gif, BMP (or even unpredictable stuff like Clipboard copies) and so on. These are meant to stay in that form and be saved as small as possible, without hidden bloat or even security implications (handing out hidden unknown data).
I send you a demo. |
7 L A T E S T R E P L I E S (Newest First) |
xequte |
Posted - Oct 05 2024 : 17:24:38 Hi
It will be in the next beta.
When enabled, it will optimize the image channel when saving to PNG, PSD, 32bit BMP, JPEG2000 (ioJ2000_RGB color space), WebP and WIC formats. It is not needed for GIF.
Nigel Xequte Software www.imageen.com
|
zerob |
Posted - Oct 04 2024 : 02:00:47 Nice, thank I've tried bmp.SyncAlphaChannel( True, True ); which works, and i guess, the IEGlobalSettings().AutoOptimizeOnSave isn't included in that beta, as it needs a lot of work to get done properly :-) Will this affect all formats or just some export formats? And will there be an exclusion or param to exclude some formats? For example PSD, IEN... |
xequte |
Posted - Oct 03 2024 : 23:57:33 OK, we will add this as: IEGlobalSettings().AutoOptimizeOnSave
Nigel Xequte Software www.imageen.com
|
zerob |
Posted - Oct 03 2024 : 21:56:23 I understand, that it needs to be an option with bold prominent info on the helpfile and that i intentionally used up the whole screen.
But it is rather normal when working with layers and alpha to build a nice image composition, to still have a chunky area hidden by alpha. Even when using transparency for web elements, there will be a not irrelevant portion of empty area.
Also security and privacy plays a role in some situations. Imagine cropping or erasing some persons or children or places or just uploading a photo of a thing to sell on ebay, while standing there in pijamas next to a still messy children toy mountain or anything else you wanted removed before oploading. The inhouse used dev tools won't include most of the stuff, but you never know what things accidentally get published when you build the next photoshop, paint shop pro or a wildly popular sharing tool. You never know what some fan or script kiddie discovers on closely inspecting a image or reusig or reediting it for some meme in some thirt party tool. Or maybe do the graphics of a huge page or game, where the disk or transfer bloat quickly gets into the hundreds of giga or terrabytes.
|
xequte |
Posted - Oct 03 2024 : 21:28:45 Hi
We'll consider making it automatically optimize the non-alphas content when saving in a later release.
It would need to be an option though, as it destructive (some users would not content cleared unexpectedly).
In your examples it does make the image significantly smaller, but your examples are atypical (keeping only 0.05% of the original image). Most times the differences are much more modest.
Nigel Xequte Software www.imageen.com
|
zerob |
Posted - Oct 03 2024 : 00:35:01 Hi Thank you for implementing this. Will there also be a longterm solution for all different components, ways and places that save these formats (ImageEnView, IO, Actions...) ant things that only alter on export and not permanently delete all data in a ImageEnView while editing a new graphic while saving it to check or as backup while still editing? Doing a merge to a iebitmap for a destructive syncalphachannel to save is ok in most instances, but sometimes you can't as some imageen functions may do the saving by themselfe or don't expose a bitmap or do it by TAction or you just don't want the work in progress Layers to be altered. Also in case of PNGs, WebP, GIFs and other formats i think people would never again use IO. to save them, when a iebitmap saves nearly 20'000% smaller files. |
xequte |
Posted - Oct 02 2024 : 21:20:56 Hi
Please email me for the latest beta. You can use:
bmp.SyncAlphaChannel( True, True );
To remove any non-visible content.
Nigel Xequte Software www.imageen.com
|
|
|