garagecoder wrote:
@Ronounours: How about passing the input image width/height to scripts as global gmic vars? Perhaps given that info some filters could render a more accurate preview? That way nothing existing breaks but you can get the dimensions if you want.
Well, from my point of view, I think that most of the inaccurate previews are not caused by the fact that the image dimensions are not those of the final image (after all, the ratio is preserved, and it often suffices in making things easier), but rather by the fact that some of the image statistics are not preserved in what the preview widget gives as a thumbnail.
Particularly, the real min and max values are lost, for any zoom factor. The min and max of the gradient norms are also important features that are missing.
So, of course, I could pass all those values as global variables so that the preview commands can try to do a better job, but I don't think this is a good idea at all, because :
- You probably don't want to write a version of your filter specific to the preview, considering these extra variables (it will probably requires some changes in the code compared to the original filter, and I doubt many people will have the motivation to do it).
- You will probably need (one day) some extra variable linked to a particular image characteristic that we didn't think about, and thus you will ask for a new extra variable, and you will have to wait for a new version, and probably you will abandon the idea of doing a better preview
- For most of the filters, those extra variables will be useless, but still will take time to compute (and as they will be computed from the full-size image, it can take some time !).
- You will need to add those extra variables not only for the GIMP plug-in, but also for other interfaces of G'MIC (Zart, G'MICol, and maybe future Krita integration). I wouldn't like to be responsible of breaking all these interfaces because the extra variables are not defined (of course, you could check if they are defined in your preview command, but this becomes a bit ugly).
Note that on the other hand, there are simple rules that can be respected to enhance the preview rendering. The most important one to me is to avoid at any price the mixing of 'global' and 'local' features of the image for a filter to compute. When someone codes a new filter, he should have an idea on which scale (zooming factor) is the best to get an accurate preview, and then decides the meaning of the parameters regarding the scale he chose.
For instance, a lot of filters define some 'smoothness' parameter, used practically as the argument of a '-blur' function internally used. Depending on the 'best' preview scale, it could be better to call '-blur' with '$1' (for a local scale) or '$1%' (for a global scale). A lot of G'MIC commands accept '%' arguments, and this is very useful to use them when possible, to make a better preview (but not only of course).