GNOME Bugzilla – Bug 669818
Calculation of file size totally erroneous
Last modified: 2018-05-24 13:46:02 UTC
Created attachment 207275 [details] Screenshot: Save JPGs, file size precalculation The precalculation of the size of JPG files shows totally erroneous values that don't make any sense. The example in the attachement belongs zu a small picture of 53.7 kB uncompressed!
Hah hilarious :) This is the last 2.6 release though, can you check this with 2.7.4 please?
*** Bug 669825 has been marked as a duplicate of this bug. ***
grauerwolf55, can you reproduce problem with latest GIMP ?
Akhil Laddha, I didn't try it with 2.7.5. But I managed with GIMP 2.6.12 (because there are many important bugs fixed) using a simple trick: 1. Install GIMP 2.6.12-i686-septup.exe, but don't start it, because it's obviously broken! 2. In programs/gimp/lib/gimp/2.0/plugins you copy "file-jpeg.exe" to any folder (make a mental note, where :-) ), f.i. in "install" 3. Install GIMP 2.6.12-i686-septup-2.exe, but don't start it yet! 4. Recover the old "file-jpeg.exe" to programme/gimp/lib/gimp/2.0/plugins overwriting the new one! 5. Start GIMP et voilà: The precalculation of the size of jpg-files works. Since then I've worked many day's with GIMP. I had no problems at all, everything work's stable. There is still another bug when you open existing files. If you click on "force a new preview" you get a new thumb but no new file-size. There is only shown "5.0 EB", whatever that means. But I think, this is a little insignificant bug we can live with... Sorry for my bad english, it's not my native language, but I hope I could help you! Best regards Wolf
The 2.7.5 installer for Microsoft Windows even mentions this as a known problem in the installer dialog.
*** Bug 673006 has been marked as a duplicate of this bug. ***
*** Bug 673597 has been marked as a duplicate of this bug. ***
Same problem here with 2.6.12
Same in 2.8.0-rc1, although the file sizes has become considerably smaller - only 1.3GB instead of 5EB ;)
This bug was killing me on 2.6.12 always says 5.5 petabytes. 2.8-rc1 says 1.3GB always. It renders GIMP absolutely useless for saving jpegs. Thanks to the poster GrauerWolf55 above, I was able to install GIMP twice and swap the one file. Not fixed for over 2 months! For shame.
Yes, it's a total shame that absolutely none of our many windows users gives a shit about GIMP's problems on windows, steps up and fixes some. We have 0 (literally zero) windows developers, so either somebody comes and fixes this stuff, or we will have to drop support for windows. I am not joking.
*** Bug 673968 has been marked as a duplicate of this bug. ***
Don't resign, Mitch. We users are still able to work with files in GIMP and they are fine despite of the wrong displayed size. Perhaps the following informations are helpful: - The problem is only on Windows. The versions 2.6.12 for Linux and Mac don't have this issue. - The Windows' version 2.6.11 (Jernejs build) doesn't have this problem, too. A first glance at the code gave me the impression, that the function g_format_size vs. g_format_size_for_display may be the bugs root. There's one commit from 2011-09-30 18:30 on jpeg-save.c which looks 'interesting'. But I think the problem lies deeper in g_format_size, as this function is called from some more erroneous parts of GIMP, see bug #673006. I didn't find the functions definition in GIMPs code, but I found hints to GLib; also see the bugfix for bug #658467 and bug report #655336. So it seems, g_format_size is defined in GLib and the GLib version used in the Windows build is wrong. I currently have no time to come to grips with building GIMP and its dependencies on Windows, but maybe somebody else is able and willing to check this. Perhaps one of the Windows' version packagers (Jernej, Partha)? Hope I could help.
I don't know how file-jpeg.exe is built on Windows, but if file-jpeg.exe of 2.6.12 is wrong and it was built from the branch gimp-2-6, then it does not use neither g_format_size nor g_format_size_for_display see: http://git.gnome.org/browse/gimp/tree/plug-ins/file-jpeg/jpeg-save.c?h=gimp-2-6#n199 vs http://git.gnome.org/browse/gimp/tree/plug-ins/file-jpeg/jpeg-save.c?h=master#n206 The other thing that could be wrong is the usage of struct stat: docs suggest to use GStatBuf to avoid problems with the various combinations of mingw win32/64 and C libs I'd try a s/struct stat/GStatBuf/
I don't know exactly what they are talking about, but this user on gimpchat claims to have fixed it. I tried to follow but it isn't clear. Maybe someone here knows what they are talking about. http://www.gimpchat.com/viewtopic.php?f=4&t=4057&start=10#p50077 This is still present in the recently published 2.8 final for Windows.
Yeah; I already posted at both GIMPChat and GIMPUsers that this bug still exists. At least the tif bug is now patched. gimprc conflict with PSPI and User filter paths still unfortunately exists too. Oh well. :)
I think it is worth noting that on my Windows installations for 2.6.12 32-bit, the calculation is correct. For me, only 2.8.0 showed this bug.
*** Bug 675539 has been marked as a duplicate of this bug. ***
Additionaly bug seems persist only in 64 bit windows systems. On my all 32 bit systems it works good.
Ah; bet you they did patch those bugs but didn't do so for GIMP 64-bit then Szpakowski. :)
I look at the functions called for calculation and it looks like that: http://developer.gnome.org/glib/stable/glib-File-Utilities.html#g-stat and http://developer.gnome.org/glib/2.29/glib-Miscellaneous-Utility-Functions.html#g-format-size I don't have toolchain and time to check it, but remember that bug started something about 2.6.12, when compiled glib version changed. On function g_stat there is a mention about mess with 64 bit stat functions. So it might be a glib bug not only gimp.
Just fyi: I checked it again and removed all other software with its GLibs. But unfortunately on my Windows 7 (32 bit) system, GIMP 2.8.0 still shows 1.3 GB.
*** Bug 675724 has been marked as a duplicate of this bug. ***
The problem is in GLib. Cross compiling GLib with mingw64 (64 and 32 bits) I get this warning: gstdio.c: In function 'g_stat': gstdio.c:491:3: warning: passing argument 2 of '_wstat64i32' from incompatible pointer type [enabled by default] In file included from gstdio.c:27:0: .../sys/stat.h:128:15: note: expected 'struct _stat64i32 *' but argument is of type 'struct GStatBuf *' if I change struct stat with struct _stat64i32 in plug-ins/file-jpeg/jpeg-save.c I see the similar warning cross compiling GIMP, but then the plug-in shows the correct size. For the record the 1,3 G is the modification (or last access) time in seconds from Epoch. There's already a bug report for a similar issue with msvc6, dating back to 2010: Bug 619448.
Created attachment 213919 [details] test-case attaching a simple test program. compiled with mingw64 its output on Win7 64bits is: mingw64 version: 3.0 (_WIN64) helloworld stat is #define'd to '_stat64' _wstat is #define'd to '_wstat64i32' GStatBuf size: 1336831682 atime: 1336832956 mtime: 1336831682 ctime: 2031646 struct stat size: 1336831682 atime: 1336832956 mtime: 1336831682 ctime: 2031646 struct _stat64i32 size: 14 atime: 1336831682 mtime: 1336832956 ctime: 1336831682
moving to Product glib
*** Bug 675967 has been marked as a duplicate of this bug. ***
re comment 24, in gimp-2.8.0 (release src), I changed strut stat to strut _stat64i32, but did not see any change when look at jpeg preview in the file-open dialog.
*** Bug 675974 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > re comment 24, in gimp-2.8.0 (release src), I changed strut stat to strut > _stat64i32, but did not see any change when look at jpeg preview in the > file-open dialog. Yes changing jpeg plug-in only changes jpeg plug-in size computation. There are, IIRC, 16 occurrences of g_stat in GIMP's sources, one of them will be responsible of file open dialog.
You are correct. I modified the jpeg plug-in. The preview is controlled by gimpthumb-utils.c. Modifying this file fixes everything. Thanks, Partha
*** Bug 675978 has been marked as a duplicate of this bug. ***
*** Bug 675983 has been marked as a duplicate of this bug. ***
*** Bug 676098 has been marked as a duplicate of this bug. ***
*** Bug 676319 has been marked as a duplicate of this bug. ***
*** Bug 676354 has been marked as a duplicate of this bug. ***
*** Bug 676380 has been marked as a duplicate of this bug. ***
*** Bug 676459 has been marked as a duplicate of this bug. ***
*** Bug 677670 has been marked as a duplicate of this bug. ***
*** Bug 677756 has been marked as a duplicate of this bug. ***
*** Bug 677811 has been marked as a duplicate of this bug. ***
*** Bug 677957 has been marked as a duplicate of this bug. ***
*** Bug 678242 has been marked as a duplicate of this bug. ***
*** Bug 678260 has been marked as a duplicate of this bug. ***
*** Bug 678498 has been marked as a duplicate of this bug. ***
*** Bug 679096 has been marked as a duplicate of this bug. ***
*** Bug 679119 has been marked as a duplicate of this bug. ***
*** Bug 679597 has been marked as a duplicate of this bug. ***
*** Bug 679653 has been marked as a duplicate of this bug. ***
*** Bug 680037 has been marked as a duplicate of this bug. ***
*** Bug 680474 has been marked as a duplicate of this bug. ***
I was going to use GIMP for resizing photos to be 1 MB or smaller for web uploading, but ran into this bug, making my process much more difficult. I'll just have to use Phatch for that instead (it's better suited to batch resizing anyway). Hopefully this gets fixed soon.
*** Bug 681655 has been marked as a duplicate of this bug. ***
*** Bug 682497 has been marked as a duplicate of this bug. ***
*** Bug 682522 has been marked as a duplicate of this bug. ***
*** Bug 683368 has been marked as a duplicate of this bug. ***
The saved preview size is always a little bigger then the actual size is now, but I can live with that. :)
(In reply to comment #58) > The saved preview size is always a little bigger then the actual size is now, > but I can live with that. :) Is it a little bigger, or is GIMP using base 10 for size calculation (1 MB = 1000000 bytes) and Windows is using base 2 (1 MB = 1048576 bytes)?
They fixed this issue in 2.8.2; you need to download and update GIMP cbodendein. :)
(In reply to comment #60) > They fixed this issue in 2.8.2; you need to download and update GIMP > cbodendein. :) I have 2.8.2. You were saying that preview size is a little bigger in 2.8.2 than the actual, but I am saying that I think the preview size is correct, but GIMP and Windows use different units to measure file size.
Oh; I see what you are saying now. Many sites I visit require a file size of 200K or less. At this size, it's usually around 3 or 4K smaller then what the GIMP preview size says it will be (a good thing; lol). This small bug is no where near what was the issue for 2.8.0. lol :)
I just tried to get the filesize in GIMP on exporting to JPEG and see 'unknown' because g_file_query_info returns nothing valuable. Product: GLib 2.36.4 (in GIMP master, Mike Hennings nightly build from 7.10.2013) Platform: Windows 8 (64 bit) It works fine on XP (32 bit), Windows 7 (32 bit) and Windows Vista (64 bit), so I assume it's something in Windows 8.
After the update to glib2 2.38.0 in GIMP master (Mike Hennings nightly build from 15.10.2013) nothing has changed: it works on Win7 (32 bit), but not on Win8 (64 bit). The JPEG export dialog in GIMP still shows filesize 'unknown' there.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/509.