YOUR ACCOUNT

rjp74
Posts: 21
Filters: 7
It is often the case that the preview window is blank even though the result window is correct.
code used is in next message

  Details E-Mail
rjp74
Posts: 21
Filters: 7
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
Have you tried it on source images with varying pixel dimensions? Try one with dimensions matching the small thumbnail on the component.
  Details E-Mail
rjp74
Posts: 21
Filters: 7
Yes, I have tried this with varying success. With this filter it works with 96x96 images but not with larger ones. I do know there is a bug in my code which I have to resolve. When the preview is linked to a specific component I was expecting it to show that component and not the final image.

However, in some other filters where the code is correct and the original image is drawn correctly the preview is sometimes not drawn or partly drawn. The final image is correct when not in edit mode. The preview seems more prone to go wrong when the compute time in the prepare() section is long.

Due to get_sample(x, y) working pixel by pixel which does not work well with a collection of vectors I am preparing a computationally heavy optimising routine that breaks the set of vectors down into small manageable groups that only needs to be computed once no matter what size the final image is or whether it is the 96x96 image used in the editor. Currently my code is using the Liang-Barsky algorithm to chop up the vectors. This works. In the new version I am trying a simpler approach which should give better response times. Initial testing indicates a reduction of the get_sample(x, y)compute time from 50 seconds down to around 2 or 3 seconds on a 400x400 image. However, because the prepare() function runs multiple times this computational heavy routine runs N times when only once is necessary which slows things down a lot. These seem to run in parallel threads. So the non-display of the preview might be some sort of race condition. I don't know how to force the prepare() function to run only once which is what I expect it to do.
  Details E-Mail
Dmitry Sapelnikov
Filter Forge, Inc. AKA Egret
Posts: 76
Filters: 5
rjp74, I've inspected the filter. The script is quite complex, so it's rather difficult to discover the problem fast.
I suppose the main problem of the script is using pixel values of OUTPUT_WIDTH, OUTPUT_HEIGHT and SIZE in the filter.
While some FF native components use output and filter sizes for some purposes (for example, noises for correct seamless tiling,) they DON'T use pixel values, only relative ones.

On the screenshot below you can see a simple script example which makes different results for the main and the component previews. The explanation is simple: we have different pixel sizes of the previews.

We've got 600x600 main preview and, according to the script formula, 600/200 = 3.0 value in pixel channels.
But the component preview has 96x96 pixel size, so that the pixel channel values there will be 96 / 200 = 0.48 which is much darker than for the main preview.

The solution is to use relative output size, i.e. OUTPUT_WIDTH/SIZE, OUTPUT_HEIGHT/SIZE.

  Details E-Mail
rjp74
Posts: 21
Filters: 7
Thank you. I am already using scaling using OUTPUT_WIDTH and OUTPUT_HEIGHT in the code in several places. I still have a logic bug to fix though as my new algorithm results in some "holes"

This does not sort why the preview is not always drawn though. As written before I have seen this in several more complex filters.
  Details E-Mail

Join Our Community!

Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!

33,711 Registered Users
+18 new in 30 days!

153,533 Posts
+31 new in 30 days!

15,348 Topics
+73 new in year!

Create an Account

Online Users Last minute:

23 unregistered users.