Getting rid of low alpha rounding errors? Baking shaders?

I’m slowly fading a bitmap image by drawing a very faint (low alpha) rectangle over it every frame. At lower alphas there remains an echo of the old image (it doesn’t fade to full black) which I know is due to rounding errors.

I think it should be possible to smoothly fade using a shader but I need to save the changes to the bitmap itself, as it should continuously fade out while I draw new stuff on top.

So I’m wondering if it’s possible to save or bake a shaders modifications back to an image?

@Kirl Not sure what problems you’re running into fading an image. Here an example that fades a sprite without any problems. A bitmap image shouldn’t be any different. There aren’t any rounding error because val is an integer. Even if I make val a number so it uses floating point, there still isn’t a problem.

function setup()
    rectMode(CENTER)
    parameter.integer("val",0,255,0)
end

function draw()
    background(255)
    sprite("Planet Cute:Character Horn Girl",WIDTH/2,HEIGHT/2)
    sprite("Planet Cute:Character Cat Girl",WIDTH/2,HEIGHT/2+100)
    sprite("Planet Cute:Character Princess Girl",WIDTH/2,HEIGHT/2-100)
    fill(255,255,255,val)
    rect(WIDTH/2,HEIGHT/2,200,400)  
    fill(255,0,0)  
    text("Move the slider to fade the images",WIDTH/2,HEIGHT-100)
end

Hi dave, here’s an example of my problem.


function setup()
    parameter.number("fadeStr", 0, 20, 8)
    bmp = image(WIDTH,HEIGHT)
end

function draw()
    strokeWidth(10)

    setContext(bmp)
    fill(0, fadeStr)
    rect(0,0, WIDTH, HEIGHT)

    ct = CurrentTouch
    if ct.state ~= ENDED then
        line(ct.x, ct.y, ct.x-ct.deltaX, ct.y-ct.deltaY)
    end
    setContext()
    sprite(bmp, WIDTH/2, HEIGHT/2)
end


@Kirl You might need background(0) in draw or else all of the previous draws will remain.

@Kirl We’re running the same code, so what version of iOS and Codea and type of iPad are you using. I’m on an iPad Air, iOS 11.0.2 and Codea 2.5.1 (97) .

That’s weird, here’s what I get with a fade value of 8 as in my example code, this is as far as it’ll fade. Higher values (even up to 50) fade to a fainter echo but still clearly visible.

PS Codea appears to crash if I try to save the inbuilt screenshot function, so I used the ipads screenshot function (pressing power and home button simultaneously).

Ah sorry, just touch the screen to draw some lines and fiddle with the fadeStr parameter. Default fadeStr value should demonstrate the problem though.

I want to slowly fade out whatever is drawn to the image. But if I fade too slowly (lower alpha) the image never fades to full black, you will see a faint shadow of whatever was drawn remaining.

You can get rid of the echo/shadow by increasing the fadestr/alpha over a certain threshhold, but this will increase the fade speed…

I want a super slow fading to full black (or white or whatever the bg color may be). I probably should have faded to white to make it more apparant.

@Kirl I noticed that if the value is above 1, if fades all the way and if it’s below 1, it doesn’t fade. My suggestion is to make the minimum value a 1 so it always fades. Apparently any value below 1 is treated as 0 and never fades. Any value above 1 fades to black for me. I don’t see any faint shadows.

@Kirl Are you running the code you show above. In your image, I see a white background with a grey line. When I run your code above, I have a black background. If I set the value to 1, it fades to complete black. If I set it at .99, it doesn’t fade at all. See the images below with a value of 1 and .99 .

It’s the same code but I switched black and white to make it more apparant as I mentioned in one of my replies, sorry for the confusion. These are my results with the original colors, one with fadeStr=8 and fadeStr=1.

I also found a processing thread & stackoverflow question about the same problem (https://processing.org/discourse/beta/num_1138703939.html, https://stackoverflow.com/questions/22317685/why-does-the-processing-fill-with-alpha-never-completely-fill), but those solutions don’t work for me as I need a continuous fading of the screen.

I don’t have a destination where I stop fading, it’s supposed to continuously fade the screen/image.

I dread that question because I’m never quite sure. So after the necessary searching I found this.

Acording to the web ipad model A1566 is an iPad Air 2 (Wi-Fi Only). AFAICT all the latest updates for codea and ios (that is there are no new updates).

ios 11.0.3 (15A432)
Codea 2.5 (90)

I should probably mention that this is not a new problem for me, in fact I’ve been running into it from time to time for years. I think I even got this back with javascript and actionscript, but I’m not sure. I do know it’s a familiar problem to me and old enough that I don’t even remember when I first ran into it… =)

@Kirl Your ipad is newer than mine, your iOS is newer than mine and the Codea release probably doesn’t matter. I tried your code on my iPad Pro and guess what, I’m seeing exactly what you’re seeing. It isn’t fading to black, but a grey trail remains. I’ll look at what’s happening on both iPad, maybe I’ll see what the problem is.

@Simeon Do you know why the above program by @Kirl fades to black on my iPad Air but leaves a ghost image on my iPad Pro and his iPad Air 2. On my iPad Air, a value of 1 will eventually fade to total black.

I don’t know if this is helpful, but another way to fade things out is by using the tint() function. If you set the tint’s r g and b to 255, you can use the alpha value to set transparency. Set the tint, with the alpha value you want, just before you draw a sprite, and it will be drawn as transparent as you like.

Since you say you’ve seen the same problem in many different languages and contexts, this may not change anything. But who knows, it might. Maybe worth a try.

@UberGoober This seems to be a device problem. The above code works perfectly on my iPad Air, but shows the ghost trail on my iPad Pro. Using tint is another way to go, but it looks like there’s a problem that the above code is showing.

I seem to remember it’s a rounding error, this was also explained in one of the threads I linked above. The explanation sounds reasonable enough though I’m not sure where the rounding gets done, but I suppose somewhere in the cpu…

[edit]
Here’s a list of apple devices and their stats: https://en.m.wikipedia.org/wiki/List_of_iOS_devices.

WARNING, potentially unrelated technobabble!
The 2nd gen pro has a 2.39 GHz hexa-core while the air2 has a 1.5 GHz triple-core.

@Kirl Both of my devices are 64 bit. As for rounding, I entered a starting value of 1on both devices so there wasn’t a rounding error there.

@dave1707 a nice bit far from my knowledge set, but could iPad Air/iPad Pro differences be a matter of the contrast or color-detection settings on one or both of the devices? I remember reading somewhere that the iPad Pro had the ability to dynamically color-correct its display based on its environment’s lighting conditions.

@UberGoober I don’t know why the difference. I’m sure @Simeon will tell us.

Just a bump post. I had yet another run in with this again. It’s such an annoying and persistent problem, it keeps plaguing my projects for many years now.

It’s especially puzzling as dave’s older ipad air2 doesn’t seem to have this problem. Though this might also be a clue to it’s solution, if indeed there is any…