Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[davidperetz]

Hello

I really love MC28 Looking forward for MC29

I was wondering if you could implement the image features better in mc29

I really like all the tagging ,sorting and filtering that i can do in mc28 video library , and really want it to be my photo management library.

Right now i can't use it effectively as the raw support and speed is not sufficient , also the viewing, zooming of pictures and moving from pic to other and back is not comfortable. even if i use the 2d viewer which is little better 'still lacking and opened like a video.

is there a chance to get better photo managing features and implementation in MC29?

Thanks

[JimH]

Loading and displaying an image shouldn't be slow.  It's about 1/2 a second on my laptop.

Raw images would be slower because of their size.   Take a look at options for images.

If you're loading from a network drive or a USB drive, try loading from a local drive.

Antivirus could also cause a delay.

[davidperetz]

Thanks for the answer

That's not all i meant , its not just that the raw loading is slow. my intention was not complaining about something that is not good , instead i asked if the whole image section can be developed little more like the video section is.

Mc is really powerfull tool and i use it all the time for all my media management, so i though about use it for my images as well.

Thanks

[Buldarged]

Well, a nice addition would be to have some kind of "Mosaic View" instead of the standard grid view. The grid view is fine, when everything has the same aspect ratio, like music album or TV show covers. However images and photos do usually not share the same aspect ratio. Some are portrait, some are landscape, some are long and thin and some are square.

What do i mean, when i say "Mosaic View"? Something like this. Just looks much better artistically.
Most implementations use fixed sized rows or columns or completely fixed pre-made grid layouts. However, I have seen at least one implementation that doesn't. By resizing, cropping and slightly reordering beautiful results can be achieved.


Another big problem with images and MC is the performance. You will notice a slowdown with 100k+ files in MC. With 1M+ files, MC becomes less and less usable. Just opening views might take seconds or even crash MC. Importing a single new file into such a library can easily take over 10 minutes.

I know this because i tried to use MC for such purposes. But I had to give up. However, i slowly begin to face the same problem with lots of small mp3 audiobook files.

[davidperetz]

really?

i didn't know of that issue , so you recommend not importing all of my pics? with all songs and movies will be way over 100,000

[JimH]

Another big problem with images and MC is the performance. You will notice a slowdown with 100k+ files in MC. With 1M+ files, MC becomes less and less usable. Just opening views might take seconds or even crash MC. Importing a single new file into such a library can easily take over 10 minutes.

I know this because i tried to use MC for such purposes. But I had to give up. However, i slowly begin to face the same problem with lots of small mp3 audiobook files.

Have you reported this?  It's not normal.

Antivirus software can cause problems like this.  So can network drives.  MC can handle whatever the file system will.

[JimH]

really?

i didn't know of that issue , so you recommend not importing all of my pics? with all songs and movies will be way over 100,000

You won't have problems.  I know of libraries over a million tracks.  We've used MC as a front end for libraries of around ten million.

[davidperetz]

Oh Ok

i have a very powerful pc with ryzen 5950x 18 cores cpu and 32gb ram i think i will give it a try

[Buldarged]

Have you reported this?  It's not normal.

Antivirus software can cause problems like this.  So can network drives.  MC can handle whatever the file system will.

Well, I've written something in another thread by another user a year ago: https://yabb.jriver.com/interact/index.php/topic,127472.0.html
This was with version MC27 and I'm using MC28 only since yesterday (through MC29 license, since I skipped MC28), so I have not yet experienced any of the changes of the last year. My experience with a photo library with more than 1M files is much older (maybe around MC22) and was on an older quad-core CPU.

Still, when using the latest version of MC28, faster scrolling in some views stutters significantly when having "Show Fanned Thumbnails" enabled. This feature looks like it causes MC to load 5 times the amount of thumbnails. Not that I need that feature, but it indicates that I might get the same problem with a 5 times bigger library, while having it disabled.


I generally think that the way thumbnails are generated,stored and loaded should be reworked for both quality and performance reasons. For one there are newer compressions like webp available, which makes the thumbnails smaller on disk and in ram. It makes displaying them more expensive, but the amount displayed scales with monitor resolution and not with the number of files.
It might also make sense to provide more levels than just large, medium and small. Mip mapping usually goes down to 1 pixel. Currently MC sometimes uses the medium thumbnail and upscales it, instead of downscaling the large one. I only have a 1080p monitor, but I still notice that album and series cover thumbnails are not as crisp as they should be. If I scale the view to have 5 TV show covers in a row, the thumbnails are of low quality. If I change the scale of the view show only 4 in a row, they are as crisp as I would expect them to be. If I notice that on a 1080p monitor, it might look even more noticeable on a 4K monitor.
Last thing is loading. Usually the thumbnails are stored on the primary drive, which can be expected to be a SSD nowadays. Loading thumbnails from those large files requires a lot of random accesses. This is not a problem for SSDs, as long as drive queue is filled with lots of asynchronous requests, ideally from multiple threads. I don't know how thumbnail loading is done currently, but I expect a HDD optimized approach that loads files one after another, maybe in an optimized order. This would be worst case for an SSD since the queue depth and thread count would be both 1.

The quality of the thumbnails is currently the biggest downside of MC that I can think of. Performance is important too, but it is not that imminent. Improving the thumbnails would fix the first and substantially improve the second issue. It would also be quite important for image libraries. If I as a more technical person notice the problems in thumbnail quality, an artist or photographer will surely do so too.