[krita] [Bug 404317] no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 Tymond changed: What|Removed |Added CC||tamtamy.tym...@gmail.com --- Comment #5 from Tymond --- > Writing a scaled PNG outfile file, without creating intermediary artifacts Just opening the .kra file as a .zip to get out `mergedimage.png` (which is lossless, so no artifacts) and using imagemagick or a similar tool to scale it down should be sufficient, then. For more advanced functionality, would it be good enough to use a Python script and a kritarunner? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404317] no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 --- Comment #4 from brainchild --- I agree that it is a wish. I just hope that given the high benefit and low difficulty, it is not a forgotten wish. You are making a painting application, and facilitating conversion to a standard exchange or display format facilitates distribution of the paintings that artists create with that painting application. A studio painter requires paint, paintbrushes, canvas, and other source materials, as well as packaging materials, to allow shipping out finished paintings, in order to be a successful painter. Writing a scaled PNG outfile file, without creating intermediary artifacts, makes it easier to build web pages, publications, applications, and other larger works for which Krita documents are among the source material, and such support makes Krita a more useful and prolific tool. Thanks very much for considering the request. (For reference, from the man page of Inkscape, various formats can be specified by CLI switch for headless conversion, and '-' is accepted as a filename, representing standard output. Simple selections and manipulations are also supported.) -e, --export-png=FILENAME -a, --export-area=x0:y0:x1:y1 -C, --export-area-page -D, --export-area-drawing --export-area-snap -i, --export-id=ID -j, --export-id-only -t, --export-use-hints -b, --export-background=COLOR -y, --export-background-opacity=VALUE -d, --export-dpi=DPI -w, --export-width=WIDTH -h, --export-height=HEIGHT -P, --export-ps=FILENAME -E, --export-eps=FILENAME -A, --export-pdf=FILENAME -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404317] no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 --- Comment #3 from Boudewijn Rempt --- I understand your feature request perfectly well, but we are making a painting application, and that is the most important thing to us. Which means that no, there's no way any of development that's currently sponsored is going to be redirected towards this feature request: we've got over 400 open bugs and almost 400 open wishes. Most of those have a higher priority. In any case, this is a feature request, so it must be classified as a wish. If it's important to you, you can either work on it yourself or pay someone to work on it. But be aware that it certainly is not easy to "Bypass the graphics layer, and behave though a CLI-only tool, whenever the command invocation does not require graphics" -- that is, in fact, impossible because Qt needs X11 to even render a font. Note that if the 8 bit sRGB representation of the image is sufficient, you can just take out the mergedimage.png from the .kra file, which is a simple zip file. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404317] no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 --- Comment #2 from brainchild --- I am afraid that the purpose of the request may have been lost in your response. No part of the request had the intention, or would have the effect, of competing with ImageMagick. The purpose of this request, as is the purpose largely of standard input and output generally, is to facilitate interoperation of applications to achieve an effect that neither application fully supports in isolation. If you look at the example, you see that Krita is used to achieve an effect that ImageMagick cannot achieve, that is, to read a Krita file; whereas ImageMagick is used to create an effect that Krita cannot achieve, that is, command-line image processing. Together, through the pipe, the two applications do achieve this effect. Intermediary files are generally an option, but often create other issues, such as managing their deletion and finding a location to place them, in the case of scripts. If Krita did offer the full suite of processing capabilities via command line, then the pipe with ImageMagick might be unnecessary. As you correctly say, however, such is not the purpose of Krita. Krita should, however, permit easy interoperation with other tools via pipes, and my request that Krita open standard output instead of a physical file is hardly a tall order. Since no tool currently exists, to my knowledge, other than Krita, that can read a Krita file, the requested feature effectively augments not duplicates the current utility of ImageMagick, such as in the case of producing a JPEG file to half the scale of an existing Krita file. I understand that "feature request" might be a better classification than "bug" for this issue, but I ask you to take it seriously, given the low difficulty of implementation and the considerable utility of use. Given the prevalence and usefulness of support for standard output, I am inclined to suggest that the request is closer to a missing feature than to merely a nice-to-have. Please consider not giving it a classification so low that it is unlikely to be noticed. Thank you for reviewing the clarification, and for taking the time to understand the rationale. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404317] no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 Boudewijn Rempt changed: What|Removed |Added Severity|normal |wishlist CC||b...@valdyas.org --- Comment #1 from Boudewijn Rempt --- Krita really is not meant to be a commandline, console tool competing with imagemagick. I'm setting this to wish, but if you really want this to be implemented, you'll have to roll up your sleeves and start hacking. It just doesn't have any priority. -- You are receiving this mail because: You are watching all bug changes.
