Image converter support

abduct commented 7 years ago

This is a feature request to add image conversion support built into Cum. I suppose this could be done via ImageMagick externally, or if python has any built in image conversion utilities/packages.

I find I am forever converting some series from more obscure formats such as webp to png and/or jpg and was just wondering if there could ever be support to have this built in via config settings and external calling of the Imagemagick morgrify application.

Thanks.

CounterPillow commented 7 years ago

I've thought about something to this effect before, and I'm currently unsure about how generalised this functionality should be. One thing that's for certain though is that it needs some changes as to how cum currently saves downloaded manga; zips from Madokami never get extracted, for example, and some of them even are in RAR format which makes the whole idea of an automatic unpacking step even scarier.

What it essentially boils down to is how many use-cases such a feature should support, from simple image conversion to advanced postprocessing of all images using whatever command line tool the user chooses.

An important part is that cum needs to know where the resulting files after processing end up, so that it can pack them into the final archive.

There's multiple approaches to this issue. I'll go through them real quick.

1. Having cum convert the images

This would be very limited in scope, as the only functionality would be image conversion. It would also require cum to add a dependency to something like pillow, which while not completely off-limits, is not the nicest thing ever either.

2. Having cum call hardcoded external tools to convert images

This is essentially as inflexible as the last approach, but gets rid of the python module dependency and instead replaces it with a dependency on one of a selection of command line tools being installed. In [Minecraft-Overviewer](https://github.com/overviewer/Minecraft-Overviewer] we have something similar in the optimizeimg functionality, where users can choose from a variety of pristinely wrapped image optimisation tools to run on each image. The lesson I learned from that one is that each tool has a different modus operandi as to how it deals with input and output files, which makes the user really benefit from having them nicely wrapped as config options, but makes the developer tear their hair out as they discover yet another flaw in the way a tool is invoked. It also means all possible post-processing tools one may want need to have corresponding wrapper code inside cum.

3. My proposed solution: Having cum add a powerful general post-processing configuration syntax

Instead of restricting ourselves to image conversion, generalising this into a general post-processing functionality would give us the most flexibility. It would, however, also require us to allow users to fine-tune how the programs are invoked, as the user needs to tell us how the tool should be run to do processing from input A to output B, with the right file extension and all.

Imagine a mime-type matching config syntax like this:

"post_processors": {
    "image/webp": [
        ["convert", "{{IN}}", "{{OUT.jpg}}"],
    ],
    "image/jpeg": [
        ["jpegoptim", "{{INOUT}}"],
    ],
    "image/png": [
        ["zopflipng", "{{IN}}", "{{OUT}}"],
    ]
}

The idea here is that the tokens {{IN}}, {{OUT.ext}} and {{INOUT}} are replaced by cum with filenames of its choosings so it knows where to find the results and with what extension the tool should save them. {{IN}} would be the input filename, {{OUT}} would be the an appropriate output destination and filename that cum chooses, and {{INOUT}} means "this tool overwrites the input file, so choose that to pack into the final archive". The .ext part is for cases where the file extension changes, e.g. when converting from one format to another.

I've not yet solved the issue of shit like pngnq-s9 only being able to either write with a specified prefix or write to a specified output directory (as opposed to just having an output file option), but I feel like I'm overengineering this entire thing already.

abduct commented 7 years ago

I like the idea 3 the most out of all of them. Not only does this allow a user to specify external (optional) applications, but it could also allow for further conversion customization via the external applications flags and feature set which can be specified via the config.

For instance this means if the end user really wants maximum compression jpegs for their archives they could simply pass

convert -strip -interlace Plane -gaussian-blur 0.05 -quality 5%

Which not only opens up ways to reduce file size, but opens up the full external applications feature set which can be used to customize and improve image quality. This could even go as far as if the external application allows for scripting to further automate the image processing (Cough, white space trimming and color adjustments, Cough) outside of CUM.

This would indeed be a powerful feature when paired with a powerful feature filled external image processor all while keeping CUM simple and manageable by offloading the processing to a purpose built application.

Hamuko / cum