hh at hyperhh.de
Fri Aug 11 06:32:55 EDT 2017
*** 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).]
> 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,
More information about the Use-livecode