mergeing stips with offset

[fmw42]

You can only do fx calculations in-line like that in IM 7.

But I still do not understand. If your image is not a multiple of your crop size in either dimension, then you will get these short x or y pieces. I would think, it would be easier to crop your input image first to a multiple of your crop WxH. Then the crop won't create these extra pieces that you would need to delete.

[imaggie]

Thanks, I'm not sure which of us is not understanding the other here.

The image is a exact multiple of the 128px strips in height. the width is fine but there is an alignment issue. ( in fact it looks like scaling more than a shift but if I can set some Affine params successfully then I can scale or shift as needed.

However, each of the subsequent strips which need collating in y seem to have a few pixel rows of overlap. It is that which I'm trying to eliminate.

The reason I have to delete some of the crop tiles is that it is presented as a 8 bit greyscale but in fact it is a 24b RGB which is interleaved. That is why I have the three $list variables, so each time I can strip the 2/3 of the tiles which are from the other colour channels. Maybe there is a really l33t way to do all this in one hit but I'm struggling with IM's arcane and inconsistent syntax as it is , I'm not going to try to run before I can walk.

You can only do fx calculations in-line like that in IM 7.

I'm using Fedora which is not really cutting edge releases. If it is a show stopper I may install from source. So am I right in thinking that on IM6 the only way to create variable geometry parameters is to use shell variables as you do in most of your scripts and thus there is no way to use "n" in this calculation without updating to IM7 ?

[fmw42]

My misunderstanding. I guess without an image, I do not fully understand what you are trying to do.

With respect to your fx calculation. Can't you do that ahead of time with a string format and put it into a variable and then use the variable there, if limited to IM 6.

[imaggie]

I guess without an image, I do not fully understand what you are trying to do.

I posted a link to the image yesterday, see above.

It's the Juno Earth fly-by efb12 I'm playing with. They're rather large but if you'd rather have the image ::
http://www.msss.com/junocam_efb/efbimg.html

[imaggie]

With respect to your fx calculation. Can't you do that ahead of time with a string format and put it into a variable and then use the variable there, if limited to IM 6.

Thanks for confirming. I have installed IM 7.0.2

Where can I find the correct syntax for inserting fx into geometry arguments? This still is not being accepted:

Code: Select all

convert  junocam_efb12_roll.png  -crop 1648x128  +repage -delete "$list2,$list3"  -crop 1648x115+'%[fx:n*5]'+13    +repage  -append efb12_collateG.png

convert: invalid argument for option '-crop': 1648x115+%[fx:n*5]+13 @ error/convert.c/ConvertImageCommand/1215.

The following runs without error but it seems that "n" is zero throughout:

Code: Select all

convert  junocam_efb12_roll.png  -crop 1648x128  +repage -delete "$list2,$list3" -crop 1648x115+0+13  +repage -distort AffineProjection 1,0,0,1,'%[fx:n*5]',0 +repage  -append efb12_collateG.png

[snibgo]

"convert" isn't a v7 command, but a legacy v6 command. Try "magick" instead.

[imaggie]

Thanks, I thought the change notes said this was just a name change to avoid clashes but it does have different behaviour.

It's not doing what I expected, but at least it is not faulting and is doing something.

[snibgo]

I'm not sure what you are trying to do, but %n will have the same value for all your images. Perhaps you intended %s. See http://www.imagemagick.org/script/escape.php

[imaggie]

%n number of images in current image sequence

Ah thanks, I had misread that as meaning the number of each of the images in the sequence . It looks like %s is what I intended.

Actually, this looks more like a scaling factor than an offset ( plus there is a change of perspective view point )

Each group of three is concurrent but there is a lag of about 0.4s between image slices. It seems that Juno was going so fast that the distance was changing noticeably between frames. Also the image starts at the equator scans to south pole, a fair gap while it does a complete turn and then north pole comes into view.

This means that the position relative to the earth has turned a little and the limb of the Earth image has changed.
This is quite a challenge to line up using a scripted method. A good exercise is using IM at least.

I think the orbital speed will be slower over Jupiter than the slingshot flyby, so this may be less of a problem. It's quite an eccentric orbit so the scaling may still be needed.

Can you suggest how I can do catmull-rom scaling on each image using %s ?

BTW isn't rather %p which references the different tiles created by -crop ?

%p index of image in current image list

[imaggie]

OK, it looks like the Junocam images are a total waste of time anyway.

I thought they would have put a decent camera on board and we would be getting stunning resolution like the Pluto images. In fact we already have far better images of Jupiter even from up market amateur equipment on the ground.

Seems like Junocam is more of a dashcam for the probe than a proper scientific instrument.

I suppose I should have guessed from the name. NASA playing at "outreach" rather than proper science.

[snibgo]

%s and %p are the same, unless "-scene" has been used, eg:

Code: Select all

convert rose: -crop 10x10 -scene 10 -format "%s " info:

%s here gives numbers from 10 upwards.


I heard a comment for one of the NASA missions that the scientists didn't want a camera, and there wasn't going to be one, but it was added for PR reasons.


For the alignment problem:

If we make slices 0 and 3, open them as layers in Gimp, overlapping them as seems reasonable then changing layers mode to "Difference", zoomed in to 800%, the overlap is black when the match is exact.

There is no offset that yields a black overlap.

The best y-offset is a 14-pixel overlap.

The best x-offset is about 3 pixels on the left side and zero on the right side. So slice number 3 could be widened slightly to match slice number 0.

We can do all this automatically with IM: crop the bottom of slice 0 and the top of slice 3. From the top of 3, crop out a chunk from near the left side and search for that in the bottom of slice 0. This gives the best offset for that position. Similarly, find the best offset for a chunk near the right side.

Then use "-distort affine" with two control points from each image.

Repeat the process, using the previous result with slice 6, then use that with slice 9, and so on.

[imaggie]

I heard a comment for one of the NASA missions that the scientists didn't want a camera, and there wasn't going to be one, but it was added for PR reasons.

Yes, that fits, "outreach" means PR. The camera is little more than dashcam with RGB(IR) filters stuck on. Lamentable. They also use lossy compression before transmission

OK, it remains an interesting learning exercise for IM, just takes the fun out of it.

Thanks for the idea of using GIMP difference. I'm fairly sure that the scaling thing is just changing distance so it needs apply in to x and y. That will leave a different overlap cropping in y.

There is an added problem that the probe is moving quite fast around the earth as the sequence goes on. The top and bottom are not going to match up properly whatever I do.

Then use "-distort affine" with two control points from each image.

I'll have to get more familiar with that.

Thanks for the tips.

[snibgo]

Yes, if you also need to scale y, then you have 4 control points from each image, and would use "-distort perspective". This is the general transformation used when photographing a flat object from different positions, and angling the camera differently.

Cheap cameras (like dashcams) often suffer from barrel distortion. That is easily corrected in IM, but not easily detected. For detection, the Hugin tools can be used, but I don't know if they would work well on these images.

[imaggie]

I would hope at least they put a descent lens on it !

Perspective will not work here, it is not a flat object seen from different angles, it is a different part of a spherical object. There may be a clever transformation which could account for some of that but it will not be a simple 3x3 matrix op.

Also I don't want an "affine" transformation here, I want a Catmull-Rom resizing. Is that possible inside this kind of internal iteration of the IM tiles ?

[snibgo]

I'm not sure what you mean. In IM, Catmull-Rom refers to how pixels are looked-up (interpolated) when new pixels are calculated. "-filter Catrom -resize {whatever}" or "-filter Catrom -distort {whatever}" does that. See http://www.imagemagick.org/script/comma ... php#filter . I know almost nothing about the various "-define" settings for filters.

Perhaps you want Catmull-Rom as a shape interpolation (as opposed to colour interpolation.) No, sadly IM doesn't have that.