search

meerk40t / meerk40t

Hackable Laser software for the K40 Stock-LIHUIYU laser boards.
MIT License
223 stars 61 forks source link

[Suggestion] Image op has default step / raster wizard #742

Open Sophist-UK opened 2 years ago

Sophist-UK commented 2 years ago

At present if you don't apply a raster wizard/script to images, when you execute an Image Operation, an automatic dither is applied - to Step 1? Not sure exactly what the rules are if the image resolution is > step 1 or non-integral, but presumably it does something.

If the user wants a step other than 1, to save the user having to apply a Raster Wizard manually to each element individually (yes - I know you can use a Raster Script on all image elements at the same time - but only at step 3), could we have a configurable step for an Image Operation (default 1 for backwards compatibility) so that e.g. images can be automatically dithered to step 2 or 4 (or even 3)?

tatarize commented 2 years ago

Some steps have requirements. So if you don't want grayscale to be applied you are disallowed some other operations and leaving them enabled forces it to convert that image to grayscale even though you de-checked the grayscale box. You end up needing to disable a few more of those operations to get it to not grayscale it. The operations can come in any order per-design so the filters while applied in order sometimes tend to assume their requirements are met. The work around is that if they are not and for some reason the image is the wrong type, we just force it into being the correct type.

This system may need a bit of a rework. Dealing with Project Balor it's become a bit obvious that there's issues with converting basically anything into device native units prior to the cutplanning process. It might be the case that we should assign a raster script to an image and perform those actions within the CutPlan, like actualize-image but with more steps. Since we could have objects that we're manipulating and change the device which natively runs different natural units. So the pixel size for one device is wrong for another device and there's no way to to fix it between devices after that's locked in. So it might need to remain dynamic and have the images actualize by default but them also apply these other script commands to the image object afterwards.

There's simply no way to have the same sized pixels work in fairly native units in multiple lasers that could have two different coordinate systems.

Sophist-UK commented 2 years ago

Yes - I can see the issue with different lasers. BUT...

The Raster Wizard actually consists of some tools that act on the image regardless of the laser resolution and regardless of any change of image resolution, and some tools that are concerned with resizing the image to a particular step. These may, of course, be intertwined, but if we could separate them that would allow a cutdown Raster Wizard to act immediately, and then for the Image operation to be responsible for doing the resolution change for steps at execution time.

tatarize commented 2 years ago

In 0.8.x raster wizard is deferred until cutplanning and the scripts are pushed into the image nodes themselves.

Sophist-UK commented 2 years ago

That deferral is a good change.

However the requirement expressed in this issue is not met by such a change - the purpose here is to make Image operations work like Raster operations if a user has not run a Raster Wizard/Script on an image i.e. you set a raster step on the Image operation and at cutplanning time, if the image has not got a Raster script associated with it then (instead of an implied raster step of 1 which is, I believe, currently applied, the suggestion is that the Image operation step is applied by default instead.

Sophist-UK commented 2 years ago

P.S. Is the pushed raster script run when the image is shown in normal scene and / or simulation scene?

In 0.7, where raster scripts are applied immediately, you can often see visually that the image has had a script run on it. Ideally the visual representation in scenes would remain the same even though the finalisation of the raster script is deferred until execution time.

tatarize commented 2 years ago

You can see the proper view in simulated scene, but it happens where actualize used to happen. Generally it's either the script or actualize (which is basically the script). But, it lets you set the various properties and scripts won't take effect (but it will show you a preview in the actual scene). You can tweak the settings in the node properties. This fixes a bunch of weird issues where you couldn't possibly do raster wizard for several different native resolutions or whatever, it would be an actual size and that could be a serious problem if you tried it on a different device or at a different size.

Sophist-UK commented 2 years ago

I think that deferred running of the script is a good thing - I just would like the intended raster script to be reflected in the main scene.

Sophist-UK commented 2 years ago

P.S. It does make saved files bigger - I am used to creating a file with a high-res image in Inkscape, and then saving a LASER7 version from MK after the raster wizard has been applied - and that file would be much smaller.

tatarize commented 2 years ago

The deferred file does show up the raster script in main scene. It just doesn't have that the actual end-result script. It does the same sort of preview that rasterwizard used to run. If you go into properties and you edit the thing a bit, it'll reflect on the version you see in main after a little bit. This is because specifically it keeps the original loaded file and reapplies the script. It can do the same thing on a resize or rotation or whatever. It just reapplies the script in those cases where the pixels will have changed and doesn't make this whole script thing actualized until the cut planner.