[FIXED] Hue filter issue

Solar2D Advanced Graphics
#21

Posted Bug (Case 35892) for this.

Easiest reproducable case is to load an image, set hue filter to it and set the hue angle to 0.

On Nexus 4,5, 2nd gen 7 and iphone ipad etc works as expected (image looks “normal”)

On Nexus 1st gen the image has a hue adjustment to it.

Not sure how many other devices would be affected, but assuming it would not just be isolated to Nexus7 1st Gen.

#22

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

Thanks

David

#23

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

#24

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

#25

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

#26

Hi David,

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

Brent

#27

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

#28

Hi David,

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

Brent

#29

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

#30

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

#31

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

#32

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

#33

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

#34

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

#35

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

#36

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

#37

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

[lua]

print( system.getInfo( “gpuSupportsHighPrecisionFragmentShaders” ) )

[/lua]

#38

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

#39

Hi David,

The hue filter was modified to always use high precision, which should result in the expected output. From my understanding, the only negative impact is that the shader performance will be slower on devices that do not provide hardware accelerated high precision floats, but it’s possible that the hue values will not be what you expect on devices that do not support high precision (thus, an issue with OpenGL and that particular GPU).

As for setting the angle to 0, what is your intention with that? To restore the image to it’s non-filtered (original) state? If so, why not just set the fill.effect to nil instead of 0? That should remove the filter entirely, thus showing the original untouched image.

Take care,

Brent

#40

Thanks Brent, I guess the goal here for us was to get the hue to work on all the devices we have found it doesn’t work on. We have a photo layering blending app out ( https://play.google.com/store/apps/details?id=com.playthisstudios.Meld&hl=en ) which is doing well, and getting good reviews. The hue adjustment feature is one we have wanted to add, but it is tricky if it doesn’t work on some devices. Customers don’t understand or care about the technical restrictions, they will just one star it and move on.

So we were hoping that this thread would result in a solution that would allow hue to work on those devices. As it stands now, we have released a version on android and iOS, testing for the HPSF, and if not available, make the hue option not visible to the user. But as you can imagine, users want it, irrespective of their device (of which some are quite recent and don’t work)

So hope that clears up what we are trying to do!

Thanks again, David