2016/10/20(Thu) SWFEditor 0.65 をリリースしました

SWFEditor 0.65 をリリースしました

  • PHP7 対応しました。
  • chunk 間にゴミがある JPEG 指定で replace 出来ない不具合を修正しました。

PHP7 対応

@withgod 先生から対応コードを頂きました。ありがとうございます。


JPEG chunk 間のゴミ

chunk の頭は 0xff なので chunk の頭と思って読んで 0xff 以外だった場合は、読み飛ばしてその後ろの 0xff を探すようにしました。



オライリーの "Understanding Compression" から


When it comes to the relentless bulk of web content, images are by far the largest load bearer today (although there’s an argument to be made that videos have become king as of late).

But what’s truly interesting is that as much as compression information can help solve some of the congestion, there’s a massive amount of human problems that keep compression from making its way into everyone’s hands.

Let’s take a trip back to 1985, when Unisys filed a patent for the LZW compression algorithm.

A few years later, when CompuServe invented the 89a format (which later became the GIF format), they used LZW as its backbone, not realizing that it was patented.

Unisys didn’t care about this until 1993, when the Netscape browser added support for the IMG HTML tag, alongside support for the 89a format.

Within a year, animated images became all the craze on the Internet, and Unisys began enforcing its patent.

CompuServe and Unisys eventually reached a court agreement in December 1994, announcing that Unisys would begin collecting royalties from all software that used the 89a graphics format.

In the months following this decision, a group of seven engineers developed an entirely new, patent-free format known as the Portable Network Graphics or PNG format.

Within another few weeks, PNG was fully supported by the Netscape browser.

In 2004, the patent on LZW finally expired, but for an entire decade, the GIF/PNG image format debate was a hot one among Internet folks.

JPG has been a standard for some time now, and is generally accepted by most image-editing programs and Internet browsers.

In 2013, Google and a set of other open source contributors were able to create a new image codec algorithm named WebP, which aimed to compress images smaller than JPG while keeping the same image quality.

WebP’s savings aren’t huge, maybe 5%–30%, depending on the size of the image.

However, these are massive savings for companies that operate in the big image business (e.g., shopping and social sites). To these companies, a 30% reduction in size means a significant reduction in cost as well as faster transfer and loading times.

But there was one huge challenge with the WebP format: getting it adopted by every browser.

Chrome (being developed by Google) was the first to adopt it.

However, the real drama comes from the fact that the largest competitor at the time, Mozilla’s Firefox, wanted nothing to do with with WebP and openly rejected it, stating that it wasn’t powerful enough, and that it didn’t compress as well as JPG variants.

In fact, the Mozilla engineering team even open-sourced a new MozJPEG codec to improve the lossless preprocessor phase of JPG, all in an attempt to rebuke further WebP adoption.

This pushback didn’t stop Google from implementing the codec for Google+ and its Google Play store. Facebook soon followed with support for their own implementation, all the time praising the gains in compression and image quality.

Since then, WebP adoption has been expanding, even becoming a dominant part of some compression for video games.

Mozilla’s hold-out didn’t last. In 2015, the company had a change of heart about the WebP format and stated publicly that “technology decisions often are the result of personal predilection, political scheming, and inter-company rivalries. But cold hard data still can win the day.”

And there’s a lot of wisdom in that statement.

These stories of image formats on the Web help shed light on some interesting truths about technology adoption, programmer mentality, and customer benefit around compression.

Even though an algorithm might be technically superior, it’s still subject to the same product biases that relate to all types of technology output. It still must fight for acceptance and approval among a world of engineers who are generally skeptical by nature.

2016/10/11(Tue) ImageMagick-6.9.6-1差分


ImageMagick-6.9.6-1差分 - yoyaのメモの続き

The latest release of ImageMagick is version 6.9.6-2



ChangeLog の分
  • Unit test pass again after small SUN image patch.


2016-10-10  6.9.6-2 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.6-2, GIT revision 11095:14d2cea:20161010.

2016-10-10  6.9.6-2 Cristy  <quetzlzacatenango@image...>
  * Unit test pass again after small SUN image patch.

2016/10/09(Sun) ImageMagick-6.9.6-1差分


ImageMagick-6.9.6-0差分 - yoyaのメモの続き

The latest release of ImageMagick is version 6.9.6-0



ChangeLog の分
  • Fixed incorrect RLE decoding when reading a DCM image that contains multiple segments.


2016-10-07  6.9.6-1 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.6-1, GIT revision 11092:1f7ca24:20161008.

2016-10-07  6.9.6-1 Dirk Lemstra <dirk@lem.....org>
  * Fixed incorrect RLE decoding when reading a DCM image that contains
    multiple segments.

2016/10/03(Mon) ImageMagick-6.9.6-0差分


ImageMagick-6.9.5-10差分 - yoyaのメモの続き

The latest release of ImageMagick is version 6.9.6-0



ChangeLog の分


2016-10-02  6.9.6-0 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.6-0, GIT revision 11078:9aec251:20161002.

2016-09-27  6.9.6-0 Dirk Lemstra <dirk@lem.....org>
  * Fixed incorrect RLE decoding when reading an SGI image (reference