[FIXED] Hue filter issue

Solar2D Advanced Graphics
#41

Hi David,

What do your tests reveal on non -highp devices now, when you set the hue angle to nil and not 0? Does it revert the image to its original state? Do you have one to test on? I am again not in the office at the moment so I can’t test this…

Brent

#42

Hi Brent, yes, setting the hue angle to nil on a non-highp device reverts the image to the original state. So I guess that is something. Is there any way to get hue adjustment working on non-highp devices, or am I hoping for too much with this?

Thanks David

#43

Hi David,

Beyond checking for highp devices, I’m not sure what more our engineers can do on this filter. The hue filter should work consistently on highp devices now, but for low-end devices without GPUs that support it, I’m not sure there are any guarantees that could be realistically made. I understand that for 99.9% of app users, they don’t know (and don’t care) about such things as “high precision fragment shaders”, and they just want the app to work. However, the Android world is a little like the “wild west” and there are hundreds upon hundreds of devices out there, all with different GPUs and overall processors. I imagine that many low-end or older devices experience these kind of issues, but perhaps moreso with apps that focus on proper color usage and so forth.

I suppose one option, if you could gather screenshots from users who are having issues on non-highp devices, is to determine if there is any consistency whatsoever between their hue shifts. For example, if you can confirm that devices A, B, and C (all of them non-highp) shift the hue 20% further toward green, you could perhaps offset your hue filters to reverse-compensate for that only on non-highp devices (just add or subtract from your angle settings). However, if device A is swinging wildly toward green, and device B is swinging wildly toward purple, then it’s probably impossible to compensate with any accuracy.

Anyway, sorry I can’t be of more help, but I think it’s something that just can’t be overcome on various devices.

Brent

#44

Any further updates on this issue? The bug (Case 35892) was filed over 6 weeks ago?

Thanks

David

#45

I have been more than patient on this issue - I posted the  bug (Case 35892) 10 weeks ago - I joined the discussion here http://forums.coronalabs.com/topic/52957-getting-odd-results-with-filterhue/?hl=filter

where another user was having problems with it.

I added a check for system.getInfo( “gpuSupportsHighPrecisionFragmentShaders” ) so the hue filter is only available on supported devices (which blocked it on 1st gen Nexus 7, although users will complain why they don’t get the hue feature)

I was just about to submit the update to app store - thought I would try on iphone4 to do a final test, and it PASSES the test above, but setting the hue to 0 makes the image have a hue adjustment, which makes a photo app useless to a user with an iphone4.

Could I PLEASE have someone from engineering look at this and tell me what can be done?

David

#46

Hi David,

I’ve once again urged the engineers to look into this a.s.a.p. Sorry for the lack of action on this… I’ll keep you posted.

Thanks,

Brent

#47

Thanks Brent.

At this point we are using that check on android, and are going to have to restrict to iOS8+ on apple devices (to ensure user has 4S or above).

Not a great solution, but if engineering fix it, we can remove those restrictions.

David

#48

Hi David,

Does the issue mostly occur when the angle is set to 0? Or any angle?

Brent

#49

Hi Brent,

0 or any angle (on 1st gen Nexus) it is as if it is offset. An orange image with angle 0 (or 360) will appear green.

David

#50

Hi David,

Just to be 100% clear, any angle? So like 90, 180, 172, or anything? Not just 0 or 360?

Brent

#51

Yep, any angle is wrong. I set it up with a slider to adjust the angle (I was thinking of getting the user to do an initial adjustment on platform), and on the Nexus 1st gen, to get the orange image back to “orange”, it required it to be set to about 57. But, the image didn’t quite look right (the color wasn’t exactly the same). ie it wasn’t the same as setting to 0 on another device/simulator.

Hope that helps,

David

#52

Can you add this line to your config.lua:

shaderPrecision = “highp”,

This tells your app to use high precision calculations which apparently the hue filter needs.  I’ve tested it on my Kindle Fire Gen 1 and my Nexus 7 Gen 1 and the FilterViewer for Hue now matches the simulator.  This is a short term fix because it’s causing any other shaders to use more math than needed.  Engineering will get this fixed in an upcoming daily build, but for now, this should work around the issue.

Rob

#53

Hi Brent,

So I saw that there was a note in release 2522 about this being enabled for hue only.

Tested on Nexus 7 1st gen and another low end android tab that it didn’t work on before. And if you set hue angle to 0 it does indeed match the original image.

BUT! If I try to adjust the hue after that (for instance on a slider as the basic example code below shows), then it doesn’t update. Tried same build on a Nexus 2nd gen  and it updates correctly on changing the hue angle.

So we are close, but not quite there. Could you ask engineering to try adjusting the hue value after creation and see if they can repro the issue?

local widget = require( "widget" ) local snapshot1 = display.newSnapshot(400,400) snapshot1.x = 200 local base = display.newImageRect ("Icon@2x.png",200,200) base.x = 50 base.y = 50 local test = display.newImageRect ("Icon@2x.png",200,200) test.y = 100 snapshot1.group:insert(test) test.fill.effect = "filter.hue" test.fill.effect.angle = 0 local myText = display.newText( "0", 100, 350, native.systemFont, 16 ) -- Slider listener local function sliderListener( event ) print( "Slider at " .. event.value .. "%" ) test.fill.effect.angle = event.value myText.text = event.value snapshot1:invalidate() end -- Create the widget local slider = widget.newSlider { top = 400, left = 50, width = 400, value = 0, -- Start slider at 10% (optional) listener = sliderListener }

David

#54

Hi David,

This might be a snapshot issue, not a hue filter issue. What happens if you try this code on the test image but don’t involve any of the snapshot stuff?

Brent

#55

Hi Brent, tried without the snapshot as well, and no different.

That code works fine on 2nd gen Nexus, so not sure how the hue could now be set, but not able to be changed.

Did you try that code on your nexus 7 gen 1?

David

#56

Hi David,

I’m not in the office at the moment so I don’t have an older device to test on. In any case, does merely setting the value to (say) 50 now work, or not work, on the 1st-gen Nexus? Meaning, simplifying this without the slider code, what happens when you set angles? Do different devices now basically sync in hue behavior or not?

Did you remove the “highp” thing from your config.lua once you upgraded to 2522?

Thanks,

Brent

#57

Hi Brent, on further investigation, setting the angle to 50 or 90 results in the same as setting it to 0. Which is probably why the slider doesn’t do anything. It would appear that setting it to anything on Nexus 7 1st gen results in a hue of 0.

Can you confirm when you are in again and pass back to engineering?

David

#58

And yea, I didn’t use that config.lua call - this is all in straight 2522

#59

Does the 1st-gen Nexus even support high-precision shaders? Please try this…

[lua]

print( system.getInfo( “gpuSupportsHighPrecisionFragmentShaders” ) )

[/lua]

#60

That call does return false. So does that mean hue is unsupported? If so, what fix did engineering do so that setting hue to 0 worked?

Thanks

David