PixelMath - a 'Bug', or my stupidity?

[Niall Saunders]

I was trying to be clever last night - I wanted to paste two versions of the same data, side-by-side, into a new image, twice the pixel-width of the original.

Obviously, I could have done this in any of the common 'Paint' programs, but I wanted to be able to achieve this whilst still maintaining the original dynamic data range inherent to the FITS format.

So, I created a 'clone' of (one of) the images - by dragging its name tag to the workspace background. I then used <Processes><Geometry><Resample> and un-clicked <Preserve Aspect Ratio>, and then set <Width><%> to 200, and dropped the instance on the cloned image.

Then I went to PixelMath and used the following expression in the RGB/K line

Code: [Select]

iif(x()<width($T)/2,pixel(HaRGB_final,x(),y()),pixel(RGB_final,x()-width($T)/2,y()))(I left everything else at the default settings)

The intention here was to use data from the HaRGB image when the pixel position (i.e. 'x') was LESS than 'half-way' across the target image, and the RGB image when the pixel position was 'beyond' the half-way position.

This certainly gave me two images 'side-by-side', with the HaRGB version on the left half, and the RGB (only) version on the right-hand side.

But this is where I seemed to be having a problem. The right-hand side of the new image was identical to the RGB image - and was 'full colour'. But the left-hand side - although 'the same' as the HaRGB image, was in 'mono', seemingly all three colour channels contained 'the same' information - I don't know whether the Rd, Gn and Bu channels were 'all' copied into each channel - it was too difficult to tell.

But I was able to 'fix' the problem with a second PixelMath expression, as follows (again, just using default values, and entering the expression in the RGB/K line)

Code: [Select]

iif(x()<width($t)/2,pixel(HaRGB_final,x(),y()),$T)
This time I WAS able to get the HaRGB data to appear on the left-hand side of the image, and found (by experimenting) that if I just left the right-hand side 'alone' (by re-using the $T data) I could achieve what I wanted - but by a far more convoluted process.

My question is, "Am I just trying too hard , or is there a problem with the initial expression that I was trying to use?  "

Any suggestions?

[Juan Conejero]

Hi Niall,

You have found a bug in the PixelMath interpreter. I have confirmed this bug, which must be a regression (I don't know from which version). So the stupidity is all mine

I haven't found a workaround. Copying the same expression on the R, G and B slots (after disabling the "Use a single RGB/K expression") and specifying the correct channel indexes, as in pixel( A, x(), y(), 0 ), doesn't work either. Obviously the interpreter is not selecting the correct channel indexes internally.

I'll fix this bug as soon as possible. Sorry for the inconvenience, and thanks for catching it!

[Niall Saunders]

Hi Juan,

Yes - I had tried all sorts of combinations of single-channel and multi-channel expressions, but nothing seemed to work. I guess I just 'struck lucky' with the method I finally used. At least it worked.

What I am now looking for is a method, within PI (hence using the actual FITS data) that allows me to view the image FULL-SCREEN (surrounded by a BLACK border, if needed) with NO distraction from any operating system, or user interface 'white areas'). Sometimes this is what I want to do, to be able to get a true perspective on my images, viewing them on a large (28") monitor in a darkened room.

In this case, what I was trying to do was to compare the image with, and without, the addition of Ha data multiplied into the Rd channel. Once the 'bugs' are ironed out, it will be simplicity itself to create a PSM file containing the four process steps needed:
1.) ImageID to rename one of the two images to 'Left'
2.) ImageID to rename the other image to 'Right'
3.) Resample to rescale to 200% in the X axis, creating a new 'recipient' image from either one of the 'source' images
4.) PixelMath, appplied to the 'Recipient' image, that places the 'Left' and 'Right' images in their respective locations in $T target

Then all I would need to do is to 'Merge' that ProcessIcon dataset with whatever I currently had in the workspaces.

Talking of which, can you see a way of allowing PI to save only those Process Icons that ahave been 'selected', or maybe even just those icons currently within a selected workspace? And, if so, could a 'reload' of Process Icons be targeted AT a workspace, rather than reloaded into the workspaces that they originally were saved from?

Cheers,

[Juan Conejero]

Hi Niall,

I'll work on fixing this bug starting from tomorrow. I hope to be able to release a fixed version of PixelMath together with the new ImageRegistration and ImageIntegration modules. Hopefully this will happen in a few days.

[Niall Saunders]

Hi Juan, and Happy New Year - I take it you have been 'resting' - I hope so, becuase we intend to work you very hard in 2010 

Can I ask you to have a quick look at some of my posts in the other section - I wasn't sure whether to post them here in 'Bugs', as they weren't really bugs - but they may have some bearing on your workflow in the next few weeks.

Cheers,

[Juan Conejero]

Hi Niall,

Happy 2010 to you too! 

Yes, I've been resting a bit. I have rewritten PCL's entire fast Fourier transform support (integrating KISS FFT library and redesigning the whole high-level interface). I have designed, implemented and tested a new automatic intersection detection feature for StarAlignment. Now you don't need to define previews on overlapped mosaic regions, as StarAlignment is able to find them automatically. I have integrated Qt 4.6 into PI's main development trunk on all platforms, and tested it deeply to release a first 64-bit version for Mac OS X (without too much luck, I must say). Other than this, I've rested. 

I'll try to resync myself with all pending forum posts; please be (even more) indulgent with me.

[Juan Conejero]

Hi Niall,

This is to inform you that this bug (along with a few others) is now fixed. Your PixelMath expression works fine.

A new version of the PixelMath module, including these bug fixes, will be released soon. The same release will include an updated/improved version of the StarAlignment tool.

Thank you for your patience.

[Niall Saunders]

Great news Juan - I am sure Yuriy was having a similar problem (if memory serves me right !)

Cheers,

[georg.viehoever]

Hi Juan,

This is to inform you that this bug (along with a few others) is now fixed. Your PixelMath expression works fine.

is this bug limited to PixelMath, or does it have effects on JavaScript functions such as Image.apply() or ImageStatistics. I am asking because I saw some strange results during experiments lately (which also could be bugs produced by myself, I did not yet have time to investigate).

Kind regards,
Georg

[Juan Conejero]

Hi Georg,

No, these bug fixes are exclusive to PixelMath.

As far as I know there are no problems with PJSR's Image.apply() and ImageStatistics; these methods and objects work nicely in all of our testing and working scripts.

As always, feel free to ask any doubts about PJSR programming topics on the corresponding forum board. Or, if you find a bug in PJSR (heaven forbids), please report it here.

[mmirot]

Juan,

How about the Calibration Module will it make it into the next update?

Max

[Juan Conejero]

Max,

How about the Calibration Module will it make it into the next update?

Yes, that is my intention. As I've said on another thread it's just a matter of patience. Let's migrate to the new server and we'll continue normal development.