Updated UPX to 5.1.1.
Thank you for the response! You are right, I was being a bit naive about the work being put into reading files. THAT BEING SAID ... does the verification need to be done at the moment files are loaded into FO? What if that verification was done at the moment the file is about to be optimized? It would have the benefit of boosting the loading of files initially while not loosing any of the verifications done by FO. I figure, you're gonna work on the file anyways so might as well do most of it in the...
Some minor optimizations and code cleanup
Thank you so much for your analysis Louis Horvath -. In fact the problem is not just adding the files to the list, which as usually implemented is exponential. The problem is the code at FO does a lot more things that your AutoIt sample. You can take a look at the core here: https://sourceforge.net/p/nikkhokkho/code/HEAD/tree/trunk/FileOptimizer/Source/cppMain.cpp#l2827 1) For each file, it reads its attributes in order to be able to recurse. 2) For files it gets its file size. 3) For files it reads...
I did a little script in AutoIT3 that shows how long it takes for an interpreted language to load 4533 files into an array. Full comments so you can figure out what each line does. TLDR : According to AutoIT It takes ~150 miliseconds. ; Create array from a specified folder. Compare with FileOptimizer Opt("MustDeclareVars", 1) ; All variables must be created before they are used. #include <Array.au3> #include <File.au3> #include <Timers.au3> Global $aDir ; Will hold an array to contain filenames Global...
Rebooted my machine, same folder takes ~42 seconds to load. When in cache it takes ~22 seconds to load. Note : dir command is nearly instantaneous. It's not a file system slowdown.
This is not a bug per se but when I load files into FileOptimizer it looks like a very laborious process I have a folder with ~4500 files and it takes about 15-20 seconds to display the listing of the files During that time FileOptimizer doesn't say anything and the interface is frozen. I'm not noticing any wild CPU usage. I'm assuming FileOptimizer is already using the system cache to accelerate the process I've done programming before and this is a simple 2D array: filename + size. This issue is...
This is not a bug per se but when I load files into FileOptimizer it looks like a very laborious process I have a folder with ~4500 files and it takes about 15-20 seconds to display the listing of the files During that time FileOptimizer doesn't say anything and the interface is frozen. I'm not noticing any wild CPU usage. I'm assuming FileOptimizer is already using the system cache to accelerate the process I've done programming before and this is a simple 2D array: filename + size. This issue is...
Possible underflow at bytes saved
Abría que analizar esa fotografía en cuestión, pero es poco probable que los metadatos sean 14 MB. Lo que ocurre es que si quieres conservar metadatos, FileOptimizer no usa todos los plugins disponibles, ya que algunos de ellos no conservan esa información, por lo que además del espacio de los datos, optimiza menos.
Hay algo que no me cuadra. Optimizo una fotografía de 20 MB permitiendo pérdida de datos. Si no mantengo los metadatos me la deja en 6 MB pero si mantengo los metadatos "solo" la deja en 14 MB. ¿Tanto ocupan los metadatos en una fotografía? No soy entendido en informática pero intuitivamente me parece extraño que en una foto de 14MB 8 sean de metadatos.
Hay algo que no me cuadra. Optimizo una fotografía de 20 MB permitiendo pérdida de datos. Si no mantengo los metadatos me la deja en 6 MB pero si mantengo los metadatos "solo" la deja en 14 MB. ¿Tanto ocupan los metadatos en una fotografía? No soy entendido en informática pero intuitivamente me parece extaño que en una foto de 14MB 8 sean de metadatos.
Efectivamente. La opción es no guardar los metadatos, y entonces los resultados serán equivalentes o incluso mejores a la 17. La trampa es que debido a un problema, la 17.00 no siempre mantenía los metadatos.
Muchas gracias. En lo personal no puedo hacer ningún tipo de reclamación que tu no puedas hacer. No infringe nada de FileOptimizer, aunque sí de Ghostcript y otros.
Sí, eso me pareció. Por eso mandé el mensaje por si no sabías la existencia de este pirata y si podías hacer algún tipo de reclamación. Muchas gracias por tu esfuerzo.
Cuando permites la pérdida de calidad la version 17.10 comprime menos de la mitad que la version 17.0. A cambio mantiene los metadatos referidos al dispositivo con que fueron tomadas las fotos o la localización que en la version 17.0 se perdían.
Cuando permites la perdida de calidad la version 17.10 comprime menos de la mitad que la version 17.0. A cambio mantiene los metadatos referidos al dispositivo con que fueron tomadas las fotos o la localización que en la version 17.0 se perdían.
fileoptimizerapp.dezeiraud.com Encontré esto en la tienda de Microsoft. ¿Es la misma aplicación?
No es la misma aplicación José Luis González Díaz. Si descargas su MSIX ( 62041DezeiraudGatan.FileOptimizer_1.8.4.0_x64__jbdvxd7n7677j.Msix ) verás que han tomado la misma idea del FileOptimizer genuino, es decir, este mismo, y la han implementado en un interfaz de .NET mucho más sencillo y con muchos menos plugins incluidos. Todo ello cobrando 1,99€ por su "compra". En realidad eso es algo ilegal, no por mi FileOptimizer, sino porque están rompiendo la licencia de varios plugins, entre ellos Ghostcript...
https://fileoptimizerapp.dezeiraud.com/ Encontré esto en la tienda de Microsoft. ¿Es la misma aplicación?
Updated to guetzli-cuda-opencl 2.2.1 x64 (Reiner Schweinlin)
There is still something wrong, I think! I added different versions of cjpegli.exe to the plugin folders of V. 17.10 and now I'm sure that V. 17.10 is skipping cjpegli. It doesn't show up under "status" and V. 16.90 is still compressing much better than V. 17.10! But caution: In 16.90 x64 the combination of cjpegli and guetzli is destroying files! With guetzli.exe renamed to guetzli.exe.old V. 16.90 x64 is working, but even with this workaround the results of 16.90 x86 are little better.
Thank you so much for the testing. I have been reviewing the initialization code, and have not found any problems. So I guess it should be a bug in latest C++ Builder combined with Windows 10. This will also confirm that when patched gets better.
Thank you so much Renard Voß. I have restored the Win32 EXE (maybe it was accidentally removed): https://sourceforge.net/p/nikkhokkho/code/1863/ Regarding the changes, in 17.10 I fixed the keep metadata, but probably the change comes from 17.00 when I switched to Google builds. Have reverted it, and now added official ones.
Fixed missing Win32 cjpegli 0.11.1 (Renard Voß #144)
...futhermore the compression rates of 16.90 x86 with cjpegli.exe x86 are much higher than the ones of 17.10 x64 without visible differences! Did you change the cjpegli command, Javier?
Unfortunately adding cjpegli.exe to the Plugins32 folder didn't help in V. 17.10. It helped in V. 16.90.
cjpegli.exe has 0 KB in Plugins32 folder of FileOptimizer 17.10 and 17.00
I see! Thanks for the quick reply Nikkho. Since I'm mostly working on Android games, I didn't really notice a big difference, they honestly seem the same to me. Still, it would be cool to have an option for some lossy optimization that matches the size and speed of TinyPng.
AFAIK, TinyPNG is lossy, and the main focus of FO is to be lossless, even if with the time, some lossy capabilities have been added.
Hello everyone, First I want to say that FileOptimizer is a great program! I used it to optimize over 5000 assets for my game. I just want to know, if there is a way to match the optimize speed of TinyPNG and size? I noticed that even though the program uses a lot of plug-ins and takes longer to finish, the final size is still bigger than when I optimize my assets in TinyPng. Maybe I'm doing something wrong? I really prefer FileOptimizer cause it allows me to optimize a lot of files, without having...
Tested versions 05092025 and 08102025, started 10 times from icon; older version (FileOptimizer 17.10.2857 (x64) Sep 5 2025) failed 4 times with read and write errors. newer version (FileOptimizer 17.10.2857 (x64) Oct 8 2025) failed 1 time with write error, see attached image. So newer is obviously better with W10. Both versions started w/o problems after I clicked ok to those error-messages. So still no serious issue IMO, but still interesting.
Same conditions, same issues (pls see attached screenshots). Just out of curiosity, what happens around offset 0x410EF (since this is common to otherwise very different environments ~ at least here)
I have updated to lastest C++ Builder 13 September Update Patch, and compiled all binaries. Can you test with them? https://sourceforge.net/p/nikkhokkho/code/HEAD/tree/trunk/FileOptimizer/Win64x/Release/
Upgraded to C++ Builder 13 September Patch
Thank you so much. qpdf was already added in FO 17.10: qpdf.exe --compress-streams=y --decode-level=generalized --recompress-flate --compression-level=9 --optimize-images --object-streams=generate Regarding FO, since ads as well as donation are optional, I would say is not commercial. Indeed you can donate to LibreOffice and no one would say it is commercial.
Thank you so much. I was not aware on qpdf, so I would take a look to it. Regarding FO, since ads as well as donation are optional, I would say is not commercial. Indeed you can donate to LibreOffice and no one would say it is commercial.
In fact, pdfsizeopt is "only" a wrapper like FO, but there are some interesting differences: pdfsizeopt produces better results, especially when pdf files contain png images. Then the filesize is usually about 20% smaller. pdfsizeopt doesn't keep file properties pdfsizeopt sometimes destroys contents of pdf files pdfsizeopt uses qpdf instead of cpdf pdfsizeopt and/or qpdf sets pdf file version to version 1 and deletes the file ID (while cpdf keeps the file ID although cpdf sets the pdf file version...
I've seen it. Is Photoshop issue. All other programs open optimised files corectly, only Photoshop display a gray-like image with artefacts (improper decoding). I can confirm it on Photoshop CS6.
So it's not Only my problem - kind of happy (or not!) to hear. Because Nikkho just mentioned "FO 17.10 being upgraded to latest C++ Builder 13". Maybe some kind of a compatibility-problem with C++ Builder 13? More error-reports are certainly needed... This might be a problem to someone who tries to automate/script FO. Or they just have to use older versions, no such problem with pre-17 -versions. And even 17.10 seems to be working OK for 99% of users?
Same issue here, with some additional content: on a win2019 server, the issue (Access violation, before the main window ~ close, then everything is nominal), appears every time I run the program as Administrator, but never (so far) when I run it as regular user on a Linux machine (ubuntu 24.04, wine 9.0, 64bit prefix configured as Win7), the issue appears every time. Hope this helps, TIA and keep up the good work!
Updated jpegoptim to 1.5.6 x64
Thank you so much. It could be either related to W10 Updates as you state (I myself am running W11 with no issues), or either due to FO 17.10 being upgraded to latest C++ Builder 13; or maybe an incompatibility with both. I shall review the initialization code before main window opens, maybe there is a problem never noticed before, but it does not seem very probable.
Happens immediately before actual FO-window opens, and FO always starts/works ok when I click OK-button in error window. I open FO by directly starting .EXE (FileOptimizer64.exe), I don't use automation or scripts or cmdline-options with FO. It wouldn't surprise me if this has something to do w/ soon ending W10-updates? But no other issues with W10 so far. And this is 1st time I've seen this. Just strange. But if there are no other reports of such issues maybe we should forget about this one? FO...
Thank you for your report. Can you please provide more details? When does the error exactly happen? Is after doing some action or while loading? Is the main window showing when the popup appears or not yet visible? If you launch FO with no parameters the error still happens occasionaly?
Strange startup-bug in FileOptimizer 17
2nd try to add attachment...
2nd try to add attachment...
2nd try to add attachment...
Strange startup-bug in FileOptimizer 17
Thank you so much for your help. I have integrated it in the source, and will be available in the next FO release: https://sourceforge.net/p/nikkhokkho/code/1859/ Regards.
Added hungarian translation (kekmacska)
Hello I have completed FileOptimizer's translation from English to Hungarian. I'll attach the .po file in question. If it is good enough, please consider including it in the software's next release. Thank you. kekmacska
17.10
Updated ffmpeg to 8.0.0 x64
- Updated internal EdgeView to 1.0.3065.
Bugs - cjpegli deletes metadata & cpegli missing in Plugins32 folder
Sorry for the delay. I am on holidays, but have been able to solve it. https://sourceforge.net/p/nikkhokkho/code/1855/
Fixed cjpegli removing metadata (Renard Voß, Danylo Surmai) #140
Hi sorry to ping, but is there any estimation on fix on EXIF data removing? thx!
Thank you for the solution Nils Ax. Indeed that feature was added on version 10: 10.00 - 2017/07/21 (5th aniversary release) - Added EnableCache=false INI setting to enable cache of already optimized files, so they are not reoptimized each time.
Nevermind. Found a feature called 'Enable Cache' in FileOptimizer that seems to be doing the exact same thing.
That was easy. Preliminar qpdf support is also added: https://sourceforge.net/p/nikkhokkho/code/1854/
Thank you. qpdf (https://github.com/qpdf/qpdf) sounds interesting. I will investigate it when some time!
Thank you so much. DNG support is preliminary added: https://sourceforge.net/p/nikkhokkho/code/1853/
- Added tinydng-cli to the TIFF toolchain (avalanch).
Chatgpt is suggesting this. tinyDNG – Open-source and Free This tool wraps a JXL-compressed payload inside the DNG container, preserving metadata and Raw structure. It supports a lossless flag (-l) for truly lossless compression. Typical result: your DNG might shrink from, say, 33 MB to around 25 MB in purely lossless mode. If you're willing to accept visually lossless compression (with more aggressive file reduction), you can get down to around 4.5 MB Super User . Example usage: tinydng-cli --input...
Chatgpt is suggesting this. tinyDNG – Open-source and Free This tool wraps a JXL-compressed payload inside the DNG container, preserving metadata and Raw structure. It supports a lossless flag (-l) for truly lossless compression. Typical result: your DNG might shrink from, say, 33 MB to around 25 MB in purely lossless mode. If you're willing to accept visually lossless compression (with more aggressive file reduction), you can get down to around 4.5 MB Super User . Example usage: tinydng-cli --input...
Ok I see what you mean. I asked chatgpt about it and it returned this however. Most Efficient Overall (Best Compression) Ghostscript Consistently reduces PDFs the most because it can downsample images, re-encode them (JPEG/ZIP), and strip unused objects. Offers different -dPDFSETTINGS presets: /screen → very small, lower quality /ebook → good balance /printer or /prepress → higher quality, larger size Can beat most other tools in size reduction when you allow lossy compression. 👉 If your priority...
FileOptimizer is just a frontend using third-party opensource plugins. Unfortunately I am not aware of any accepting lossless compression.
I tried to recompress DNG file with FileOptimizer. It did not compress much. In the newest version of the format they added suport for JXL compression which can significantly reduce the size of the DNG file. Couldn't find a way to turn on lossles compression in Adobes own DNG converter tool. Here is a qoute from Wikipedia "2023, June: Specification version 1.7.0.0 published. JPEG XL added as a compression method. In September, 1.7.1.0 was published as a minor refresh with additional compression ...
Great! Thanks.
Hi Nikkoh, many thanks for your quick answer and explanation. That solves my problem. I've even created a new INI file but missed that comment regarding comma as it was too far right in my editor.
DisablePluginMask no longer working
You are right. After 16.80, due to a request, separator was changed from ; to , It is documented in the changelog as well as in the tree: https://sourceforge.net/p/nikkhokkho/code/1835/
DisablePluginMask no longer working
- Updated SQLite to 3.50.4 x86 and x64 Visual C++ 2022 custom builds.
What do you have in mind? Just installed PDFGear and I do not see any command-line tool inside. Not sure if the other GUI ones can be launched via command line.
pdfgear has some pretty good pdf compression, have you tried implementing that software into yours?
Updated ffmpeg to 7.1.1 x64
Thank you so much for the effort. It has been added: https://sourceforge.net/p/nikkhokkho/code/1850/
Added japanese translation (Re*Index. (ot_inc))
I created a file with the Japanese translation file.
I created a file with the Japanese translation .
I have compiled updated EXE just in case you want to test them before next FileOptimizer version release: https://sourceforge.net/p/nikkhokkho/code/1849/
Update EXEs
I have found the issue. It is in the execution of Leanify. Since ODG is a ZIP file, it seems that FileOptimizer is only honoring Recurse ZIP files in ZIP extensions and not in ODG. Also it was not passing the JPEG keep metadata, so I have hopefully fixed it and will be available in next FO release. https://sourceforge.net/p/nikkhokkho/code/1848/
Fixed not honoring keep metadata inside ODG from the ZIP toolchain (Arturs Pupausis)
Here are the sample files. Tested 1000000000000320000002A8DD603A86.jpg file with diffchecker com, images are not the same also the size difference is quite large.
Thanks. Is it possible to have a sample of the ODG file?
JXL compression looks to be fine. I was referring to JPGs in .odg file. Sorry for the confusion, simply my screenshots happened to be in .jxl format.
Thank you so much for your reportand your support @Arturs Pupausis. I have isolated the problem on ImageMagick. FileOptimizer is running it as: magick.exe convert "2025-07-23 200941.jxl" -quiet jxl:effort=9 "2025-07-23 200941.jxl" It should behave lossless, so I will need to investigate if there is a bug on ImageMagick. Thanks.
Compressing .odg file - it compresses JPGs in lossy even when lossy is disabled. Using Best compression and copy metadata is checked. It also deletes Exif data. Running File optimizer 17.0.0.2842.