Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gaussian noise preview, somewhat mixed up preview oddety. (Old + Win:XP) #60

Closed
MvGulik opened this issue Jan 23, 2017 · 7 comments
Closed
Labels

Comments

@MvGulik
Copy link

MvGulik commented Jan 23, 2017

Some odd (and old) image-preview behavior (to me) on Gaussian noise generated image(s).
(A minor issue at best. Don't mind knowing what might be triggering this (if known and its not to technical).)

When previewing a Gaussian noise generated image in nip2 (when not using a power of 2 zoom level) the preview image shows a bit mixed up preview.
Image: example that nicely show the odd bands.
capture_01232017_200350

  • Only effects/seen in image preview(s) for images with Gaussian noise generated data in them (as far as I could tell).
    -- Only for none 'power of 2' zoom levels. (ie: zoom 200%, 400%, 800%, etc don't show this)
    -- Saved image files are ok / not effected by this.

Nip2: 8.4.0 (Not tested on older versions, but I have seen this before a long time ago.)
OS: Win:XP

@jcupitt
Copy link
Member

jcupitt commented Jan 23, 2017

Oh dear! Yes, seen on linux as well. I'll investigate.

@jcupitt jcupitt added the bug label Jan 23, 2017
@jcupitt
Copy link
Member

jcupitt commented Jan 23, 2017

It's only a half-bug, I think. The gaussnoise operator generates random pixels every time it is called, so if a pixel is generated more than once (as it can be on zoomed tile overlaps), you'll see different answers.

To fix this, gaussnoise should make a single random seed for the whole when it starts up, then use the (x, y) coordinate plus that seed to make a number for a pixel. I'll make an issue on the libvips tracker.

Thanks for reporting this!

@MvGulik
Copy link
Author

MvGulik commented Jan 24, 2017

Roger.
Thanks for explanation.

jcupitt added a commit to libvips/libvips that referenced this issue Jan 24, 2017
previously, pixel values were regenerated on every calculation, so they
changed on recomputation

pixel values are now generated from the pixel (x, y) coordinate plus a per-call
seed

thanks MvGulik, see

libvips/nip2#60

https://github.com/jcupitt/libvips/issues/583
@jcupitt
Copy link
Member

jcupitt commented Jan 24, 2017

OK, fixed! Thank you very much for pointing this out. The fix will be in 8.5, due in March 2017.

@MvGulik
Copy link
Author

MvGulik commented Jan 24, 2017

PS:
Seeing the "plus a per-call" part, I think that also changes/fixes a none intuitive exception I spotted on multiple Gaussian-pattern usage.

Merging 3 Gaussian patterns, with identical settings, will probably now also generate a colored image instead of a (virtual) gray scaled image.

  • A1, A2, A3: Pattern_images_item.Noise_item.Gaussian_item.action
  • A4: Object_assemble_item.action [A1,A2,A3]

Correct ?

Better to ask now I think.

@jcupitt
Copy link
Member

jcupitt commented Jan 24, 2017

I tried a tiny Python program:

#!/usr/bin/env python

import sys

import gi
gi.require_version('Vips', '8.0')
from gi.repository import Vips

r = Vips.Image.gaussnoise(100, 100)
g = Vips.Image.gaussnoise(100, 100)
b = Vips.Image.gaussnoise(100, 100)

im = r.bandjoin([g, b])

im = im.copy(interpretation = "srgb")

im.write_to_file(sys.argv[1])

And it makes this image:

x

So it looks like noise on an old analogue colour TV.

You're right though, try that in nip2 and you'll see a plain grey image. I'll try to fix that too.

@MvGulik
Copy link
Author

MvGulik commented Jan 25, 2017

Roger.

In that case ... I can't resist giving it its own ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants