[SOLVED] PixelMath Image Scaling (Potential) Bug

[Conor]

First and foremost, let me just say I _think_ this bug is only with the PixelMath tool; I've been unable to reproduce it with any other tool.

Problem:
Reusing the PixelMath tool to create the same image (possibly new images with new data), can cause 'skewed aspect' on resultant images, if the first image has been cropped or scaled.

Steps to reproduce:
1) Use the PixelMath tool to generate an RGB image from greyscale data.
2) Use DynamicCrop on the resultant image.
3) "Zoom to Fit" button on the image view.
4) Resuse the PixelMath tool to generate the image again.
5) Second resultant image will be skewed i.e. enlongated stars etc.

I'm not sure if this is a cosmetic bug, or if the data is actually scaled in one/both axes. If I can provide any further data, please let me know. I'm in the process of examining the data further.

(PixInsight 1.08.01.1092 on FreeBSD 10.0-RELEASE)

EDIT: This isn't actually a bug. Thanks to pfile and Gerald for clearing up any misunderstandings.

[oldwexi]

Can you provide a screenshot of the PixelMath Process.
especially showing all Parameter, including  "Image width" and "Image height".
Gerald

[Conor]

The filesize of the image exceeded 512KB, so I've uploaded it here: https://i.imgur.com/ivuyCnn.png

Left - the first image produced, having applied the DynamicCrop and "Zoom to Fit".
Centre - PixelMath dialogue used for both images.
Right - subsequent image generated using the same dialogue with no processing; I just applied STF and zoomed the image to show the oblong stars.

Again, if I can provide further details, do say so.

[oldwexi]

Hi,
it depends over which image you have dragged and dropped the blue triangle of PixelMath.
If you dropped the triangle over "Image04" than the result of combining Ha, OIII and SII will be resized.
Because you selected Image width and Height of the cropped Image (As target!!!), therefore
your HA, OIII SII will be rescaled in each axis seperately to fit into the smaller cropped Image.

You have to drag the triangle always over the HA, or OIII or SII original and not on over
the cropped Image.

Gerald

[Conor]

I generated a new image, as you can see in the dialogue, in both instances. I haven't applied the operation to an image. Perhaps we have our wires crossed.

[Carlos Milovic]

How are you applying the Pixelmath instance? Are you throwing the drag and drop icon to any image, using the Execute icon (square) or the Execute Global (circle)?

[Conor]

I'm executing it (Square icon). Just so we're on the same page, this is what I'm doing:

1) I have three narrowband images which I combine with PixelMath.
2) I configure the expressions and output as shown in the screenshot.
3) I click Execute (square icon)
4) I process the reesulting image, including applying DynamicCrop i.e. the frame is now smaller.
5) I click Execute (square icon) again.
6) The _second_ outputted image is 'squashed', for want of a better term i.e. the dimensions are equal to that of the first image, with the DynamicCrop applied.

Whether it's a cosmetic bug, or something more serious, I still think there's a bug here, not to badger the point. I can upload a second screenshot with the second image a bit clearer to demonstrate the effect I'm talking about.

[oldwexi]

Hi,
This is not a bug, because you selected the actual (cropped image) as the new width and height by using the square Icon.
PixelMath does not Crop with the Width and Height Parameter, it does a scaling. Thats nice for creating Image sizes you Need.
If you replace the width and height with the wished image size you can enter any value, the image will either be rescaled
or gets the size of the Ha, OIII and SII if you enter the correct values instead of "As target".

Or as mentioned before you drag the triangle over one of the original Images.

If your wish is to crop the Images you should use the crop process.

Gerald

[Conor]

I think you're completely misconstruing what I'm suggesting the problem is. The "As target" part is what I think the bug is. I'm not using the PixelMath tool for cropping images, I've used the DynamicCrop tool for that, as I've stated several times.

Shouldn't the "Create new image" option actually create a new image, with the expressions as inputs i.e. not based on another unrelated image? For example, when I create the first image with the PixelMath tool, the image height and width are set to "<As target>" -- what target does this pertain to? The resulting image from the operation is of the appropriate dimensions -- the height and width of the input data -- why isn't that the case for the second image? I use the square button in both cases.

If it is the case that the square icon automatically uses the first resultant image as the "target" for subsequent images, shouldn't there be a global context in which it can be applied, such that it consistently creates images with the same dimensions as the input data?

[pfile]

well… no. processes always have a target image even if the actual pixel data is unrelated to the target. for instance you can use NewImage to create two new images, say one 256x256 image and one 256x512 image. then in pixel math if you set R,G,B to 1 and create new image with all the rest of stuff defaulted, if you apply the PM process to the 256x256 image you'll get a white square image. if you apply it to the 256x512 image you will get a white rectangular image.

if the pixel math expression is the identifier of another image, that's where the scaling that Gerald is talking about comes in.

i think this makes sense because in general, which of the 4 input images should be the image you take the dimensions from?

whichever image is topmost is the target image for the square button in any process.

rob

[Conor]

Hmm, that clarifies things somewhat. It's my misunderstanding of the apply (square) button, in that case. If I grok this correctly, to apply the PM tool in a global context and have dimensions equal to the input data, I need to plug in the dimensions manually. I don't know how I missed this behaviour in previous versions of PI...

Finally, to answer your question regarding which of the input images you should take the dimensions from; it would make sense to me to take the maximum X and Y dimensions of the set of inputs, even if these figures come from two separate images. It'd be nice if there was a "dimensions from input" option on the dialogue to accommodate this, I suppose. I can make an appropriate post for that elsewhere.

Thank you for clearing up my misunderstanding, both pfile and Gerald. I had the wrong end of the stick entirely.

[pfile]

cool. but what if the pixel math expressions... are expressions that do not refer to any image? or expressions that refer to multiple images? then there's no clear image dimensions to take. i think that's the problem and juan wants to avoid overloading the expression inputs with extra semantics, like "if there's no image name in the expression box then take the dimensions of the target" and "take the image dimensions of the first/last image in the expression" etc. that way leads to madness

rob

[Conor]

That's a very good point. I hadn't thought of expressions containing multiple inputs or sans image inputs altogether. I can see how that would lead to combinatorial explosion with regard to expression semantics.

I wonder if using expressions for the output dimensions would be a possibility; in all cases, the expression would expand to a scalar value. Say, if you could define dimensions with `sizeof image_z` which would result in an x/y tuple, or macros like `HEIGHT(image_z)` and `WIDTH(image_z)` or some such. This is probably overkill and more work than just entering the dimensions manually. Just a thought!

Thanks again, Rob.

Conor.