I’m not sure what you mean by the photos being of 4K quality. My point and shoot camera is 14M and my SLR is 20M. A 4K picture is 8.3M. It seems strange to take a picture of 14M downscale it to HD and then let the tv upscale it to 4K when it could just be displayed at 4K to start with. Am I missing something here.
1 Like
The point I was (badly) trying to make was that I doubted there would be any visible difference after jpg compression had taken its toll on image quality and that the up scaling in the TV may actually make for a sharper image at that size. Of course that all depends on the original resolution of the images, the type of compression applied and whether they have been resized.
If you’re taking at >12MP with the camera set to the highest quality, not resizing and using a high quality jpg compression then yes you would see a noticeable difference in 4k.
On the other hand if you are using a <12MP camera set to “medium” quality to get a balance between quality and number of pics on the sd card then you’d likely see very little difference at 4k.
All that being said this is not possible with kodi at the present time on any platform. There are several threads dedicated to it at the kodi forums http://forum.kodi.tv/ with little progress being made.
Ultimately it is a Kodi development issue and is probably best addressed directly there, though any improvement will not be made now until after the 18.0 release as all development on v17 is now frozen.
These days there is little need to reduce quality to fit more shots on the sd card as large capacity cards are inexpensive. That said I take your point. I hope that kodi keeps pushing for the highest quality media. Flac files in music and uhd in video so why not 4k photos. If the developers start relying on upscaling why not let the tv upscale the videos too. I will keep hoping.
You might have come across this already but as I recall the issue is this:
Videos are rendered in the GPU, whereas the GUI is rendered in the CPU. Still photos are not video, so are also rendered in the CPU. As Kodi is currently implemented, still photos are shown in the native resolution of the GUI, so while it might in theory possible to render the GUI in 4K, the load on the CPU will increase greatly and the general fluidity and responsiveness will be adversely affected.
Clearly, there could be a mechanism to keep the GUI in 1080 and switch to a higher resolution when showing full-screen photos. Perhaps this will be possible in Leia.
Thanks for the explanation - I can understand the reasoning and when both videos and the GUI are in hd it didn’t matter. Now that 4K is becoming more popular perhaps the developers will rethink. The photos do seem to be not as well thought of as music or videos - the slideshow and screen savers don’t seem to work very well. The slideshow timing is poor and the way the photos fade into each other during a slideshow is a bit clunky. Maybe thats just a case of the processor power available. I used to run kodi on a windows pc and the slideshow was fine. I changed to the pi because I was fed up with windows. I am looking forward to kodi 17 as I understand it will have a netflix capability. There isn’t that much you can do at the moment if you want to stay legal.
Sorry meant kodi 18.
I confirm that, in2017, the lowest and cheapest camera or even phone can make a picture bigger then 1920 x 1080.
And I also confirm that the visual difference with a 4k and a HD display is striking, even in jpg.
So, I would really really appreciate is the matter could be taken as “important”
Sincerely
1 Like
Is it possible to know where to follow up on Kodi 18 and the possible 4k display of pictures?
Thanks
As this is a Kodi issue or a specific Kodi function you should look at addressing the issue there. We are unable to resolve your issue. If you do believe that this is an OSMC specific issue, please let us know.
Actually can you confirm it is a Kodi issue?
I’m still trying to figure out who will tell me how and when it will be possible, with the Vero 4K to display the pictures with the 4K resolution and not a down scaling as it is at the moment.
I was expecting someone from this forum to be able to help.
Thank you.
It’s part of Kodi’s “functionality”, ie that’s how the Kodi developers have written it.
If you would like the Kodi developers to display pictures with 4K resolution, the correct place to ask would be on the Kodi forum.
Yes. Categorically.
Vero 4K runs Kodi so see above.
How? This forum is for hardware support and support of the Operating System the Vero4K runs. Kodi runs on Windows too would you expect Microsoft to know when Kodi would launch new functionality?
The only people who can answer your question are those who are actively involved in Kodi’s development and those who control the direction of it’s evolution. That is to say the developers on the Kodi forum.
If Kodi were to support this but it didn’t work on the Vero 4K (or another 4K device running OSMC) then this would be the place for that question, but whilst Kodi doesn’t support it at all then the underlying hardware is rather irrelevant.
I’m sorry.
I always thought vero4K was the hardware and osmc the software (based on Kodi)
And as I’m running Osmc on my Vero4K, and having probleme using a fonctionnality, I thought a forum on osmc.tv, in the help & support section was the right place to ask those questions.
I don’t understand the analogy with Windows/Kodi question!?
Isn’t this a osmc help & support forum?
Fixed that for ya 
Anyone can, and often do, install Kodi on a Windows machine sold by Dell. If there is a problem with Kodi itself in such an instance, Dell is going to have no desire to troubleshoot an issue that is clearly a problem with the Kodi program itself. They will direct this user to address the problem with Kodi directly.
I did post in Kodi forum 6 month ago and the problem doesn’t seem to interest anyone…
Nobody here (using Vero4K) is interested in solving the problem?
Got a reply from the Kody community
fritsch :
Reading vero kernel source: https://github.com/osmc/vero3-linux/blob...2g_16g.dts ← it’s force to 1080p60 there and fb0 only has enough memory reserved for 1080p. Video is rendered bypass. Fix that 
but I honestly doubt that it can render GLES in 4k. Bypass is done by a blackbox directly into FB1 without going through the GPU. Remember: On ARM chips one has to highly distinguish between 3D GPUs that one knows from the desktop and a VPU. Most of the time they are tied specially via an IPU that outputs without having to read memory back like the 3D GPU needed to do.
So in short: If OSMC configures the FB for 4k (which they cannot do by default in a hardcoded way) you will get 4k GUI in kodi.
And then he added :
Ask in osmc forum if Sam can provide you a build that forces primary framebuffer to 4k
So, there you are, it is a osmc business after all
This was mentioned before, and I don’t recall anyone saying it’s a Kodi issue.
So yes – you’d need to:
- Build a kernel with 4K framebuffer allocation
- Disable the scaling code in the initramfs.
- Remove scaling patches from Kodi (may not be necessary)
I can send you a patch if you want to try this, but don’t have time to test it myself currently.
Yes, sure, thank you, I’m ok to test it.
Please send me a patch 
Vincent
- Change the amount of memory allocated to fb:
diff --git a/arch/arm64/boot/dts/amlogic/vero3_2g_16g.dts b/arch/arm64/boot/dts/amlogic/vero3_2g_16g.dts
index 97fde3d..a6df7a8 100644
--- a/arch/arm64/boot/dts/amlogic/vero3_2g_16g.dts
+++ b/arch/arm64/boot/dts/amlogic/vero3_2g_16g.dts
@@ -69,7 +69,7 @@
};
fb_reserved:linux,meson-fb {
compatible = "amlogic, fb-memory";
- size = <0x0 0x2000000>;
+ size = <0x0 0x4480000>;
no-map;
};
@@ -157,7 +157,7 @@
interrupts = <0 3 1
0 89 1>;
interrupt-names = "viu-vsync", "rdma";
- mem_size = <0x01800000 0x00100000>; /* fb0/fb1 memory size */
+ mem_size = <0x0 0x4480000>; /* fb0/fb1 memory size */
display_mode_default = "1080p60hz";
scale_mode = <1>; /** 0:VPU free scale 1:OSD free scale 2:OSD super scale */
display_size_default = <1920 1080 1920 3240 32>; //1920*1080*4*3 = 0x17BB000
- Make sure the initramfs doesn’t configure scaling for 4K video modes:
diff --git a/package/kernel-osmc/initramfs-src/init.d/vero364 b/package/kernel-osmc/initramfs-src/init.d/vero364
index 06bbf16..8f3b553 100644
--- a/package/kernel-osmc/initramfs-src/init.d/vero364
+++ b/package/kernel-osmc/initramfs-src/init.d/vero364
@@ -40,30 +40,20 @@ fi
# Configure framebuffer X and Y size
case $hdmimode in
- 480*) X=720 Y=480 ;;
- 576*) X=720 Y=576 ;;
720p*) X=1280 Y=720 ;;
- *) X=1920 Y=1080 ;;
+ 1080p*) X=1920 Y=1080 ;;
esac
-/bin/busybox fbset -fb /dev/fb0 -g $X $Y 1920 2160 32
-/bin/busybox fbset -fb /dev/fb1 -g 32 32 32 32 32
+if [ ! -z "$X" ] && [ ! -z "$Y" ]
+then
+ /bin/busybox fbset -fb /dev/fb0 -g $X $Y 1920 2160 32
+ /bin/busybox fbset -fb /dev/fb1 -g 32 32 32 32 32
+fi
echo 0 > /sys/class/graphics/fb0/free_scale
echo 0 > /sys/class/graphics/fb1/free_scale
echo 1 > /sys/class/video/disable_video
-# Enable scaling for 4K output
-case $hdmimode in
- 4k*|smpte*|2160*)
- echo 0 0 1919 1079 > /sys/class/graphics/fb0/free_scale_axis
- echo 0 0 3839 2159 > /sys/class/graphics/fb0/window_axis
- echo 1920 > /sys/class/graphics/fb0/scale_width
- echo 1080 > /sys/class/graphics/fb0/scale_height
- echo 0x10001 > /sys/class/graphics/fb0/free_scale
- ;;
-esac
-
# Enable framebuffer device
echo 0 > /sys/class/graphics/fb0/blank
- Remove this Kodi scaling patch:
- Add the following patch:
From 46aab0b0856eeaa855c430ddd36ac97203afa43b Mon Sep 17 00:00:00 2001
From: Alex Deryskyba <alex@codesnake.com>
Date: Wed, 1 Jul 2015 23:37:11 +0200
Subject: [PATCH 3/5] [aml] Add support for 4k resolutions
---
xbmc/utils/AMLUtils.cpp | 16 ++++++++--------
xbmc/windowing/egl/EGLNativeTypeAmlogic.cpp | 23 +++++++++++++++++++----
xbmc/windowing/egl/EGLNativeTypeAmlogic.h | 2 ++
3 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/xbmc/utils/AMLUtils.cpp b/xbmc/utils/AMLUtils.cpp
index 80fb453..65286de 100644
--- a/xbmc/utils/AMLUtils.cpp
+++ b/xbmc/utils/AMLUtils.cpp
@@ -463,8 +463,8 @@ bool aml_mode_to_resolution(const char *mode, RESOLUTION_INFO *res)
}
else if (StringUtils::EqualsNoCase(fromMode, "4k2ksmpte") || StringUtils::EqualsNoCase(fromMode, "smpte24hz"))
{
- res->iWidth = 1920;
- res->iHeight= 1080;
+ res->iWidth = 4096;
+ res->iHeight= 2160;
res->iScreenWidth = 4096;
res->iScreenHeight= 2160;
res->fRefreshRate = 24;
@@ -481,8 +481,8 @@ bool aml_mode_to_resolution(const char *mode, RESOLUTION_INFO *res)
}
else if (StringUtils::EqualsNoCase(fromMode, "4k2k24hz") || StringUtils::EqualsNoCase(fromMode, "2160p24hz"))
{
- res->iWidth = 1920;
- res->iHeight= 1080;
+ res->iWidth = 3840;
+ res->iHeight= 2160;
res->iScreenWidth = 3840;
res->iScreenHeight= 2160;
res->fRefreshRate = 24;
@@ -490,8 +490,8 @@ bool aml_mode_to_resolution(const char *mode, RESOLUTION_INFO *res)
}
else if (StringUtils::EqualsNoCase(fromMode, "4k2k25hz") || StringUtils::EqualsNoCase(fromMode, "2160p25hz"))
{
- res->iWidth = 1920;
- res->iHeight= 1080;
+ res->iWidth = 3840;
+ res->iHeight= 2160;
res->iScreenWidth = 3840;
res->iScreenHeight= 2160;
res->fRefreshRate = 25;
@@ -508,8 +508,8 @@ bool aml_mode_to_resolution(const char *mode, RESOLUTION_INFO *res)
}
else if (StringUtils::EqualsNoCase(fromMode, "4k2k30hz") || StringUtils::EqualsNoCase(fromMode, "2160p30hz"))
{
- res->iWidth = 1920;
- res->iHeight= 1080;
+ res->iWidth = 3840;
+ res->iHeight= 2160;
res->iScreenWidth = 3840;
res->iScreenHeight= 2160;
res->fRefreshRate = 30;
diff --git a/xbmc/windowing/egl/EGLNativeTypeAmlogic.cpp b/xbmc/windowing/egl/EGLNativeTypeAmlogic.cpp
index 88cd385..3bfb0c6 100644
--- a/xbmc/windowing/egl/EGLNativeTypeAmlogic.cpp
+++ b/xbmc/windowing/egl/EGLNativeTypeAmlogic.cpp
@@ -64,7 +64,22 @@ void CEGLNativeTypeAmlogic::Initialize()
{
aml_permissions();
DisableFreeScale();
+ GetMaxResolution(m_maxResolution);
}
+
+void CEGLNativeTypeAmlogic::GetMaxResolution(RESOLUTION_INFO &maxResolution)
+{
+ std::vector<RESOLUTION_INFO> resolutions;
+ ProbeResolutions(resolutions);
+
+ maxResolution = {0};
+ for (size_t i = 0; i < resolutions.size(); i++)
+ {
+ if (resolutions[i].iScreenWidth > maxResolution.iScreenWidth || resolutions[i].iScreenHeight > maxResolution.iScreenHeight)
+ maxResolution = resolutions[i];
+ }
+}
+
void CEGLNativeTypeAmlogic::Destroy()
{
return;
@@ -83,8 +98,8 @@ bool CEGLNativeTypeAmlogic::CreateNativeWindow()
if (!nativeWindow)
return false;
- nativeWindow->width = 1920;
- nativeWindow->height = 1080;
+ nativeWindow->width = m_maxResolution.iScreenWidth;
+ nativeWindow->height = m_maxResolution.iScreenHeight;
m_nativeWindow = nativeWindow;
SetFramebufferResolution(nativeWindow->width, nativeWindow->height);
@@ -244,8 +259,8 @@ void CEGLNativeTypeAmlogic::SetFramebufferResolution(int width, int height) cons
{
vinfo.xres = width;
vinfo.yres = height;
- vinfo.xres_virtual = 1920;
- vinfo.yres_virtual = 2160;
+ vinfo.xres_virtual = m_maxResolution.iScreenWidth;
+ vinfo.yres_virtual = m_maxResolution.iScreenHeight * 2;
vinfo.bits_per_pixel = 32;
vinfo.activate = FB_ACTIVATE_ALL;
ioctl(fd0, FBIOPUT_VSCREENINFO, &vinfo);
diff --git a/xbmc/windowing/egl/EGLNativeTypeAmlogic.h b/xbmc/windowing/egl/EGLNativeTypeAmlogic.h
index cfb33ca..cf60134 100644
--- a/xbmc/windowing/egl/EGLNativeTypeAmlogic.h
+++ b/xbmc/windowing/egl/EGLNativeTypeAmlogic.h
@@ -58,6 +58,8 @@ protected:
private:
void SetFramebufferResolution(const RESOLUTION_INFO &res) const;
void SetFramebufferResolution(int width, int height) const;
+ void GetMaxResolution(RESOLUTION_INFO &maxResolution);
std::string m_framebuffer_name;
+ RESOLUTION_INFO m_maxResolution;
};
--
1.7.10.4
Thank you.
I’m okay to do the edit necessary in my config to match the requirement
But a compilation?
Is it possible to have the patch compiled?
Thanks