Test application: For "lightning fast thumbnail creation" (1 Viewer)

Inker

Retired Team Member
  • Premium Supporter
  • December 6, 2004
    2,055
    318
    I just took a brief look at the source code of MyPicture section of MP.

    It seams that the integration becomes more complicated as I thought.

    From my brief research I did not found a method that allows me to set the shown Thumb in the facadeView at runtime without loading a file from disk. All available methods seem to based on loading files (thumbs) from the harddrive, but that (of course) will slow down the whole routine because I have to save the thumb just to load it afterwards.

    I've found the implementation of the OnRetrieveCoverArt. At this point it would easy to "turn to" my ExifExtractor to check if the item has an embedded and retrieve it. But how can I assign the retrieved image the the facadeView?

    I tried something like this for testing (in the OnRetrieveCoverArt):
    Code:
    Bitmap tmpBitmap = new Bitmap(160, 120);
    Graphics tmpGraphics = Graphics.FromImage(tmpBitmap);
    tmpGraphics.FillEllipse(Brushes.Red,new Rectangle( 0, 0, 160, 120));
    
    System.Drawing.Image img = (Image)tmpBitmap.Clone();
    
    item.Thumbnail.MemoryImage = img;
    But item.Thumbnail is always null. And create new GUIImage seems to need a filename again ... :(

    The following code does work (Of course)... but this no solution.
    Code:
    Bitmap tmpBitmap = new Bitmap(160, 120);
    Graphics tmpGraphics = Graphics.FromImage(tmpBitmap);
    tmpGraphics.FillEllipse(Brushes.Red,new Rectangle( 0, 0, 160, 120));
    
    System.Drawing.Image img = (Image)tmpBitmap.Clone();
    img.Save("C:\\test.jpg", ImageFormat.Jpeg);
    
    string thumbnailImage = "C:\\test.jpg";
    item.ThumbnailImage = thumbnailImage;

    Any ideas?

    Bye
    Lars

    You'll have to use the Texturemanager to convert the bitmap to a texture and then load that texture to the control. But you need to make sure they get unloaded too when you don't need them anymore or the memory usage will go through the roof.

    Something like:

    Code:
    System.Drawing.Image img = whatever.LoadImage();
    string name = "whatever"; // unique per thumbnail, perhaps use the path
    Size s = new Size(100,100);
    item.ThumbnailImage = buildMemoryImage(img, name, s);
    
    public static string buildMemoryImage(System.Drawing.Bitmap image, string identifier, System.Drawing.Size size)
    {
        string name = String.Format("[Thumbnail:{0}]", identifier);
        try
        {
            if (GUITextureManager.LoadFromMemory(null, name, 0, 0, 0) == 0)
            {
                GUITextureManager.LoadFromMemory(image, name, 0, size.Width, size.Height);
            }
        }
        catch (Exception ex)
        {
            // error
        }
        return name;
    
    }

    for me it works only if I specify a folder with jpg inside of it.

    If I specify the folder above that, eg multiple folders the program just sits their doing nothing after i press start

    Because it doesnt search recursivly, its just a test app :)
     

    lkuech

    Retired Team Member
  • Premium Supporter
  • February 16, 2007
    576
    83
    50
    Hamburg
    Home Country
    Germany Germany
    Thanx Inker.

    That makes sense. I will do some more researches on that.

    Bye
    Lars

    Edit: After just another brief experiment it look much better. I now able to see the embedded pictures in the fascadeview and it is not slower than before. The routine extracts the thumbnails from the pictures so fast that there is no need to have thumbnails in the "thumbs" folder anymore.

    No I have to think of a texture management to get rid of textures that not used any more.
    The mentioned OnRetrieveCoverArt is called by the fascadeview if a list item is shown for the first time... so that is perfect to implement my routine.
    But unfortunately there is no "OnFreeCoverArt" or something like that.
    Do you know how I can analyse with items are shown and with not?

    I thought about a List<string> that contains the texture names of the loaded textures, but I have to find out which textures are not needed anymore to free them by time...

    Bye
    Lars

    Edit2:

    Mmhh. I still haven't found a proper way to know which items are currently visible and which not. that would be the "cleanest" way to keep only textures in the memory that really needed.

    A different approach would be to keep all textures that has been loaded via the modified OnRetrieveCoverArt till the folder is changed... But after browsing a folder with many images that wouldn't be a perfect solution.

    Any ideas ;)
     

    lkuech

    Retired Team Member
  • Premium Supporter
  • February 16, 2007
    576
    83
    50
    Hamburg
    Home Country
    Germany Germany
    Hi again :)

    Here is my first approach...

    It is not an 100% solution right now... but I'm on my way ;)

    The current behaviour is like this:
    1. Search for a thumbnail in the "thumbs\picture" folder.
    2. if not found. Try to use the Exif thumb.

    To test the new function is makes sense to delete all already generated thumbs from the "thumbs\picture" folder (create a backup first :mad:).

    The background thumb generator does only generate thumbs for images without EXIF thumbs. This will save thousands of files from being created and save a lot of diskspace.
    But I plan to created an option that gives you the ability to choose if he should generate highres thumbs in the "thumbs\picture" folder instead (this is the old way but will most likely generate thumbs with a slightly better quality as the embedded thumbs).

    Know "bugs"
    • Exif Thumbs will not be rotated right now.
    • images without EXIF thumb will not update not update the database right now. That means you will not see them if you switch to the date based view.
    • (fixed)The background thumb generation of images without EXIF thumb will not update the listview automatically. After using PageUp or PageDown the images are shown.

    EDIT: I fixed the "EXIF thumb will not update the listview automatically" bug. The attached files has been updated

    EDIT2: I've remove the attachment because it was is outdated. If someone is interested in the updated test files... just let me know.

    Bye
    Lars
     

    The_Stig

    Retired Team Member
  • Premium Supporter
  • April 5, 2005
    2,176
    428
    Did a short test and worked good here. I had fast thumbnails showing and creation of thumbs started in background as usual. But they showed up nearly instantly, so that EXIF-reading seems to work.
     

    lkuech

    Retired Team Member
  • Premium Supporter
  • February 16, 2007
    576
    83
    50
    Hamburg
    Home Country
    Germany Germany
    I've updated the post before. In the new attachment I have fixed that images without EXIF thumbs are not shown directly if the background updater has created the thumb.

    Bye
    Lars
     

    lkuech

    Retired Team Member
  • Premium Supporter
  • February 16, 2007
    576
    83
    50
    Hamburg
    Home Country
    Germany Germany
    Because we are currently in a "freeze phase" of the development until the next stable comes out. I'll wait with the final integration till we reach that point. The posted windowplugins.dll (post #13) shows like a "proof of concept" how fast MP may show thumbnails even without the need to pre generate them (and how well they look even on a 40'' FullHD screen).

    The final integration will make a complete replacement of the current ExifExtractor (that one that is used by MP right now) necessary. That means even classes like the PictureDatabaseSQLLite.cs have to be changed. Of course that is not possible during a freeze phase.

    Also we have to discuss when and how to generate big thumbs, because these can not be replaced by my routine.

    Most likely I develop this further (with minor priority ;)) and we will soon have something to show when the freeze is over.

    Bye
    Lars
     

    Maschine

    Retired Team Member
  • Premium Supporter
  • June 15, 2004
    768
    86
    Germany
    Home Country
    Germany Germany
    Also we have to discuss when and how to generate big thumbs, because these can not be replaced by my routine.

    While thinking about this I had the following idea: we give the user an option to decide between the "small" EXIF thumbs and the "big" MP thumbs.

    For option 1 (EXIF) the EXIF thumbs will used whenever they exist in a file, only when there is no thumb available, the MP thumb generator starts to create one, which is used then. If a file has exif thumbs no "big" MP thumbs are ever used.

    For option 2 the best solution would be a section in the configuration program that generates thumbs for all your shares. Like the building of the music db is done already. So you could start this, leave MP alone once for some time, but then you'll have all thumbs ready. For monitoring shares for new picures there is something like the music share watcher. It creates the "big" MP thumbs in the background with a very low priority. If a user enters a folder with no big thumbs created yet, he will see the EXIF thumbs like in option 1.

    I hope at least somebody can follow my thoughts :cool: What do you think?

    Maschine
     

    pollyplopp

    Portal Member
    July 8, 2007
    13
    0
    Home Country
    Sweden Sweden
    Thanks for this nice addition. It sure makes My Pictures much more useful.
    And I really don't like wasting space just to show icons now and then.

    While thinking about this I had the following idea: we give the user an option to decide between the "small" EXIF thumbs and the "big" MP thumbs.

    For option 1 (EXIF) the EXIF thumbs will used whenever they exist in a file, only when there is no thumb available, the MP thumb generator starts to create one, which is used then. If a file has exif thumbs no "big" MP thumbs are ever used.

    For option 2 the best solution would be a section in the configuration program that generates thumbs for all your shares. Like the building of the music db is done already. So you could start this, leave MP alone once for some time, but then you'll have all thumbs ready. For monitoring shares for new picures there is something like the music share watcher. It creates the "big" MP thumbs in the background with a very low priority. If a user enters a folder with no big thumbs created yet, he will see the EXIF thumbs like in option 1.

    I hope at least somebody can follow my thoughts :cool: What do you think?

    Maschine

    I like the idea that it's configurable!
    I would use #1, ie remove all small thumbs and use exif. For images without Exif thums, small thums could be created.

    About #2: For me it would be enough if big icons were created (slowly) on the fly only when I choosen 'Big Icons' in certain directories. Exif thums would be enough most of the time.
    I find it a big overkill with a 'thumb-database' like the music db, but maybe that is just me.

    Ps. I tried reproducing idioteque 'it messed up my TV guide'. I once had the guide 'stuck' on top, without it being possible to remove. That happened only once so I am uncertain if it was the fault of the new windowplugin or not.

    idioteque, please explain what/how it messed it up, so that it could be checked/fixed.
     

    lkuech

    Retired Team Member
  • Premium Supporter
  • February 16, 2007
    576
    83
    50
    Hamburg
    Home Country
    Germany Germany
    Hi @ll.

    As far as I can say from analysing the current code of the latest MP SVN, the large thumbs are only used for filmstrip panel (also known as cover view). Even if you switch to "Big icons" you use the "small thumbs".
    That means the only kind of thumbs that can not be replaced by the new EXIF extrator are these "large thumbs".
    But IMHO the idea of pollyplopp to creating them on the fly when they are required is absolutely worth to think about. How often is the the filmstrip used? Does it really make sense to create thousands of files just for such kind of feature?
    Why not doing the same thing like the slideshow (even manually) does. Load the picture when it is needed (and do the same with the next and previous one to speed up the user experience). Generating a copy of every picture in a resolution of 768xsomething is a "bit" oversized for our propose... at least from my point of view.
    Tourette had mentioned good idea on IRC yesterday. Because of the reason that not all cameras may generate thumbs in a quality that can compete with the manually created ones from MP. We should create an option to set which resolution the embedded thumb must have to be used. Otherwise MP generates it's own in the background (but used the embedded one till the new thumb is generated).

    idioteque: the file I have posted is just for test propose. It was compiled against a svn that is two days old. To use it with a different SVN may lead to side effects in other modules. So after the testing of the Picture section (and only these ;) you should better return the the original file.
     

    Users who are viewing this thread

    Top Bottom