• State Not Answered
  • Replies 12 replies
  • Subscribers 17 subscribers
  • Views 645 views
  • Users 0 members are here
Options
Related

EdgeMTB Display Value Understanding

crispgarmin

Hey (again),

I've had some end-user feedback that the image I get from a web request (PNG) display received on the EdgeMTB device is substandard.

The user sent some screen shots (captured from device) that are an absolute dogs dinner!  The device list (https://developer.garmin.com/connect-iq/compatible-devices/) just says this is a High Colour so I went into the "compiler.json" files at the SDK install folders Garmin\ConnectIQ\Devices\

The EdgeMTB reports differently to the other Edge 1040/1050 series devices in the following ways:

    "alphaBlendingSupport": false     [this is true for other Edge]

    "bitsPerPixel": 16                            [this is the same as other Edge]

    "outputColorSpace": "ARGB2222"    [this is missing for other Edge]

    "imageFormats: [ "png", "jpg" ]             [this is missing for EdgeMTB but present for other Edge]


Whilst the simulator is not an emulator, my graphics look great there and so without the EdgeMTB hardware can anyone hint at how I need to alter my return images that I though would be OK as I naively expected the same screen tech and bitsPerPixel would mean similar image support.

Does all this simply mean I need to ensure there is no alpha / transparency in the image?
Can I do that in the makeImageRequest() options parameter as a transform or palette?

If I could replicate the quality issue on the simulator I could make changes and see the results, but at present I feel I'm flying blind a little.

 Many thanks in advance

  • 0

    Might help if you included the edgemtb screenshot and another one where we see the expected result

  • 0

    My field might help. I ran into this with the older displays. The Simulator looks vibrant and crisp, but the actual displays do not. Having your user take a photo of it running this field can help. But be careful because some smartphone cameras auto enhance pictures, which can misrepresent what they see. It is a pain to try to pick colors with proper contrast on less capable displays.

    apps.garmin.com/.../ff11a00c-b563-45d5-9cff-c9feff6b5f5e

  • 0

    Pls see example of image from end-user compared with the simulator.
    Although the sim reports to be 16bits/pixel the same as the other Edge there is complete lack of finesse in the grey-scales.

    I thought of your tool DaveBrillhart as I saw this in other posts, but there should be 65,536 colours available.

    I think the key is in the transparency support.  The grey in the sim / in the source image is a darker colour with an alpha channel on the PNG.
    The EdgeMTB mysteriously does not say it supports PNG (though they obviously display) and also uniquely has the "alphaBlendingSupport": false

    What the application really does is overlay other colours and, again, the end-user on-device report is that unless they are at full opacity from the on-app settings I have it looks poor (no example available).

    From my basic image knowledge, a RGB 0,0,0 with a 50% alpha channel is (in the background) equivalent to RGB 128,128,128 -- so I'll try that.

    But it remains difficult to do device development without seeing the proper fields (Edge 550, 850 missing layouts) or very different graphics support.  

     

  • 0 in reply to DaveBrillhart

    So  - it seems not even 64 colours [sad face]

    Attached are the images from the EdgeMTB device (via end user in the US) - eyeballing the screen shows duplicate colours in the grid and putting the image into a colour counter gives 28 distinct hex values.

    Could this be a firmware issue or just a device limitation?  What is the best place to try and get a definitive answer on the hardware and the correct simulator settings from Garmin? 

     thanks for any suggestions

     

  • 0 in reply to crispgarmin

    Is it possible that the edgemtb has a different palette than what is used by the app, and that's why we see some colors are rendered identical (because the device finds the closest existing color in it's palette)?

  • 0 in reply to flocsy🤠
    flocsy🤠 said:
    Is it possible that the edgemtb has a different palette than what is used by the app, and that's why we see some colors are rendered identical (because the device finds the closest existing color in it's palette)?

    Yes, I'd agree -- without knowing the source-code of the app we don't know if it's:
    * drawing coloured rectangles (would probably default to the internal default palette)


    * drawing a resource image with colours in the PNG/JPG resource (would probably default to the internal default palette)


    * drawing a resource image with known palette colours in the PNG/JPG AND use of code :palette in a DrawBitmap() or similar (this would be the ultimate test of #64 colour support)?

    I'm heading down the latter road but trying to work out dynamic palettes for different make web image requests!

  • 0 in reply to crispgarmin

    I don't think it matters if the compile time conversion of the drawable is done correctly. But you can also compare the palette of different 64 color edge devices in the device reference web page.

  • 0 in reply to flocsy🤠

    Every other Edge (apart from the old monochrome 130) supports 65,536 colours -- I assumed I could "hack" the compiler.json and change the listed:
        "bitsPerPixel": 16

    to:
        "bitsPerPixel": 6

    But in doing so it won't compile!

    So the compiler says EdgeMTB is 16bpp, the simulator shows a full palette (probably 65,536) for EdgeMTB and I don't know the default palette so it's difficult to test working with a custom palette on the image as it looks like if I get it wrong the simulator will show a good image anyway.  Learned some things, more to learn! 

    Thanks for time and input folks.

  • 0 in reply to crispgarmin

    I assume the number of unique colors on all but the very latest AMOLED and LCD screens (1050) are 64. And even then using my field, I've found the number of practical colors to pick from with decent contrast to tell them apart is much less than 64. Maybe 16 bits are used, but the ability to discern among them makes the practical pallette more like 20-30 maybe.

Copyright © 1996-2025 Garmin Ltd. or its subsidiaries