Moho Forum

1024 x 576 doesn't divide into a whole number. This would cause a rounding error when determining out put size at render time if AS can't go to enough decimal places.


1024 x 576 is 1.7777777778... well... that's what my calculator says which would mean it is probably an "infinite" value. Since AS doesn't use pixels there would be no possible way to out put that image accurately... ever ever ever ever... in my humble opinion. Probably no image could be out put "exactly" based on that. AS would have to modified to use "pixels" somehow in certain situations.

Look in the AS file format for the image layer. You will see:
"shape" is the "size" of the image layer. It is not in pixels. That is the "ration" of the out put size.

-vern

More stuff...

If you render out to a PSD without antialiasing and open the result there is one pixel offset on the left of the layer. The layer is 1 pixel short.

EDIT: The above is a mistake on my part. I had "shifted" the layer slightly. Still there appears to be rounding errors when a layer is at 100%.

I have to STRONGLY agree with Rhoel now. It doesn't matter if I haven't encountered this problem... he is right. This IS a very big problem. I don't see an easy solution. I hope SM does listen.

Rhoel, I will send them an email about this as well with my "discoveries" but I would guess that Mike is probably more familiar with it than any one else.

-vern

I got a "perfect" render out... but... I'm not sure exactly what is going on. A couple of things, I had to render WITHOUT antialiasing. I also "squetched" the original png file to 1023 x 580

EDIT
I changed the CANVAS size after I set up the file with the original image... I don't know if this had an effect or not. Also 2 pixels are being cut off the top and bottom... not a big problem if you ask me.

EDIT: False alarm. Still a 1 pixel "blur" vertically. I think there is a sweet spot somewhere involving project size and image size to fix this though.





-vern

Smith Micro have responded with the message saying this is eFrontiers technical support as SM do not provide support for AS. WTF? Did SM buy the product or not?

Whatever, eFrontier have now been informed.

Playing with the file code is an interesting idea, one I will look at tomorrow - its nearly 02:30 here and I should be tucked up in bed.

(And people wonder why I don't have a wife )


Rhoel

Just played with the file interior - there is nothing there that will give us back the missing image edge. If you scale the image layer, you will see the right/bottom edge is actually missing. Nothing in the file settings can be changed or fudged to give you that back.

As for the renderer, I cannot see anything anywhere except in the source code where this can be fixed. Scripting a new value into the MohoDoc relevant channel might work, its seems to be a AninVal3 (? its late and I'm too lazy to look in the file).

I'll leave this with eF and MC - they are the ones to pick up the baton and run with it: Hopefully, they will come back and at least say they are looking at it.

At least we will know the ticket is officially open.


Rhoel

I've continued testing. The best I can get is the example above with a 1 pixel "blur" upwards on the vertical.

Animating the layer does not change the image (this is good). It is the same 1 pixel offset.

Changing the project size settings will effect this, but I can't figure out exactly how. I think you are right Rhoel, this 1 pixel is it. There is no way to fix it with image sizing or scaling. Whatever changes are made always end up with 1 pixel up, down, left or right.

I'm done now with my experiments. I even set up a file with step keys for scaling and changed the layer scale by .001 on the x and y on like 20 frames with no solution. They all had similar 1 pixel offsets.

-vern

After some failed attempts at getting a ticket open at Smith Micro/eFrontier, I eventually rang them tonight (09:00 morning California) and spoke to Customer service (after being routed to two different voice mails "We'll ring you back" - to Cambodia?). Perseverance prevailed.

They are now aware of this issue/s and are passing it to tech support at e-frontier for them to look at. Hopefully Mike will get a cc of the mails too.

I also raised the observation that this forum seems to have been neglected by Smith Micro, that we were/are not hearing of new releases/books being published etc. I suggested customer service might want to mention this to the Suits, to see is we can have the equivalent of a Fahim to drop by occasionally and give us any helpful news about the product.

Hopefully, I'll have some kind of response on both points sometime over the next day or so.

Fingers crossed.

Rhoel

Hi guys,

I just found out about this thread, sorry I'm late. I'm looking into it now, and I expect to post a detailed repsonse later tonight.

-Mike

Rhoel wrote:Digital theory is you can import a 100 x 100 image, save it out and the result will be 100 x 100. every pixel will line up with the original.

That's true for compositing and editing programs that have a pixel-for-pixel correlation between source and output images.

However, 2D and 3D drawing packages have to position an element in their "3D space", and the final image is a sampling of the internal 3D world.

In the same way that you wouldn't expect to be able to map a 100x100 bitmap on a 3D object and expect every pixel to map to the 100x100 output image.

Also, I would imagine that the slight blur works better for movement, which is what animation programs are for.

I'm not concerned about this at all. If I want pixel-perfect images, I'll use a compositing program.

If Mike can make it work perfectly, great, but I wouldn't expect that behaviour from AS.

The400th wrote:However, 2D and 3D drawing packages have to position an element in their "3D space", and the final image is a sampling of the internal 3D world.

I understand the point you are making, and certainly true of 3D space.

But if the bitmap is at 0,0,0 equivalent on the XYZ plane, ie, 1:1. it should render fair. It certainly should not be image clipping, removing one row of pixels from both vertical and horizontal. Because if you are making a 100 pixel image from 99, aliasing will occur. That is what we believe is happening, not a Z plane offset.

I am happy Mike is looking at this and look forward to his comments. I don't envy him; he wrote this section of code a long time ago and for any programmer, revisiting old sections of code is a headache, trying to remember how or why line 8937 is using A==B.

Not fun.

Been there, got the t-shirt and ripped it to shreds in a fit of frustration.

As more of us move into HS and 2K, we are going to need all the resolution we can get. That will require an arsenal of different tool. I am hoping that we will get a special topic area for HS and Hi-resolution as there are some interesting questions/answers/experiences which can be fed back to other users.

Rhoel

Sorry, I uploaded some sample images, and then lost my internet connection at home. Anyway, here's what's going on. By the way, The400th basically got the answer right - but here's some more detail.

First of all, I want to make it clear what we're talking about here. I don't want new users to think the image is totally blurry. Rhoel's initial post showed an image blown up 1200%. Here's what we're really talking about. Below is an image at 640x480 pixels, with some one-pixel-wide lines on it:



And here's what you get if you create a 640x480 project in Anime Studio, import that image, and render it out:



The blur is quite slight, and to me the image looks slightly darker, rather than blurred. Keep in mind that this is a very high-contrast image, with very fine details. If your target was TV broadcast, a one-pixel line isn't going to come through anyway.

Here's a comparison of the two images at 600%:



Also, although Rhoel has been using Anime Studio for years I think, he just noticed this now. Please don't take that as an excuse - I don't mean to brush off your concerns, I just want to put this in perspective. For most real-life images, I don't think this will be a huge quality issue.

OK, now here's the reason why it's happening. As The400th pointed out, Anime Studio, although it's a "2d animation program", is really a 3D tool. Every layer, plus the camera live in a 3D space. An image you import is initially positioned directly in front of the camera so that it looks like it's flat on the canvas, but it's really floating in 3D space.

What this means is, to render a scene, the pixels of an image need to be resampled into the final output image. Resampling is bound to introduce errors. However, I'm about to make an argument that these aren't necessarily errors.

Take the following example:

http://www.lostmarble.com/misc/ImageSam ... egrees.mov

I took that image an rotated it slowly by 6 degrees in Anime Studio. The result looks pretty good. At every frame of the animation, except when the image is rotated 0 degrees, the image will have to be resampled. That's a fact of life: even if we could preserve the pixels exactly at 0 degrees rotation, it's impossible when you start rotating.

So let's say we did something special and preserved the pixels exactly at 0 degrees. Here's what you'd get:

http://www.lostmarble.com/misc/ImageSam ... rees_2.mov

The change is subtle. Use the timeline scrubber in the QuickTime player to look at the first couple of frames. Notice how the first frame is exactly perfect, but none of the other frames are. What you get is a slight "pop" when you go from that perfect frame to the resampled frames.

Here's a blown up view:



On the left is Anime Studio's rendering at 0 degrees. In the middle it's at 6 degrees, and at the right is the original image.

I'd say that although the right image is "perfect" compared to the original, it looks out of place compared to the rotated image. Since Anime Studio is, after all, an animation program, we have to assume that most image will move at some point. And movement implies resampling. So if you sometimes show a perfect original copy, and sometimes a resampled image, I'd argue that that's not really a desired result.

Back to the real world, I'd suggest not using harsh one-pixel lines anyway. If you're going to broadcast on TV, it won't look right. And even if you're going to stay on the computer, you'll probably be going out to a compressed format sooner or later that won't deal well with such abrupt edges.

By the way, I tried this in AfterEffects too. At 0 degrees rotation, they do produce a perfect copy of the input. However, if you do a slight rotation like I did, and resampling happens, I found that AfterEffects "pops" a little bit going in and out of a "perfect" keyframe at 0 degrees. So although that one frame does look more true to the original, for animation purposes I'm not convinced it's the right thing to do.

Having said all this, if it's still a big issue, we could consider adding a "background image" that doesn't behave like a normal image layer. Maybe it can't move at all, but would copied exactly to the output image behind everything else.

-Mike

I see your point Mike but...

Resampling is found in the following, resized, antialiasing and rotation.

But when you export a single still frame as an image with no antialiasing, no resampling should be done.

I must add that this issue doesn't effect me but just wanted to add my two cents.

I have to agree with Mike's explanation. I never had problems with the rendered image layer out put although I had to agree with Rhoel based on what I saw with my own eyes in my testing. Your explanation does put a new light on it though. It makes sense.

Having said that, I would still like to point out one thing. The image/movie layer feature in AS gives it the feel and capabilities of a non linear video editing tool. Being able to composite video or images on a "special" background layer without worrying about blurring or generational loss of quality would definately be a very good thing to have.

You can easily stitch together rendered out put from AS and rerender to a new movie file. I have done this many times... er... and also never noticed any visible degradation of quality... but still, to make the fullest use of that capability and possibly promote it as a "bonus" feature you would want the renders to be "precise". I wonder too if image animation export would be "faster" if the program wasn't "mucking" around with it in those very special cases?

However... it isn't at the top of my wish list. I would put it at a 12 or 15 out of 20 on my list of needed things in AS... maybe even a 17.

Thanks Mike for clearing this up.

I look forward to Rhoel's response. I sort of am "half way" supporting you Rhoel. Kind of.

-vern

Hi Mike,

Thanks for the feedback and explanation on the function of the 3D space.

It is interesting your tests in AE also showed 1:1 true renders of the original. I did my tests in Combustion - I think both programs use the z channel, though whether this is the same principle/implementation the AS 3Dspace, I do not know. The question is whether re-sampling at the 100% 1:1 is desirable or not: Vern also questions this: My thoughts are 1;1 shouldn't re-scale. That has to be balanced with what happens at 100.1% rescaling. Is the resulting difference (pop) so great as to make the end result unacceptable.

The answer to that is an open question. Programs like Combustion have found solutions to that, often by using very high floating numbers: That can adversely affect the render times. Finding the balance is the debate.

I think in some situations, the current loss of resolution and colour intensity is an issue: I have seen this error in the past and blamed what I was seeing on the non-broadcast monitors they had in the Thailand studio - clearly, there are some situations where it shows. The only way to describe it is if you have worked with a broadcast monitor - you will understand the difference viewing a component video feed then viewing the same source via the composite video feed. The results are identical to what we are seeing in these tests.

What is key here might be the downstream compression factor used in broadcasting. The general rule is to avoid any degrading of the image since the compound effect is exacerbated. That is, you want to avoid degrading an already degraded image: The less errors the better. It is an important consideration.

I must be honest and say I do have one nagging doubt; it is an issue not addressed, the missing pixel rows. My concern is, if you are using a 99 pixel row as the source for a 100 pixel output, then you will always get a re-sampling error, with its accompanying lowered contrast/colour bleeding/anti-aliased.

So for me, two questions remain.

1: Why is the bitmap layer having the right edge and bottom pixel rows stripped of. Is this a layer error, a workspace display error or resampling error? Bitmap really should not be cropped in a layer. If its a scaling error, then it is a big issue.

2: What is the cause of the jitter on Slow-track outs on bitmaps? Its a difficult error to create but when it occurs, the resulting mismatch of one vectored layer stable, the other bitmap jittering, is unbroadcastable. That remains an issue and a bug of long standing. One suggestion points to a rounding function somewhere in the floating point calculation - such 1 pixel pops left and right would explain such averaging. True floating point would produce less re-sampling errors.

The suggestion of a special bitmap layer is a valid one and a workaround if the about points are not 'bugs'. Having true 1:1 renders is valuable in some instances. In the past I have had to sample video from digibeta, add a vector layer then cut it back into the master tape. If I was to do this with AS as is, there would be a colour/contrast pop. Currently, I would composite in Combustion so problem avoided. Similarly, in Animo, Maya and NLE programs, I have exported a frame, then re-imported it back into the program, to make a seamless cut between effects/scene extensions etc. In that scenario, there is no choice but to have an identical copy.

I also accept your point that the error is not as bad/so noticeable on an average scene - the tests I did at 2k/4k showed the re-sampling error to be much less noticeable due to the increased sizes (because the bitmap images are bigger and the % error smaller). But on 176*220 mobile content, the backgrounds looked soft and lifeless: Since AS is ideally suited to mobile content generation, the new Background layer will be much appreciated by some since mobile dispalya have to be sharp and contrasty.

Perhaps the ideal solution would be to a "normal" layer with a tick option akin to the "immune to camera movements", one which forces the renderer to paint behind.



Footnote:
Mike hit on a point which I want to reinforce - I have been using with Moho and Anime Studio/Anime Studio Pro 5 for a very long time. I wouldn't have been using it for a very long time if I didn't think it was a good program, able to deliver the goods. I happen to think what Mike has achieved is astonished, especially when you consider the size of his programing 'team'. AS is an exceptional tool.

I have made harsh words about the Suits, those acquisitions companies who see the profit, not the product, the users or the community they are supplying. I am full aware I seriously ruffled the feathers of at least one person in Smith Micro, something needed to be done. I think Mike has had a very bad deal from the Suits, one which has held back the technical position pf the program: The resulting situation has seen the product jump in price fourfold without and major upgrade in performance. All that money has gone into corporate pockets, not into Mike's. The resulting games between eFrontier and Smith Micro have slowed development, something which is less than ideal. Currently, the internal mess at Smith Micro is astonishing, with SM declaring in emails "we don't support Anime Studio". Lessons learned from the open source community have shown development accelerates when the Suits are not involved. There continues to be strong case for AS to be an open source project.

But like many people who are passionate about something, making it better or the best can confuse those on the sidelines. Yes there is a layer clipping problem which may or may not introduce or contribute to the rescaling error. If that is the case and it can be bettered, it will benefit everyone. If it can't and the compromise between 100% and 100.1% rendering overrides pure 1:1 rendering, then all users will know we have looked damn hard at the problem and found the best solution.

What we are discussing here is beyond the experience of most users. I started playing with animation cameras in 1970, and have earned a reputation of taking tools to the limits. Typically, our team at Universal were/are the only people to have successfully achieve front projection on an Oxberry AN35 camera, something thought physically impossible. I like taking things to the edge because that is where interesting things are found. It also means you often find the limitations of the system, ie, you break it. Currently my testing is how to make AS work with Real-D - totally insane but technically worth doing: The maths would give Einstein a brain-ache and I'm not Einstein, the formulas are tough

What is important is the outcome of such discussions and testing benefits everyone. The product gets better.

I look forward to Mike's comments of the layer clipping.


Rhoel.

Rhoel wrote:There continues to be strong case for AS to be an open source project.

Let's see how SynFig does before throwing the baby out with the bathwater, eh?

I'd rather AS became a Photoshop than a Gimp, an Animation Master than a Blender, an Illustrator than an Inkscape.