Test application: For "lightning fast thumbnail creation"

[Inker]

Originally Posted by lkuech

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):

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.

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:

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;

}

Originally Posted by idioteque

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]

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]

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 ).

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]

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]

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]

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]

Originally Posted by lkuech

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 What do you think?

Maschine

[idioteque]

works great !

thx


one thing:

it messed up my TV-guide

[pollyplopp]

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.

Originally Posted by Maschine

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 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]

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.