Animated bitmaps (APNG) in OTF fonts - animation

The Open Type font format standard 1.7 officially supports three types of colored glyphs, as required for emojis. As of late 2016, version 1.8 has added support for another variant. Platform support varies:
Microsoft’s/Mozilla’s COLR/CPAL tables use standard Truetype glyf or Postscript CFF  outlines.
Mozilla’s/Adobe’s/W3C’s SVG  table uses SVG outlines and CSS Variables.
Google’s CBDT/CBLC tables use embedded PNG bitmaps.
Apple’s sbix table uses embedded PNG, JPEG or TIFF bitmaps (and PDFs outside the standard). Support for masks and aliases is planned.
The SVG table explicitly considers animation – using CSS, JS, SMIL or embedded files – but I’m not sure that has been implemented anywhere yet:
Glyph Rendering
The SVG glyph descriptions may be rendered statically or with animation enabled.
Does any of the PNG-based implementations support animation using APNG? How about tools?
Compressed Color Bitmaps
Images for each individual glyph are stored as straight PNG data. Only the following chunks are allowed in such PNG data: IHDR, PLTE, tRNS, sRGB, IDAT, and IEND. If other chunks are present, the behavior is undefined.
JFTR, APNG relies on three additional chunks which both OS X / macOS and iOS natively support:
acTL Animation Control
fcTL Frame Control
fdAT Frame Data
So, if I’m not mistaken, APNGs should work in sbix verbatim, but not in CBDT.

APNG seems to be supported in Firefox and Safari only, so that'll be the same when used as font glyphs.
I figure you already considered this, but if GIF suffices, your best bet would be OpenType SVG. It has the widest support, and you can embed bitmap images in the SVG: see glyph 0050 in this test font.
Regarding non-bitmap animations in OpenType SVG, unfortunately you can't use JavaScript animations, and with SMIL on the way out you're stuck with CSS animations... which don't currently work in Firefox and Edge 🙃

Related

Can I convert from swf (or fla or svg or snap or sprite.js) to bodymovin

I have a bunch of animated vector graphic files that I would like to convert to bodymovin (I assume I would need to convert them into after effects first and use the bodymovin extension).
I animated files in swf, fla, svg (using the animate element inside the svg), snap and sprite.js html5 formats. I need to preserve the animations (recreating them is not an option)
Is this possible? Any ideas?
I have imported one of my animated swfs directly into after effects and exported to an mp4 but it won't export to bodymovin (I think swf and the vector graphics are very different)
I had the same problem. You should get Bodymovin plugin for Adobe Animate CC. Have a look here: https://github.com/airbnb/lottie-web/issues/1604

How to remove anti-aliasing in PDF images?

I use Abbyy FineReader for ScanSnap to OCR a couple of scanned PDF files. The software claims it retains the original PDF images. The PDF file sizes pre-OCR and post-OCR are almost identical, which is good.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Left: Scanned PDF / Right: after OCR with Abbyy
I would like to get the original images without anti-aliasing back. Interestingly, when I open a single page from the anti-aliased PDF in Photoshop, there is no anti-aliasing and the image looks like the left one.
My limited PDF programming experience leads me to believe that Abbyy likely sets some kind of anti-alias flag for each image during OCR processing. How do I un-set this flag?
Any pointers to useful ideas would be much appreciated.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Actually in the original file 2013_11_15_22_51_31.pdf contains a JPEG image while the OCR'ed file 2013_11_15_22_51_31_OCR.pdf contains a JPEG2000 image.
Comparing them in third party viewers, it becomes clear that the image in the OCR'ed file is not inherently anti-alias'ed. Furthermore there is no evident flag in the PDF instructing PDF viewers to apply anti-aliasing to the JPEG2000 image. Thus, Adobe Reader seems to automatically render JPEG and JPEG2000 images differently, applying anti-aliasing to the latter but not to the former.
Comparing both images in detail, though, it becomes clear that these images are not identical but instead the image in the OCR'ed PDF is slightly rotated.
I assume Abbyy FineReader recognized that the original scanned image is not correctly oriented. Thus, it rotated it slightly to correct this orientation.
Thus, replacing the image in the OCR'ed version with the one from the original one is no option: Due to the rotation the OCR information would partially be somewhat off.
What you might want to try is to recode the JPEG2000 image to JPEG and replace the image in the OCR'ed version with this recoded one. This will mean some loss of quality but most likely you can get rid of the anti-aliasing this way.
Be aware, though, that the JPEG2000 image is slightly larger than the JPEG image to accomodate for the rotation.
PS: As #VadimR pointed out, there is indeed an /Interpolate true entry in the image dictionary of the OCR-ed version I missed when looking at the file. This does not seem to be the major issue slowing down the rendering.
There is /Interpolate true entry in image dictionary of OCR-ed version, and that's what causes 'anti-aliasing'. Whether that (and not JPEG2000 instead of JPEG compression) is a cause of slow-down, you check on large enough files.
To un-set this key, the best would be to turn it off while creating a file, and if that's not possible, to write and run a small program in suitable language.
But, since your file doesn't sport 'compressed objects' and offending key is in plain view inside a file, in the spirit of 'job done quickly' you can simply process your file e.g. like this:
perl -M-encoding -0777pe "s!/Interpolate true!' 'x17!ge" <in.pdf >out.pdf

What image formats do the major browsers support? (2012)

I was wondering what image formats (aside from the basic JPEG, GIF, PNG) the major browsers would support, especially Chrome, Firefox, and Webkit. If anyone can provide a link to a list somewhere (that is updated frequently to cope with the frequent updates recently) that would be great. Support for other formats (like document and video) would also be nice.
I feel like this information should be listed somewhere, but I didn't find any such thing when I searched.
Here is a nice resource: http://en.wikipedia.org/wiki/Comparison_of_web_browsers#Image_format_support
Major image file support
.bmp, .jpg, .jpeg, .png, .gif
New
.webp
The image format supported in popular browsers: BMP, SVG, JPG, PNG and GIF. There is no two format jpeg or jpg, it's one with multiple extensions used due to see here.
Note: SVG(Simple Vector Graphics) can produced much smaller images but allows only vector images(no raster).
Next, the other formats used are webp and jpeg2000.
Webp:- Supported by many browsers such as Chrome, Opera. There is an issue running for Firefox support here. Note that, Webp can reduce the image memory size to around 30-40% of the original size(in our experiments) on an average. This doesn't means always as sometimes we have seen transcoded webp from jpegs to go beyond the original jpeg size. The output image had no visual difference compared to original jpegs. My suggestion: serve webp where possible, i.e. Chrome, Android, Opera.
JPEG2000:- This format is great. Resizing an image does not drop quality as much as JPEG. The problem is it's too computation intensive for decoding and the fact it came over a decade ago when hardware wasn't great(especially not meant for mobile). It still is used in some cameras as it results in smaller images.
Less popular but worth mentioning: BPG and FLIF. This will require using JS or other library to serve on web/app.
JPEG and PNG are supported by the every browser. But the new image format which is webP is only supported by the Chrome, and partially by the Firefox and not at all supported by the Safari at all. Thou WebP is really good as it does not compromise with the quality of the image and also reduce it to 25-35% less. But we cant still use it because it is less flexible in the different browser environment.
But you can look for the other image format also which are available and compatible for each browser type.

Alpha transparency in indexed-png images

Here is an image:
This image is a simple black-to-transparent gradient saved in full RGBA PNG.
Here is the same image, converted to indexed-alpha PNG by GIMP (Photoshop produces the same result)
As you can see, the gradient is now half-opaque, half-transparent.
Here is the same image again, only this time it was converted to indexed-alpha PNG by a PHP script I wrote:
So my question is: Why are GIMP and Photoshop unable to support partial transparency in indexed images, when the PHP script clearly shows that such an image can be created with no problems?
Is there anything "wrong" with an image whose pallette contains alpha information?
A more programming-related question: Does this transparency in the last image work in Internet Explorer 6?
I've finally found the actual answer: There is a metadata entry that allows you to define the alpha value of each colour in the colour table. Most graphics programs don't make use of this, but it does exist and can be used, in particular by GD.
Another option besides fireworks is pngquant, a command line application that will convert a rgba png into an indexed png with transparency.
I found this post which talks some more about how to use it.
IE6 and earlier in windows does not support variable transparency PNGs without annoying workarounds. An indexed PNG will only show the fully opaque parts which usually works pretty well. A drop shadow would disappear but the opaque parts of the logo or icon would continue to show.
This page has a better explanation and instructions with more png compression and quantization tools: http://calendar.perfplanet.com/2010/png-that-works/
For the record, PNG does not literally support indexed images with an alpha channel. What is really happening is that PNG allows you to add additional colors to the color table (i.e. index) with alpha values in those colors... not a complete alpha channel. FWIW...
Yeah I know what you mean. Fireworks is the only image editing program that I know of that can create and edit PNG8+Alpha without problems. I wish more paint programs would support this format cause Fireworks is expensive!
I found a way in GIMP to create or convert an image with reduced color palette and alpha channel.
The trick is to add a mask to the layer.
Full steps to reproduce:
Have your image in one layer
Add a mask to the layer. Select Transfer layer's alpha channel.
Convert to Indexed (Image -> Mode -> Indexed...)
Save as PNG
Now your image has reduced colors and reduced size, but it keeps your smooth transparency.

WAP Colored Images

I'm beginning with WML development, but I hate that the only option that we have for images are the WBMP format, that is only grayscale, then I want to know if there is any way to have colored images using WAP 1.x(not the new 2.x versions of it).
Standard colour image formats such as BMP, PNG, JPEG, GIF and animated GIF were supported in the Openwave browsers (certainly Openwave Mobile Browser v6), which were shipped on a huge number of WAP mobile phones. I think it a reasonable assumption that other WAP browsers have similar support.
Beware that some browsers may not support certain advanced features of these formats e.g. progressive display/download in GIF, PNG and JPEG.
So you should be able to do e.g.:
<img alt="text" src="url" />
where the URL specifies a BMP, PNG, JPEG, GIF, animated GIF etc.
The Openwave browsers also allowed img elements within do and option elements as a non-standard extension to WML.

Resources