Need help understanding images is PJSR

[gloefer]

I'm trying to transition from my old image processing suite PVWave to PI.
I'm a long time image processing /algorithm guy. I'm familiar to expert in many programming languages and image processing tools.
My primary expertise is in PVWave, with a recent foray into Matlab.

I won't add another carp about documentation - i just accept that as why I paid 1/10 th the price for my personal package.

Following the advice on this forum I've begun learning PJSR using examples. I've started with the LinearPatternGenerator shared by Enzo De Bernardini. Thank you Enzo.

My first attempt is to generate a linear ramp in either x or y in a Uint16Integer image.

I have disabled much of Enzo's code I didn't need. below are the lines I believe are relevant and dumps to the console

My questions are
First I expected to see a linear intensity ramp going from black to white, left to right.
Instead I see the ramp and the integer values reversed. I suspect from the next effect.

Second When I dumped the values to console the x,y and fltx values are incrementing as expected, but the sample value is obviously a normalized float that is decrementing. It appears to be some intensity mapping function, but I clearly don't understand the process.

Help please?

defining the window and image:

     var window = new ImageWindow( parseFloat(this.img_w), parseFloat(this.img_h), 3, 16, false, true );
      var view   = window.mainView;
      var img    = view.image;

      var x, y, p, PV_Long, fltx;

      var width  = this.img_w;
      var height = this.img_h;

the code core:
 // Pattern Making
      switch( this.direction ) {
         case "Vertical":
            // y values
            PV_Long =width;
            //for( y = 0; y < height; y++) {
            for( y = 0; y < 1; y++) {
              // X Values
               //for ( x = 0; x < width; x++ ) {
               for ( x = 0; x < 32; x++ ) {
                  fltx = parseFloat(x);
                  img.setSample(  fltx , x, y, 0); // R
                  img.setSample(  fltx , x, y, 1); // G
                  img.setSample(  fltx , x, y, 2); // B
             console.writeln( "  x: " + x +  " mod x: " + Math.mod( x ,16) + "fltx: " +fltx + " sampl: " +img.sample( x, y, 0));
              };
            };
 

the output
 x: 0 mod x: 0fltx: 0 sampl: 0
  x: 1 mod x: 1fltx: 1 sampl: 1
  x: 2 mod x: 2fltx: 2 sampl: 0.9999847409781033
  x: 3 mod x: 3fltx: 3 sampl: 0.9999694819562066
  x: 4 mod x: 4fltx: 4 sampl: 0.9999542229343099
  x: 5 mod x: 5fltx: 5 sampl: 0.9999389639124132
  x: 6 mod x: 6fltx: 6 sampl: 0.9999237048905165
  x: 7 mod x: 7fltx: 7 sampl: 0.9999084458686198
  x: 8 mod x: 8fltx: 8 sampl: 0.9998931868467231
  x: 9 mod x: 9fltx: 9 sampl: 0.9998779278248264
  x: 10 mod x: 10fltx: 10 sampl: 0.9998626688029297
  x: 11 mod x: 11fltx: 11 sampl: 0.999847409781033
  x: 12 mod x: 12fltx: 12 sampl: 0.9998321507591363
  x: 13 mod x: 13fltx: 13 sampl: 0.9998168917372396
  x: 14 mod x: 14fltx: 14 sampl: 0.999801632715343
  x: 15 mod x: 15fltx: 15 sampl: 0.9997863736934463
  x: 16 mod x: 0fltx: 16 sampl: 0.9997711146715496
  x: 17 mod x: 1fltx: 17 sampl: 0.9997558556496529
  x: 18 mod x: 2fltx: 18 sampl: 0.9997405966277562
  x: 19 mod x: 3fltx: 19 sampl: 0.9997253376058595
  x: 20 mod x: 4fltx: 20 sampl: 0.9997100785839628
  x: 21 mod x: 5fltx: 21 sampl: 0.9996948195620661
  x: 22 mod x: 6fltx: 22 sampl: 0.9996795605401694
  x: 23 mod x: 7fltx: 23 sampl: 0.9996643015182727
  x: 24 mod x: 8fltx: 24 sampl: 0.999649042496376
  x: 25 mod x: 9fltx: 25 sampl: 0.9996337834744793
  x: 26 mod x: 10fltx: 26 sampl: 0.9996185244525826
  x: 27 mod x: 11fltx: 27 sampl: 0.9996032654306859
  x: 28 mod x: 12fltx: 28 sampl: 0.9995880064087892
  x: 29 mod x: 13fltx: 29 sampl: 0.9995727473868925
  x: 30 mod x: 14fltx: 30 sampl: 0.9995574883649958
  x: 31 mod x: 15fltx: 31 sampl: 0.9995422293430991

[Carlos Milovic]

Hi

It seems to me that the problem here is that you are setting as the pixel value a number that is outside the normalized range. So, try dividing fitx/31 and see if this solves the issue.

[oldwexi]

Hi gloefer!
To create a ramp with increasing brightness, PixelMath is less complex
than the PJSR...
Enter in PixelMath:

Step = 1 / Max(Width($T),Height($T)); ( Step*xpos())
execute it on the actual Image

and it creates a horizontal ramp without programming pages and pages ....

You can imbedd this PixelMath Expression in your PJSR script from history Explorer,
it saves you all these loops coding...

Gerald

[gloefer]

Thanks, Carlos. I will try your suggestion. Although for my purposes, I will be eventually using the data as array indices - so they should be true integer. But at least maybe I can better understand image format.

Thanks Oldwexi - your suggestion looks good for quick prototyping. However, my long term goal is to learn at least PJSR, perhaps PCL. i like to have my own toolbox of custom functions. This is just the first lesson in the first class.

[gloefer]

Carlos. Ok. Your suggestion worked. So I conclude window.mainView.image must be a normalized float, even though the new ImageWindow specified Uint16. I will explore further. Thanks!

[Carlos Milovic]

I'm far from an expert in PJSR, just coded a few toy scripts (I work with c++/PCL), but maybe this makes sense:
The PCL tries to give a framework where we can modify/access pixel values regardless or their data type. That's where the normalized range comes into the scene. Through the use of templates, all pixel values are translated transparently to the [0,1] range, so we don't have to code special code for each case. Also, several algorithms get simplified by not specifying the range.
If you need to store "physical values" (out of range, integer values, or negative values) you can still do that with real images (Image or DImage, float or double type), directly making the pixel value asignation. If you are working with integer images it won't work, because of the wrap around problem (For example, if you asign the value 1.1 to an 8bit integer image it is translated as 1.1*255 = 281-> = 26 because of the overflow). Out of range images will not be displayed correctly, and most of the tools won't work on them... but you can do that. There is even a wild tag to use with PixelMath to allow out of range values.
So, my guess is that the PJSR is doing something very similar to this, behind the curtains, and assumes that all images use the normalized range.

Hope that this helps to find a logic to programing in PixInsight's way

[gloefer]

Thanks for the excellent explanation, Carlos. That's what I was looking for - how PJSR is handling images. I understand everything you said. It's not quite what I'm used to, and I'll have to adjust how I do things. In other packages I frequently used integer images for indirect addressing because it gave significant performance improvements.

[Carlos Milovic]

I think that you may do that with the PCL... but PJSR is higher level, so I think that you have to stick to the normalized range. Let's see if Juan jumps in here and gives you a better answer.