Unable to flip / rotate webcam image

[johnwfmak]

I have flip the camera image on OctoPi, but when access via Polar Cloud I don't see options to flip / mirror / rotate the camera image.

[dnewman-polar3d]

Plugin is expected to flip them before sending to cloud. It also tells cloud if the live camera feed needs to be flipped by browser.

Sent from a pay phone

On Jul 2, 2017, at 11:19 AM, johnwfmak notifications@github.com wrote:

I have flip the camera image on OctoPi, but when access via Polar Cloud I don't see options to flip / mirror / rotate the camera image.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[johnwfmak]

My OctoPrint is setup to Flip, I don't see any other settings in the Polar Cloud plugin

[dnewman-polar3d]

Reason to flip before uploading to cloud (S3) is simple: different services may be given access (by you). They often cannot flip the image or even be told they need to. For example, if you use IFTTT.

Sent from a pay phone

On Jul 2, 2017, at 11:25 AM, dnewman-polar3d notifications@github.com wrote:

Plugin is expected to flip them before sending to cloud. It also tells cloud if the live camera feed needs to be flipped by browser.

Sent from a pay phone

On Jul 2, 2017, at 11:19 AM, johnwfmak notifications@github.com wrote:

I have flip the camera image on OctoPi, but when access via Polar Cloud I don't see options to flip / mirror / rotate the camera image.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dnewman-polar3d]

@johnwfmak The plugin should be reading the setting from Octoprint itself. Hence why there's no setting. Or more likely, this is an oversight in the plugin -- a detail it wasn't aware that it needed to do. Now it is so I'm sure it will be added in a day or two.

[markwal]

@dnewman-polar3d OK. I've got a branch with the snapshot flipped and rotated according to the OctoPrint setting. However, I've got a mapping problem for the stream. Polar Cloud only does rotate 180 degrees (rotateImg = 1) as far as I see in the docs. OctoPrint does: flipH, flipV and rotate90.

[dnewman-polar3d]

So there is no correspondence? That's odd. Does octoprint actually have people viewing reflected images with the cameras?

flipH, if the term is used normally, is a reversal (mirror/reflection across a horizontal axis), flipV (aka, "flop") is a mirroring across a vertical axis, and rotate90 is rotate 90 degrees counter clockwise. But none of those is rotate 180 degrees. So presently there's no correspondence between what the Polar Cloud has and what Octoprint has.

I doubt there'll be any room for a full correspondence then since web browsers generally cannot do anything other than rotate the image. I'll have to ask Marcus... doing a rotate 90, 180, and 270 may be feasible but the reflections (flipH and flipV) won't be.

[markwal]

It's historical I think. Originally just flips and later rotate90. It's all done via CSS in the browser. The rotate was actually the late comer in IE IIRC. Not that it matters actually since I think neither IE nor Edge display an mjpg-stream anyway.

[dnewman-polar3d]

But is flipH truly a horizontal reflection? And flipV truly a vertical reflection? Or did someone simply pick those names while the CSS is actually just rotating +90, -90, and +180?

[markwal]

No. They're reflection. The current Polar Cloud rotate corresponds to flipH+flipV (both off and both on are the only ones that correspond to actual rotation). So folks can also compensate for flipped input webcams, I suppose (do such things exist?). I was kinda guessing it was done this way earlier just because that was the CSS that was easily available/quick. I think I added the rotate90 later.

https://github.com/foosel/OctoPrint/blob/b55c4ef5ca5b96ec4274bf8ebe3ca51439003128/src/octoprint/static/less/octoprint.less#L1098-L1123

[dnewman-polar3d]

Well, the rotate 180 is pretty common: just mount the web cam upside down for example. Only way I can see to possibly do flipV or flipH in CSS would be scaleX(-1) and scaleY(-1). I believe that's browser dependent though....

img {
        -moz-transform: scaleX(-1);
        -o-transform: scaleX(-1);
        -webkit-transform: scaleX(-1);
        transform: scaleX(-1);
        filter: FlipH;
        -ms-filter: "FlipH";
 }

[dnewman-polar3d]

For Polar Cloud, I suppose we can have a bitmask?

bit	value	octoprint field	description
0	1	rotate90	rotate ccw by 90 degrees
1	2	flipH	reflection about the horizontal midline
2	4	flipV	reflection about the vertical midline

A rotate 180 would then have the bitmask 0b0110 (0x06). A rotation 90 clockwise would be 0b0111 (0x07).

Make sense? Any errors on my part? Not too sure how ugly this will be in the CSS.

Does Octoprint only do

value	octoprint field
0b000	nothing
0b001	rotate90
0b010	flipH
0b100	flipV

or can it specify combinations?

[markwal]

Yeah, that's what OP does (in the link above). Maybe it makes more sense in the protocol to do 0, 90, 180, 270 and then I'll map 4 of the 8 states onto that. And then we see whether anybody actually needs the other 4? For the moment, I could map onto the two we have (ie rotate 180 = (flipV && !rotate90)). That would actually be correct in one case and closer in the other (not mirrored) and perhaps that other case isn't in use.

[markwal]

Our replies crossed, so I'm one behind. OP allows all eight states. Two divs one inside the other. The outside div is rotate90 or not. The inside div is the two flips. That way the rotate is always done last.

[dnewman-polar3d]

Looks like OP's rotate90 is rotate clockwise 90? I don't know which way CSS actually interprets -90 but I see that OP's rotate90 is using -90 degrees.

[dnewman-polar3d]

Apparently these days you can rotate and scale on a single div. So Marcus feels this will be straightforward to add. May be a few weeks as we have some other high priority items on our plate. (Octoprint in general is HIGH PRIORITY. Just the camera rotation is, relatively, lower priority.)

So, is OP's rotate90 a clockwise (cw) or counter clockwise (ccw; widdershins) rotation?

[dnewman-polar3d]

... and since there's a couple of other groups implementing the protocol, I'll probably need to make a rotateImgExt and leave the old rotateImg as merely meaning a 180 degree rotation (which I expect is what 85% of people need... camera upside down).

[markwal]

I believe op rotate90 is CCW, counter clockwise. I just tried it out and that's what it looked like, unless my head is widdershins today which sometimes happens. ☺️

[dnewman-polar3d]

Thanks. Then since this is 2D and thus flipH and flipV will be commutative, I think we can go with the bitmask with the stipulation that rotate90 is always applied last. [flipH(rotate90(x)) != rotate90(flipH(x))]

[dnewman-polar3d]

FWIW, here's what I'm implementing in the cloud

bit	value	operation	description
0	1	reflect-H	reflection about the horizontal midline
1	2	reflect-V	reflection about the vertical midline
2	4	rotate-90	rotate counter clockwise by 90 degrees

The "rotate-90" operation will always be applied last.

And yes, I've changed names. Being a family full of mathematicians I did a sampling. No one liked "flipV" and "flipH" both because they obscure the underlying operation (a reflection) and their ambiguity. (Mind you, reflect-H and reflect-V have a similar ambiguity but their names at least reflect the underlying operation. Pun intended.)

The field in the procotol is named transformImg and it takes precedence over rotateImg.

[markwal]

Current version (0.2.0) will do 180 rotation of the video stream if "flip vertically is set". For saved snapshots as well as snapshot viewing, the transform should work in all eight states.

Future version will also do the transforms in the video stream.

[dnewman-polar3d]

Current version 0.2.0 is sending incorrect rotateImg value. It's sending false when it should send 0. I'm going to assume it also sends true when it should send 1.

[dnewman-polar3d]

... 0 and 1 as in the integers 0 and 1. Not the strings "0" and "1".