After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 538728 - PNG files are saved with smaller bitdepth and pixel depth
PNG files are saved with smaller bitdepth and pixel depth
Status: RESOLVED DUPLICATE of bug 74224
Product: GIMP
Classification: Other
Component: General
2.5.x
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2008-06-17 07:56 UTC by Vidar Hoel
Modified: 2008-10-30 20:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The original, just resized (with Image Magick) (199.49 KB, image/png)
2008-06-17 08:03 UTC, Vidar Hoel
Details
The same image, after GIMP has saved it. (101.14 KB, image/png)
2008-06-17 08:05 UTC, Vidar Hoel
Details

Description Vidar Hoel 2008-06-17 07:56:21 UTC
Please describe the problem:
I installed (from source) babl-0.0.22, gegl-0.0.18 and gimp-2.5.1.

From ufraw I have produced a PNG-file, and this is the info pngtool gives:

dsc_0118.png...
  Image Width: 2014 Image Length: 1712
  Bitdepth (Bits/Sample): 16
  Channels (Samples/Pixel): 3
  Pixel depth (Pixel Depth): 48
  Colour Type (Photometric Interpretation): RGB 
  Image filter: Single row per byte filter 
  Interlacing: No interlacing 
  Compression Scheme: Deflate method 8, 32k window
  Resolution: 0, 0 (unit unknown)
  FillOrder: msb-to-lsb
  Byte Order: Network (Big Endian)
  Number of text strings: 3 of 9
    Software (tEXt uncompressed): UFRaw
    Source (tEXt uncompressed): NIKOND40
    Raw profile type exif (tEXt uncompressed): [.. cut ..]

I open the file in Gimp, and without doing anything else, I save it with a new filename: gimp.png

This is what pngtool states about this new file:

gimp.png...
  Image Width: 2014 Image Length: 1712
  Bitdepth (Bits/Sample): 8
  Channels (Samples/Pixel): 3
  Pixel depth (Pixel Depth): 24
  Colour Type (Photometric Interpretation): RGB 
  Image filter: Single row per byte filter 
  Interlacing: No interlacing 
  Compression Scheme: Deflate method 8, 32k window
  Resolution: 2835, 2835 (pixels per meter)
  FillOrder: msb-to-lsb
  Byte Order: Network (Big Endian)
  Number of text strings: 0 of 0
  Offsets: 0, 0

As you see, both bitdepth and pixel depth are reduced. In addition the filesize has been reduced to almost 50%. Does not this mean that data in the image is lost?

Steps to reproduce:
1. Open the png-file in GIMP
2. Save the png-file in GIMP
3. 


Actual results:
Both bitdepth and pixel depth are reduced.

Expected results:
The file should be 100% similar

Does this happen every time?
Yes

Other information:
In addtition, the exif-information is lost, even I compiles Gimp with libexif-support. But this is covered in bug #56443
Comment 1 Vidar Hoel 2008-06-17 08:03:47 UTC
Created attachment 112890 [details]
The original, just resized (with Image Magick)

This is the image produced by ufraw, just resized with Image Magick:
convert -resize 10% dsc_0118.png small.png
Comment 2 Vidar Hoel 2008-06-17 08:05:25 UTC
Created attachment 112891 [details]
The same image, after GIMP has saved it.

The same as small.png, but after GIMP has just opended and saved it.
Comment 3 Michael Schumacher 2008-06-17 08:18:10 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 74224 ***
Comment 4 Sven Neumann 2008-07-02 21:39:43 UTC
The actual bug here is that the PNG loader, unlike the TIFF load plug-in, does not inform the user that information is discarded when a 16bit PNG image is opened. If you want us to improve that, feel free to open a bug report for it.