I simply do: MyMemoryBlockA = MyPictureA.ToData(MyPictureFormat, Picture.QualityMaximum)
I have a original picture I resize in MyPictureA. MyMemoryBlockB contains the binarystream of the folderitem (picture) which is already in my target folder. And I do: MyPictureB = Picture.FromData(MyMemoryBlockB)
If the size (width height) of picture A and B are the same I compare the two MemoryBlock A and B.
If the picture are the same then I don’t save the new one, if different I replace the picture in the Target folder by the one I just resized.
This is a single command line to make a picture from MemoryBlock or vice versa then I don’t think there is anything to optimise.
Hmm. That’s not going to be a great way to compare images. Both PNG and JPG use compression to reduce their file sizes, which means that even if two files have exactly the same pixels, a byte-by-byte comparison of their data will very often not match because the compression algorithms don’t always produce the exact same bytes for a given image.
If the file sizes aren’t very large, it might be faster to simply assume that the file is changed if the pixel dimensions are different and replace it, instead of trying to determine if the pixels themselves differ in some way.
I’m not sure of your algorithm, but it might be faster to compare the full-size pictures rather than compressing first and comparing the compressed data?
Instead of this:
load picture
compress it (which is SLOW)
compare compressed data to another picture on disk
do this:
load picture A
load picture B
compare pixel data
Unfortunately, Xojo doesn’t have a fast way to say “Get me the RGBA data from a picture as a MemoryBlock” . There are ways to do it, but generally require Declares and only work on a single target OS (macOS, Windows…)
Another idea: what about just storing the file modification dates? If you last processed a file at timestamp X, and the timestamp is still X, it’s pretty reasonable to assume the file hasn’t changed.
This is the Gallery I make: JM-Poeles situ.
If, for example, we make a new stove and/or remove an old one. I will add or remove the photo in my gallery, I can change the order too. There are 3 pictures, the thumbs, the picture resized for screen, and the original (click the button on the bottom right with the cross arrows, sometimes our dealers need the original to make an advertisement or a poster).
When I update a Gallery, I start from the originals files (photos) stored somewhere on my HD, I resize it to make the thumb and resize it to make the screensize photo. If exists in the previous gallery I compare and if different I replace (I do it with the 3 pictures, thumb screensize and original).
Then, when I made my previous gallery, I compressed the image in JPG. I have to compress (JPG) the new one I just resize before compare it to the one I saved in JPG some months ago.
That was my problem in the other topic I gave the link in my previous post: I loaded the JPG I made months ago to compare it with the one I just resized. And they were different because one of them has been jpg compressed and uncompressed.
To answer to Eric, effectively if in a next version Xojo change the way it compress pictures, then all my images will be updated (except original as I just copy them, they can be jpg, png, tiff, etc.).
I can make 3 kinds of galleries, the one above, Best of Stoves and Our country (I re-made this last one with my Xojo software but I first made it more than 20 years ago with the software Galeries and after with iView Media Pro ). The user can make its own model, he just have to duplicate one of the 3 existing and modify it.
Interesting. I would treat the full size originals as the “truth” in this system and the screen size and thumbnails as read only derivatives. They are only created if the original is added or updated. Add functionality that enforces this policy.
And to go further: I wouldn’t even bother checking the originals. If someone replaces an original with another original, don’t bother checking if it matches the prior version. Just dump the screen size and thumbnail and make new ones - resizing and saving a picture are very fast functions and you’ll never have to worry that your algorithm will miss an image change.
The original pictures is optional, then not always there. If not there I could use the resized picture. I check the 3 and it is fast enough, 5 or 6 seconds for 54 photos (x 3 because I use originals).
NOte: I use a MacBookProM3.
That’s not terrible. However, it might still be faster to do it my way and ignore whatever pictures are already there. I suggest you disable the checks, forcing the code to always create the new files, and see how that performs. I’d be interested to hear the results.