@Mark *** Thanks for your expertise. I couldn't do that this perfectly. ***
One of the reasons for posting this JPNG stack is to show the power of LC: The essential code of compressing PNG -> JPNG and decompresing PNG -> JPNG is both less than 10 *essential* lines of code, using comfortable LC tools. It is currently "en vogue" to try using JPEG compression together with transparency. The js- and/or objC-people have to do _a lot more_ for that. So take my demo stack as 'suggestion for the engine', to add a JPNG format to LiveCode with a compression parameter and an useAlphaDataOrMaskData switch. [ Possibly also with adding JPEG 2000 (.jp2)? ] The work is nearly done as it is already available in the engine to a big part. And for the dictionary entry use your post ;-) This all could contribute to make the size of standalones that contain a lot of PNG-compressed images significantly smaller. An may also be of advantage for a usage together with the browser widget. Once again, with a JPEGquality of 80 I have here in average JPNG-compressed sizes of 30% compared to the original PNG-compressed sizes. [I'll update the JPNG stack today for use on RaspberryPi 2/3 (and in LC 6/7).] ==== Mark wrote: > On 2017-08-11 09:29, Richmond Mathewson via use-livecode wrote: > > In theory that sounds both impressive and useful . . . > > > > But, what, apart from your stack can read the format/compression > > method properly. > > I think Hermann's suggestion is a bespoke way of reducing resource size > for built apps and their content - as there isn't a 'standard' for JPNG > (yet) it isn't really useful for interchange between apps, but it might > be that a standard does appear at some point. > > > Can your stack export a JPNG image? > > It doesn't need to in order to be useful. This is something which could > be used at the point of building a standalone (in a standaloneSaving > handler, for example) to convert PNG images into a smaller form for use > by the app at runtime. > > > "This may even result in a larger data size than the original when > > decompressing." > > I'm not sure I quite understand that comment... > > Any (loss-less) compression algorithm will produce output which is > larger than the input for some inputs > (https://en.wikipedia.org/wiki/Lossless_compression#Limitations). So all > (such) compression algorithms tend to have a flag in their encoded > output which says 'this is not compressed'. When the compressor runs, if > the output is greater in size than the original input it just emits the > output with that flag and the original data. (In this case, if the JPNG > process produces a data size larger than the original PNG, just use the > original PNG!). > > In this case the JPNG idea exploits the fact that color images tend to > withstand data-loss, but alpha data (masks) do not - JPEG is lossy, it > removes information which our eyes cannot see. PNG compression (a > variant of gzip IIRC) is loss-less, it preserves the exact values of the > inputs. So you use the lossy method (JPEG) on the part of the image > which makes no difference to our eyes, and the loss-less method (PNG) on > the part of the image which our eyes would notice a difference in. > > Warmest Regards, > > Mark. _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
