Pass image from PIL directly to an imagecontrol?
#1
Greetings,

This is hopefully a stupid question!

I played around with this image-a-magicky "PIL"-thingy, and yay me.. I got it to do something!
But.. How do I use the image - which is solely a bitmap in memory at this point - on a control?

Is there something along the lines of controlImage.image = myPILmadeImage?
I have no reason to keep a HDD copy of the image as it is a dynamic "thing", and it is made fast enough to not bother.

Thanks,

p.s. My tagline should read: Came for a skinnable MediaPortal.. stayed forever - because it's not really skinnable - unless you learn to code.. alot! - Laugh with me... Wink
Reply
#2
you have to make the image accessible via VFS, so saving to disk might be the only easy option.
Donate: https://kodi.tv/contribute/donate (foundation), 146Gr48FqHM7TPB9q33HHv6uWpgQqdz1yk (BTC personal)
Estuary: Kodis new default skin - ExtendedInfo Script - KodiDevKit
Reply
#3
Thanks Phil65. I'll use PIL for HDD based operations only then, and not as a dynamic skinning tool unless such an option should arise. There goes the fixed blurred background for a slide in menu.
Reply
#4
It's not possible. And, as I understand, this isn't even for Kodi itself, because it stores in a local image cache a copy of every image it has displayed.
Reply
#5
Hi Roman, sad to hear that Kodi isn't cool about dynamic images. Hopefully it will change sometime soon.

Assuming Kodi stores a local cached image of E V E R Y T H I N G it comes across, be that images from the internet or my local HDD, how does an update of a cached image happen? I ask because I get a sudden FEAR, that all my tens of thousands of images scraped online is being checked for updated versions.. P L E A S E tell me such an update never happens!!

It seems the deeper I dig, the less I find - to liek.
Reply
#6
(2016-02-04, 15:22)Torben Wrote: Hi Roman, sad to hear that Kodi isn't cool about dynamic images. Hopefully it will change sometime soon.

Assuming Kodi stores a local cached image of E V E R Y T H I N G it comes across, be that images from the internet or my local HDD, how does an update of a cached image happen? I ask because I get a sudden FEAR, that all my tens of thousands of images scraped online is being checked for updated versions.. P L E A S E tell me such an update never happens!!

It seems the deeper I dig, the less I find - to liek.

I said "a copy", that is a thumbnail, not an actual image. Look into \userdata\Thumbnails\ folder and you will see. If a file has been changed, meaning that a new file with the same name has been put at the same path, after some time Kodi will update the thumbnail for that file, and a new version will be displayed.
Reply
#7
Hi Roman, and thanks for being most informative on this subject - I really appreciate it! I hope you won't mind me being even more inquisitive. I do not mean to offend anyone in any way.

Q: What are the time intervals between these "check for updates"?
Q: How is it determined what images are in use by Kodi and what images are to be deleted from the thumbnail area?
Q: How does Kodi know where to look for updates?
Q: Can some or all of this be controlled/disabled in any way?
Q: How much data is needed to check a single on-line image source for an update to an image?

I know about the location of this "thumbnails" directory. And it saddens me to see that it is impossible to manage by a human. It's coded for machine-reading only.
When I write "thumbnails" in quotes, it's because they are not really thumbnails are they? Are they in fact not a cache folder that Kodi uses for display in the skins instead of the actual sources?

My thumbnail folder has around 30.000 image-files in it, and I need to know how much of my internet quota goes to maintain this.. mess.
I work towards my Kodi setup to be self-sufficent in lack of a better word - to have it all off-line. (Not the actual on-line sources obviously)

Assuming that Kodi uses these images... as they are, and has NO other skin-specific cache, I have more issues with this system:

Q:Is the same image (from the thumbnails area) used for the lists AND the detailed blow-up display?

If that is so.. A lot of on-the-fly resizing must take place in - especially - the panels that has - thumbnail - covers/posters.
I would expect a skin-specific cache to create just the proper sizes that I need for the current skin.

Depending on the answers to this, I wonder if I could/should somehow intercept the "art" part of populate lists, and pass links directly to my own folder with properly tiny thumbnailed images for lists, and links to full-sized versions when they are needed? Maybe a side-effect to this would be that the jagged scaling of the images in the skin went away.

Unless ofcourse all these custom image-links are simply being added to an autonomous "thumbnail" area by the Great Kodi Automatron..
Reply
#8
do you really think it is checking all those images all the time? would you have designed it as that?

A. It checks when an image is actually accessed, if it is 24h since it was cached it will hit the url to make sure the cached copy is not outdated.
A. Usage tracking.
A. Uhrr. How do you normally identify files? By their URL of course.
A. Not from scripting. Only the big boys have access to the functionality.
A. Depends on the protocol. On the order of 100 bytes for http (depends on the number of entries in the http headers).

It depends on how the images are used. If they are used as thumbs in the skin, the thumb version is used. if they are used in large image controls, a larger version is used. there has been some changes here lately i haven't followed.
Reply
#9
From the design I have seen here I expect about anything.
IMO checking thousands of images each day is Infact pretty close to all the time.

I need some time to edit this reply....
Reply
#10
alternative is downloading those images every time. it's much much much cheaper to check for changes.

and it's not checking thousands of images each day, or well, that depends on your usage pattern. it's checking them on use, if it is > 24h since they were last checked. unused images are not checked.
Reply
#11
Hi, I completely forgot about this.. sorry *blush*

This thread could do with a split.

I will continue to investigate my options on circumventing not the build-in-cache, but the build-in check for updated images as it is a really stupid design flaw that makes zero sence to me. If you feel like continuing the discussion, do so - please.

My issues (in this area) continue to be: How do I get full control of the quality/size of the thumbs/fullsized images, saved as "that GPU friendly format" and only use offline images, and skip checking for new images cause there wont ever be any AND if there is a change in he images I'll handle the update of the thumb myself as the path doesnt change.

I read the wiki, so all this below is pretty backwards.. kept for reminding me to shut up alittle..
There is an image database? There is a cache with rather large images? There are "real" sources scattered online and offline. Is there any intelligence somewhere? ...And then there is some black-box burried deep in that beast we now know as Kodi.

Here is my guessworks on the Kodi imagehandling black box
Please keep in mind I am simply guessing here

The database is basically a single table that looks like
Source | machinecoded name | an access date | source date
http://blah blah.., 05839509286.jpg, 2016.02.17 | 2002.01.01
C://blah blah.., 15839509286.jpg, 2016.02.17 | 2003.12.12
...
In essence, there is no images in the database

Kodi handles images like this:
In the following, an imagepath, to any image, from anywhere, online or local - is the source.
1. Kodi checks if the source is known in the database...
2. If source is known:
Kodi checks the filedate, and if more then 24 hours since last access, it requests a new date from the source, and if that turns out to be new the source is processed as "unknown" below.
3. If unknown:
Kodi makes a note of the source url and pairs that with a unique filename.
Then loads the full source and stores a nasty downsized, but not really that much smaller, version in the cache.

Finally the "smaller" cached versions are loaded directly by Kodi one-by-one and displayed as it is relying on the cpu or gpu to do the resizing on -the-fly.

This is done for any image, so scrolling through a big list of - say - albumcovers, basically makes Kodi run amok on this whole check-for-new-image every 24 hours, even though your sources hasn't changed in the last decade.

If the above is true, I speculate that to achieve my goal (which is)..:
- Disabling the continuous source checking (or whatever it is you actually do in that black box?), as I have all my images offline and they will never change.
- Use properly scaled small thumbnails
- AND high quality fullsized scans

...my hacking options are:
To prevent the source checking:
- Set the last-access dates into the future... but that is probably overwritten by Kodi on image-db-access.
- Somehow change the Kodi-system date on each and every image access to a fixed date, and then back again.
To get proper sized thumbnails and also big unscaled artwork:
- Roll my own thumbnail system, that rescales artwork to a proper thumbnail size (200x200 in my case, but probably better to use 256x256?)
- Update the Kodi mediadatabase with urls to both my rescaled thumbnail artwork, AND with locations to the full-sized artwork.

.. Then delete the non-human-readable cache for good

Correct?
Reply

Logout Mark Read Team Forum Stats Members Help
Pass image from PIL directly to an imagecontrol?0