PNG seam carving chunks. (seMw, seMh)

As a fun quirk I recently read the PNG specifications and that's some clever stuff. It's wildly extensible even by 3rd party folks. I recall messing around with seam carving years ago, and I now realized that PNG files themselves would be a fine way to store seam carving data. seMw seMh chunks would define the seam carving width and seam carving height enumerations. The data in these blocks would contain zlib compressed data (compression identical to that of other PNG chunks) of 8/16/24/32/etc bit numbers, one number, per pixel laid out left to right, top to bottom. The required bits of the number is the ceiling function to the next full byte needed to express the maximum value to enumerate that dimension. So if your width is 255 you can make do with a 8 bit number but between 256 and 65535 you need a 16 bit number. The numbers are stored in big endian notation (like that of PNG) The blocks for seMw and SeMh are independent (as required by PNG) so if you have a 360 x 240 image it will require 2 bytes per width, and 1 byte per height.

That's it. We just provide a number for each pixel, in one or two directions.

Height carving will be done first. Because of the need for pixels from other scanlines to fill in the gaps left by the now missing pixels and then the width carving.

Height carving:
* All pixels that are above a given height threshold are declared blank
* Entirely blank columns are removed.
* All pixels are copied to the topmost available pixel and blank pixels are overwritten.
* The new height is the position of the last complete scanline.
* If some scanlines are the new height, that they are truncated.

Width carving:
* All pixels that are above a given width threshold are declared blank.
* Entirely blank scanlines are removed.
* All scanlines pixels are copied to the first available pixel and blank pixels are overwritten.
* The new width is the shortest valid scanline.
* If some scanlines are longer than new width, they are truncated.

Do note, that if a threshold value causes all values in a scanline to be blanked that scanline, during width carving, is removed. Likewise if all column pixels are blank in height carving that column is removed. This allows for thresholds within width carving that remove entire lines (so long as they are the same scanline). These removed scanlines and columns are disqualified from being the shortest valid scanline or causing no scanline to be completed.

There is no guarantee you will get a particular width or height, just that it can be reduced. If at a certain pixels have a value of 0, these cannot be removed until the value is actually 0 (unless removed by the other directional carving). If all pixels are given a minimum value of 120-width the entire image is gone below that value. If well behaved it will simply reduce gradually losing seams in a proper and effective manner, if not we behaved it could do a bunch of weird and kind of rebellious things, all of which are valid. If a block (seMh, seMw) does not exist, it's assumed that it values are all entirely 0. That is to say regardless the threshold given (above zero) it won't change, and need not be implemented.

You should not assume the values are actually seams, they simply number assigned to pixels in width and height directions. The removal algorithm remains the same.

The process is not iterative. You remove the height pixels then the width pixels. If you perform this operation again, the the correct result is if you did this from the original image.

There is no requirement that both width and height carving be implemented, you could simply implement direction (width would be the easiest there).

--- The general advantage of this scheme is that in most cases it'll just be a normal PNG and work like a graphics file except in something or other that cares about this data. And when nothing cares about that data it'll be fine and just store a normal image file anyway.

If unix time is base 36, the last word in the unix epoch is ZIGZAG

Never makes it to 7 letters words. All words in 2018 start with P.

1547408965 PLACED Sun Jan 13 11:49:25 2019 1543566578 PIZZLE Fri Nov 30 00:29:38 2018 ... 1528992094 PABLUM Thu Jun 14 09:01:34 2018 1511124996 OZONIC Sun Nov 19 12:56:36 2017

September 9th was full of words. There will be no more until October. 1540710226 PHARMA Sun Oct 28 00:03:46 2018 1540702422 PHALLI Sat Oct 27 21:53:42 2018 1540695700 PHAGES Sat Oct 27 20:01:40 2018 1536787497 PEYOTL Wed Sep 12 14:24:57 2018 1536787490 PEYOTE Wed Sep 12 14:24:50 2018 1536700131 PEWTER Tue Sep 11 14:08:51 2018 1536686416 PEWITS Tue Sep 11 10:20:16 2018 1536680692 PEWEES Tue Sep 11 08:44:52 2018

Human brains are basically trash.

It takes a lot of humility to realize how utterly stupid human brains are. They are actually pretty trash, but while you're thinking with one, you think they are absolutely flawless and inerrant but that's exactly the problem.

"Behold, I come quickly."

Though the Bible is filled with prognostications about the premature exaltation of these mortal coils, this God fellow extends this much-promised rapture like a guy who thinks he is himself 'God's gift to Mankind' but is excessively focused one tiny pointless strip in the desert.