| Author |
 Topic  |
|
|
Andy_Bell
United Kingdom
37 Posts |
 Posted - Apr 23 2020 : 02:29:07
|
ImageEn 9.0
C++ Builder 2007
Problem 1 - I can't get the thumbnails to show correctly if the image was taken in portrait mode:
I've set:
IEGlobalSettings()->CameraRawEngine = iecrAuto;
ImageEnFolderMView1->EnableAdjustOrientation = true;
ImageEnFolderMView1->EnableLoadEXIFThumbnails = true;
ielib32.dll is in the same folder as my test app.
I've tried various settings for ImageCache size and threads and am using ietFastThumb as the store type.
Despite these settings, RAW images (.crw, cr2 and .srw) do not rotate properly - portrait orientation images still display as landscape.
Problem 2
The component is fairly slow but with .srw (Samsung Raw) it is painfully so.
Am I doing something wrong?
Andy |
|
|
xequte
38186 Posts |
Posted - Apr 23 2020 : 21:43:03
|
Hi Andy
1. When you use EnableLoadEXIFThumbnails you may be affected by the way the camera has stored the thumbnail. What is the result when EnableLoadEXIFThumbnails = False?
2. We are using LibRaw for SRW decoding, so we are limited by the functionality that it provides. Have you considered these properties:
- TIOParams.RAW_GetEmbeddedJpeg
- TIOParams.RAW_HalfSize
Nigel
Xequte Software
www.imageen.com
|
 |
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - Apr 24 2020 : 04:19:44
|
Hi Nigel
A few things I've found:
When using LibRaw, no combination of:
ImageEnFolderMView1->EnableAdjustOrientation = true/false;
ImageEnFolderMView1->EnableLoadEXIFThumbnails = true/false;
makes any difference. In RAW files the orientation is definitely in the EXIF data so there's either something wrong with what I'm doing or it's a bug in ImageEn's usage of LibRaw.
Turning these on:
- TIOParams.RAW_GetEmbeddedJpeg
- TIOParams.RAW_HalfSize
does not speed up TImageEnFolderMView when using LibRaw.
I've tried using this, as commented in iexBitmaps.pas:
// Load the thumbnail (will automatically fall back to the embedded JPEG if there is no thumbnail)
ImageEnView.IO.Params.RAW_GetExifThumbnail := True
ImageEnView.IO.Params.RAW_GetEmbeddedJpeg := False;
ImageEnView.IO.Params.RAW_HalfSize := True; // In case there is no EXIF thumbnail or embedded JPEG
But it doesn't make for a speed improvement. (Shouldn't RAW_GetEmbeddedJpeg be true? I tried it ina any case - no difference).
If I switch to using WIC then the speed increase is huge and the orientation is always right regardless of the setting of EnableAdjustOrientation...
The problem with using WIC is that it doesn't support the latest RAW formats and I can't control when it does.
Weirdly, what does speed IE up a lot is turning off ImageCaching and ImageCachingUseDisk. I'd understand this if it was only the first time I visited a folder that caching slowed things down. But, in my test app, if I just switch between two folders the speed degradation with caching enabled remains constant. I've made the cache large (1000 images) to ensure it'a big enough. As I'm using SSD's it can't be disk speed that's causing the problem.
So, I think there are a few problems needing addressing:
1) When using LibRaw IE is not adjusting Thumbnail orientation. It seems to ignore EnableAdjustOrientation's setting. With WIC it also ignores the setting, but WIC seems to be returning the thumbnail correctly oriented.
2) There are serious speed issues when using Libraw. Photo Mechanic, Exposure X5 and others also use LibRaw and they are so much faster. The FastRawViewer (produced by the same people as LibRaw) is very fast... All of these are a little slower with Samsung .srw files but not dramatically so.
3) Image Caching seems to slow IE down, at least as far as thumbnails are concerned.
Andy |
|
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - Apr 24 2020 : 04:39:42
|
This video shows the speed issues I'm describing using LibRaw. I wouldn't expect ImageEn to achieve the speeds of PhotoMechanic and FastRawViewer, but currently it's not usable, espcially with .srw files
https://andybellphotography.com/ImageEn/ImageEn.mp4
Andy |
|
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - Apr 24 2020 : 08:29:13
|
Update - I've built the latest LibRaw and made a sample program to test what it can do... It seems it's 'thumbail' extraction actually extracts the embedded preview JPEG except for Samsungs SRW where it gets the full size image...
So, it seems that either SRW's don't have an embedded, small, preview JPEG or LibRaw is doing something wrong. I'll have to raise it with them.
Andy |
|
|
|
xequte
38186 Posts |
Posted - Apr 27 2020 : 04:11:01
|
Hi Andy
1. Yes, we are investigating that.
2. Looking at your video, it does not look as though the other apps are loading the image fresh from file. Either they have cached a thumbnail (to file) or they are using some other method to access a thumbnail.
There is no built-in permanent caching for TImageEnMView, so you might consider coding something for your app, e.g. by redirecting the loading in OnGetLoadFilename:
https://www.imageen.com/help/TImageEnMView.OnGetLoadFilename.html
3. ImageEnView1.IO.Params.RAW_GetEmbeddedJpeg works with some RAW formats, others do not appear to contain an embedded JPEG (according to LibRaw).
In ImageEn, embedded JPEG's smaller than:
IEGlobalSettings().MinimumRawEmbeddedJpegWidth
IEGlobalSettings().MinimumRawEmbeddedJpegHeight
Are ignored. Setting these values to 3 * the TImageEnMView thumbnail size can be effective for some RAW types.
We will make TImageEnMView handle this automatically for 9.0.1.
4. ImageEnView1.IO.Params.RAW_GetExifThumbnail := True; works though not all RAW formats support it.
TImageEnMView tends to ignore EnableLoadEXIFThumbnails because thumbnails are usually smaller than the display size. I may look at an option to force its usage, but that tends to give ugly, inconsistent thumbnails.
If you want to test an update, please email me.
Nigel
Xequte Software
www.imageen.com |
|
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - Apr 27 2020 : 16:05:33
|
Hi Nigel
Thanks for the reply.
My tests show a few things:
LibRaw returns what it can - with CR3, for example, it seems to return a full size jpeg even when I ask for a thumbnail. That may be a bug in LibRaw or a feature of CR3 (or both)
In my test code, opening the image using LibRaw and extracting the 'thumbnail' (often the full size jpeg) is rapid. Trying to downsize it using ImageEn's InputOutput and Processing components (attached to an IEBitmap) are what takes the time. Decompressing the JPEG takes the most time, naturally.
The other tools in my video are doing something very clever but they retain this speed even when pointed to the images for the first time. FastRawViewer working over an SD card attached via USB3 has to be seen to be believed.
I dug around the DLL's supplied with Photo Mechanic and it is using turbojpeg.dll - an open source Jpeg library. I fiddled around with this in C++ Builder and it has a clever trick of decompressing the JPEG AND downsizing it simultaneously, resulting in a dramatic speed improvement.
The code is simple (happy to share it with you) and I would say is 10+ times faster than regular JPEG decompressing. I remember Lead Tools (horribly overpriced) or the now defunct PolyImagePro using a similar technique. It's only good for creating thumbnails as it discards EXIF/IPTC and probably other things.
I'm not saying ImageEn is inefficient here - for doing serious work with JPEGs they need to be properly decompressed and other libraries I tried operate at the same speed.
But for thumbnail creation, a more aggressive approach seems to be a good one...
Andy
Andy |
|
|
|
xequte
38186 Posts |
Posted - Apr 27 2020 : 16:34:52
|
Hi Andy
I've been working on an update that optimizes the loading of the embedded JPEG by scaling down the size (in the same way as normal JPEG images are loaded at smaller sizes for thumbnails). This should make it much faster for most RAW loading. I don't believe there is a solution for images that only contain RAW content, other than some kind of file caching.
I don't know enough about the JPEG turbo to determine whether it is practical to support the libjpeg-turbo project. I will take a closer look at it after the release of 9.0.1.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
xequte
38186 Posts |
Posted - Apr 28 2020 : 01:24:52
|
Hi Andy
I tested around 350 various raw images to see whether they contained an embedded JPEG and if so, whether it benefited from scaled loading.
Here is a summary:
3FR: Get RAW
ARW: Get JPEG: 1/4
CR2: Get JPEG: 1/8 or Get RAW
CR3: Get JPEG: 1/8
CRW: Get JPEG: 1/4 or 1/8 or Get RAW
DNG: Get JPEG: 1/4 or 1/8 or Get RAW
ERF: Get JPEG: 1/2
KDC: Get JPEG: 1/8 or Get RAW
MDC: Get RAW
MEF: Get RAW
MOS: Get JPEG: 1/2
MRW: Get JPEG: 1/4
MRW: Get JPEG: 1/4 or Get RAW
NEF: Get JPEG: 1/2 or 1/8 or Get RAW
NRW: Get JPEG: 1/8 or Get RAW
ORF: Get JPEG: 1/8 or 1:1 or Get RAW
PEF: Get JPEG: 1/8
RAF: Get JPEG: 1/8
RAW: Get JPEG: 1/8 or Get RAW
RW2: Get JPEG: 1/8
SR2: Get JPEG: 1/2
SRF: Get JPEG: 1/4
SRW: Get JPEG: 1/8
attach/xequte/20204281121_RAW analysis.txt
So the good news is that half the formats should load faster if we are more proactive about using the embedded image and loading it as scaled. The bad news is that many of the formats are RAW only or RAW sometimes (possibly an older format, or the way LibRaw handles it), so there is little we can do about that.
My testing of the new code, was not overwhelming, unfortunately. With this set of images, overall loading time was reduced by about 30%. I tried other options, such as using WIC to handle the embedded JPEG loading, but scaled loading gave the best results.
I'm open to other suggestions for optimization, but I think ultimately, we will need to implement a disk caching system.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
xequte
38186 Posts |
Posted - Apr 28 2020 : 01:37:04
|
With regard to ImageCaching, this should always be enabled when StoreType = ietFastThumb. If you turn it off StoreType is changed to ietThumb. Are you saying that when you disable ImageCaching you get better *loading* performance? I cannot reproduce that.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
xequte
38186 Posts |
Posted - Apr 29 2020 : 03:21:53
|
FYI, we've decided to implement a disk cache in 9.0.1.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - Apr 30 2020 : 03:16:23
|
Hi Nigel
Thanks for all the info. I will have to revisit my tests, but I think I did get better performance without caching. But I may have set up something incorrectly.
I look forward to receiving V9.01 in due course.
My tests of JPEG Turbo have been encouraging so far...
Andy
Andy |
|
|
|
xequte
38186 Posts |
Posted - May 12 2020 : 17:44:03
|
Hi Andy
We've completed testing of libjpeg-turbo, and have found the performance no better than our existing JPEG-9 code.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - May 12 2020 : 19:26:57
|
Nigel
Thanks for the feedback. I'm finding by setting the scale to ioJPEG_EIGHTH I'm getting about the same speed as libjpeg-turbo. I didn't know about ioJPEG_EIGHTH when I started this thread.
For extracting RAW preview images I'm finding using LibRaw's unpack_thumb and dcraw_make_mem_thumb and loading the result into ImageEn via LoadFromBuffer to be faster than using ImageEn directly, regardless of the setting of RAW_GetExifThumbnail etc. I managed to build LibRaw in C++ Builder, which means I don't need to call its DLL and I wonder if that contributes to its speed...
ImageEn's speed improves a lot with setting GetMetaData to false, but that has too many drawbacks. LibRaw is still faster in any case and loads all the metadata I need.
But I've now removed libjpeg-turbo from my project...
Andy
Andy |
|
|
|
xequte
38186 Posts |
Posted - May 12 2020 : 23:57:50
|
Thanks for the feedback, Andy,
We'll look into that.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - May 28 2020 : 17:36:02
|
Nigel
The speed improvement in 9.1 is excellent! Thank you.
I've only had time to play with the TImageEnFolderMView demo and one thing I noticed was that, when I pointed it at a folder containing 450+ Canon CR3 files, the UI locked up for 30+ seconds, before finally showing the first screen's worth of pictures. This happens even with disk caching enabled...
Would it be quicker for me to just use a TImageEnMView component and tell it which images I want to see (my program already knows which images are in the folder)?
Of course, I'll experiment with it tomorrow, but it's worth you knowing that there seems to be a lock up with folders stuffed with images.
Andy
Andy |
|
|
|
xequte
38186 Posts |
Posted - May 29 2020 : 01:39:54
|
Hi Andy
Do you see the same lock-up when you use one of our demos, such as Multi\FolderMView?
Nigel
Xequte Software
www.imageen.com
|
|
|
|
Andy_Bell
United Kingdom
37 Posts |
Posted - May 29 2020 : 03:49:25
|
Nigel
It's that demo I'm using.
However, there's good news - this morning I pointed the software at the same images on my backup drive and the results were instant! As it's a USB drive, that's impressive.
The drive I was using last night is a hybrid drive and I wonder if, after quite a long day's usage, it was doing some 'work' on its SSD cache?? This morning it is performing better but nowhere near as fast as the backup...
I don't think ImageEn can be expected to fix a failing hard drive, lol! I will continue testing 9.1 over the coming days, but the speed improvement is really excellent!
Andy |
|
|
| |
Topic |
|
Search
AutoRotate and speed in TImageEnFolderMView
