Add export resolution support for rescaled images/animations

[HanzPetrov]

Hi Ollie,

Here is a proposed feature that allows rescaled images & animations to be exported at a predefined PPI, which can be set under Export Settings:

Basically a high-resolution export feature. Let me know if there is anything here that you might want to do differently.

Thanks!

Hanz

PS. Took me a bit of time to get this working without breaking Thumbnails! ;p

[SonarSonic]

This is something I'd be planning to add too! I think the additions that could be made is a way to re-scale images that are imported with Original Sizing, and have the export resolution displayed next to the DPI.

[HanzPetrov]

Hi Ollie,

For re-scaling images imported with Original Sizing, do you mean something like generating a custom drawing size based on the aspect ratio of the original image and a settable DPI?

PS. Yes, displaying the current output resolution next to the DPI text field would be good.

[SonarSonic]

I guess it gets trickier to do this but you could have one for Re-scaled Resolution and one for Original resolution. The re-scaled would be PPI like you have and the original one could be a simple multiplier, which could be set, say between 1x and 5x with decimals.

Although I'm not sure what the best name for these would be.

[HanzPetrov]

Hi Ollie, I have always found this aspect of how DrawingBot (and Scott's original code) works to be somewhat challenging, particularly when looked at from the end user's point-of-view. The idea that one pixel of input equals one "unit" of stroke width of output is rather abstract, especially given that the end goal of the typical user is likely the generation of gcode or other output that is ultimately intended to be printed or plotted, and therefore tied to physical dimensions. Would it not make sense to scale any and all input to a physical size, based either on page size (for re-scaling) or input DPI (for conversion from Original Sizing to output size)? Might be interesting to outline some use cases. Your thoughts? Hanz

[SonarSonic]

Hey Hanz,

Thanks for your thoughts! It's a tricky one, and something that I've been wondering about for a while and so have kept it fairly simple for now. It's tricky to know what the best solution is, scaling to a physical size could be a good solution. Obviously as it currently stands high resolution images take a long time to process and vice-versa. Whereas if all images were a standardized size by default this would create more predictability and the algorithms may perform more consistently - the size the image were scaled too would probably need to be a fit into a A4* image but keep it's original proportions, and then for digital art I guess it could either be exported at the new DPI, or you could choose to lock it to the original images dimensions. New users who don't know that they should set the Drawing Dimensions, will also get more consistent results (Scotts code actually forced all images to 1000px height). Behind the scenes we would still stick Pen Width = Pixel Width because it results in very efficient PFMs which are much easier to maintain, only for the processed image though. A 1920x1080 image may still have different proportions.

*the default scaling would probably need some playing to see what works best for all PFMs, though it could also be configurable....

Another question slightly related is if PFMS which have options like "Point Count" should actually be "Points Count (per inch)" so that the PFM is consistent regardless of the size chosen, currently it's more of a guessing game to get the same density. I have avoided this because it makes it less obvious for Digital Only outputs but if they are re-scaled behind the scenes this would still be relevant.

EDIT: it would be interesting to see if digital art still renders in a pleasing way when the original image size is way off the scaled image size. Another benefit is if you input a tiny 500 x 400 image (and you want to make digital only art) you could result in one much higher res to play with.

[HanzPetrov]

Hi Ollie, I'll also need to give this more thought, but in the meantime, here's another tangent to consider: In my modded version of Scott's code, I reworked the Bresenham functions so that they consider Pen Width when "bresenham_lightening". Basically a way of combining the "Adjust Brightness" and "Plotting Resolution" parameters to allow PFMs to generate strokes based on variable pen widths, but without needing to "Rescale to Pen Width". This essentially emulates a Gimp/Photoshop eraser, and treats all images equally (i.e. it's up to the user to choose an appropriate page size, pen width, and fade rate - hopefully resulting in predictable physical output), Here are some lightened examples (same pen width, but showing hard vs soft lightening):

[SonarSonic]

That's cool! The issue I have with DrawingBotV3 is handling Beziers, they'd probably need anti-aliasing for this too work. Does it work by having a separate image at another size and using that to get the positions and then re-applying that to the smaller one?

[HanzPetrov]

There is only one re-scaled image that gets lightened. My lightening function lightens not only each pixel that is on the bresenham line, but it also lightens the adjacent array of pixels surrounding each pixel on the bresenham line. The thicker the pen, the larger the array of pixels that gets lightened. My version is crude because it uses a square array rather than a radial array - so diagonals are lightened more than verticals or horizontals - but it's hard to tell from the output (good enough - "as long as it's pleasing" ;)

[HanzPetrov]

Hi Ollie, There is a good write-up here on how Inkscape deals with what is essentially the same problem (i.e. determining the appropriate scale for a drawing): https://wiki.inkscape.org/wiki/Units_In_Inkscape It seems that we might only need to establish a reasonable default DPI setting for import (which the user could override), and based on your suggestion of a default A4-ish page size, something around 150 PPI might be about right. (The CSS standard of 96 DPI - as adopted by Inkscape - is probably too low res for PFM line tracing.) Here is a table that outlines how the typical page sizes would translate into pixels and "pen strokes":

Let me know if you are able to draw any conclusions from this (pun intended ;)

[SonarSonic]

Thanks for your work Hanz! I'm going to merge and make one slight change to allow Export Tasks to have independent Print Resolutions.