ImageCompressionBear

[jayvdb]

git-lint (coala/meta#59) has a few linters for file formats that are not supported by coala, especially non-optional image compression detection for PNG and JPEG.

They are built using shell scripts that can be found in https://github.com/sk-/git-lint/tree/master/scripts/custom_linters , wrapping commonly used binaries.

jpegtran-linter.sh: The file size can be losslessly reduced from $origsize to $newsize bytes. ($reduction% filesize reduction)
optipng-linter.sh: The file size can be losslessly reduced from $origsize to $newsize bytes. ($reduction% filesize reduction)
pngcrush-linter: The file size can be losslessly reduced from $origsize to $newsize bytes. ($reduction% filesize reduction)

There are two python libraries which provide this type of functionality.

1. https://pypi.python.org/pypi/imgutil
2. https://github.com/sk-/optimage

The latter is by the same author as git-lint, so probably much better for our needs (and it does use more binaries to attempt to reduce the size of the image).

This is a medium difficulty bear proposal, as it works on binary file formats, which is not typical for coala and will likely cause some interesting problems to be solved.

[Makman2]

ooh that's cool :)

[Makman2]

though we don't have support for binary files yet, it was planned that FileProxy gets support for that^^

[jayvdb]

The FileProxy code I saw would be completely useless for this, as it was universal line based. That is actually why I objected to its prior design.

Also, as this would be a linter bear, a file proxy would be irrelevant.

[jayvdb]

I have created a GCI task for this : https://codein.withgoogle.com/tasks/4815242129309696/ (unpublished)

[Makman2]

we could change behaviour of FileProxy and supply a new field/property:

class FileProxy:
    ...
    @property
    def raw(self):
        """bytes object"""
         return self._raw

[Makman2]

and still maintaining a universal-newline version^^

[sils]

This is a medium difficulty bear proposal, as it works on binary file formats, which is not typical for coala and will likely cause some interesting problems to be solved.

FWIW if we use optimage there won't be the possibility of using the coala in-memory files because omtimage works a lot with the file system directly.

[Makman2]

Also, as this would be a linter bear, a file proxy would be irrelevant.

and yes right, have forgotten that fact...

[yukiisbored]

coala's dependency_management is still not ready for systems that doesn't have supported package managers. Related issue: https://gitlab.com/coala/package_manager/issues/144