png resolution not imported
Bug Description
It seems that when importing a png it's resolution it's
not loaded. So it can be bigger or smaller than the
original.
Related branches
- jazzynico: Approve on 2012-07-23
- Diff: 517 lines (+417/-9)7 files modifiedconfigure.ac (+19/-1)
src/extension/internal/Makefile_insert (+4/-1)
src/extension/internal/gdkpixbuf-input.cpp (+29/-4)
src/extension/internal/image-resolution.cpp (+318/-0)
src/extension/internal/image-resolution.h (+40/-0)
src/ui/dialog/inkscape-preferences.cpp (+5/-2)
src/ui/dialog/inkscape-preferences.h (+2/-1)
- jazzynico: Approve on 2012-09-20
- su_v (community): Approve on 2012-09-20
- Diff: 61 lines (+9/-4)3 files modifiedsrc/extension/internal/gdkpixbuf-input.cpp (+5/-4)
src/ui/dialog/inkscape-preferences.cpp (+3/-0)
src/ui/dialog/inkscape-preferences.h (+1/-0)
Behavior verified. Importing a 72 DPI image and a 300 DPI
image both import with identical final size.
Presumably pngs at resolutions other than 72 dpi should be
normalized during loading...?
I think the correct solution is just to add a scale
transform to the imported object, calculated from PNG dpi.
For 72 dpi no scale is needed. That's the resolution where
each pixel gets to one point size, which is what our
imported does now.
Imported png images now are scaled by their dpi relative to
72 as a base.
Oops. There were build issues with the prior kludge, so the
final update had to be backed out.
resolution - see also
1029755 png resolution not imported
1492545 PNG resolution value not exported
I can confirm the problem, and it also applies to other
image file types.
JonCruz explained that it's to do with the fact that the
GTK+ loader does not preserve DPI.
However there is a fairly simple work around - import the
image, and adjust the size and measurement units in the
toolbar - and be sure to click on the lock first to preserve
aspect ratio.
- kattekrab
http://
under Question 3.6.
it states that import of bitmap will always be at 90dpi.
Easy idea to solve this problem:
in Inkscape > File > Inkscape Preferences > Import/Export > Default import resolution: 300 dpi
All my bitmaps are in 300dpi, so at least for my case this would solve the problem.
btw: Nice work, overall Inkscape is a fine software!
I created a small patch to use the "Default export resolution" preference also for default bitmap import resolution, see attached. Would you be interested in receiving a further patch that creates a separate "Default import resolution" preference? I am also contemplating a third patch that would use ImageMagick to query the resolution of a loaded bitmap, which could be enabled/disabled by a new "Use resolution from bitmap file" preference. A final patch could add a "Import resolution" option to the "GDK pixbuf Input" dialog. (But this is problematic in combination with the new "Always embed/Always link/ask" preference which prevents the dialog from showing up.) I also created a new branch at lp:~dawagenaar/inkscape/import-res-daw for this work.
Why not using imageMagick? It's quite easy to do and doesn't require lots of code.
Basic patch attached.
Patch tested on Windows XP, Inkscape revision 11533, PNG, GIF and JPEG files. Still needs to be improved...
JazzyNico wrote:
> Patch tested (…). Still needs to be improved...
The patch from comment #11, or the updated version from the linked merge proposal which includes a separate preference setting for import? (just to make sure that I test the same version on OS X, if time permits)
> The patch from comment #11, or the updated version from the linked merge proposal
The patch from comment #12...
Branch merged, trunk revision 11567.
Thanks, Daniel!
A couple files were omitted, but I have committed them to trunk. Daniel, that was the first patch I'm aware of us accepting from you, one more and we'll grant you commit access to the project if you're interested. Thanks for your work!
> A couple files were omitted.
Oups. My write it 100 times punishment: "I will not forget to bzr add"...
<somehwat off-topic>
Now that many images are likely to be imported scaled, taking care of reported issues with regard to SVG compliance might need to be further investigated with higher priority:
- Bug #461467 in Inkscape: “Image scale saved incorrectly”
- Bug #616717 “Resized bitmap images are rendered differently by Firefox or Batik ('preserveAspec
- Bug #924377 “wrong default value for image preserveAspectR
as well as
- Bug #371297 “Feature request: Do not optimize transforms on Image objects”
a) for bitmap images imported via Inkscape, one might consider to simply add the 'preserveAspect
b) when rendering externally created SVG files, Inkscape's renderer needs to respect the default value 'xMidYMid' (Force uniform scaling) as defined in the SVG 1.1 spec, if the attribute 'preserveAspect
</somehwat off-topic>
Testing PNG import with r11572 (Mac OS X 10.5.8 (i386), OS X 10.7.4 (64bit), default (new) preferences:
PNG images exported with Inkscape often have a dpi of slightly below 90 stored in the bitmap image (probably a rounding error with Inkscape's export (?)). In current trunk this results in slightly scaled images when importing them again in Inkscape, creating non-integer pixel sizes for the width and height of the bitmap images.
Example:
SVG: unstroked rectangle, 400 x 400px
PNG export (90dpi): Image size 400 x 400 pixels, Image DPI 89.98 pixels/inch
PNG import in current trunk: width x height 400.03467 x 400.03467 px
Would it be feasable to implement some kind of threshold to avoid such unnecessary scaling?
(The differences are tiny but might build up to unexpected anti-aliasing effects when exporting a document with such imported images to bitmap again.)
> PNG images exported with Inkscape often have a dpi of slightly below
> 90 stored in the bitmap image [...] In current trunk this results in
> slightly scaled images when importing them again in Inkscape, creating
> non-integer pixel sizes for the width and height of the bitmap images.
> [...] Would it be feasable to implement some kind of threshold to
> avoid such unnecessary scaling?
It would certainly be feasible, and in fact quite easy, but we should
think about the details with some care. One simple possibility is to
assume that a stated image resolution between 89.95 and 90.05 DPI means
90 DPI on import. Should we then also correct 71.95–72.05 DPI to 72 DPI?
How about correcting 99.95–100.05 DPI to 100 DPI? Or 337.95–338.05 DPI
to 339 DPI? Or 99.95–100.05 pixels per cm to 100 pixels per cm? Those
are probably unlikely cases, but I would rather implement a heuristic
that we won't regret in six months.
My inkling would be to round to integer any resolution that is within
0.05 DPI of an integer. One alternative could be to check upon import if
both the width and the height of the image or within 0.1 pixels of an
integer and, if so, adjust the resolution. But I am less in favor of
that, because it raises issues with aspect ratios.
I think some discussion is warranted. Anybody has any ideas?
Another solution (or workaround):
Since the issue I mention obviously seems to root in Inkscape's faulty (or imprecise) export routines, and only affects Inkscape users eager to have full control over aligning objects to the pixel grid as defined by Inkscsape's internal (for now hard-coded) resolution (90 dpi):
- allow to opt out of the new feature (same choices as with 'embed/link': always/never/ask):
i.e. optionally import images as before: 1px in the bitmap image ≃ 1px in Inkscape (SVG user unit)
It is not quite true that it only happens with images exported from
inkscape. Many other bitmaps in my collection have a resolution of
299.99 dpi according to libexif. I suspect there is some inappropriate
round-down happening in other parts of the tool chain. AFAIK exif stores
resolution as integer fractions, so I suspect somewhere the number 300.0
ends up being represented as 29,999/100 by whatever logic converts reals
to fractions in whatever exif library is used by my digital camera.
An opt-out would be a reasonable work-around, although I am hesitant to
add another little popup to the import process. Especially for new
users, I think it would be confusing to first be asked about link/embed
and then about resolution handling. Perhaps a single popup can be
devised that asks either or both questions depending on which feature is
on "always ask".
Hi,
In r11572 (Windows build from skydrive), PNG files are correctly imported when resolution is stored (export from GIMP 2.8), but not when resolution is not stored.
JPEG files seems to be not impacted by the patch, the files are not imported scaled.
Or tell me what I'm doing wrong ?
J-Ch
Hi J-Ch,
Thanks for the report. Can you be more specific: you say that PNG files
are not correctly imported when resolution is not stored. What did you
expect to happen, and what actually happened? Also, what is the "Default
import resolution" for bitmaps (in the "Bitmaps" page of the
"Preferences"? (Edit->Preferences, or Shift-Ctrl-P.)
Thanks, Daniel
with respect to image resolution, and the difficulty of maintaining a consistent resolution, the problem appears to be the rather unusual units used by PNG files. The PNG file stores resolution in units of dots/meter, in the pHYs chunk in the header. This means that 90 dpi will get converted to 3543.3 dots per meter, which will get rounded off to 3543, and when you re-import this file, then the dpi will be less than 90 consistently.
One possible workaround would be to force the dpi to be in units of 0.1 dpi when importing a png file, I mean round it off to the nearest 0.1 dpi. This would be consistent with the resolution used in the spinboxes on the png export dialog. The resolution of 0.1 dpi is less precise than the PNG resolution because 0.1 dpi is roughly 4 pixels/meter. So there would be little danger of generating random garbage caused by round off error.
I think rounding to nearest 0.1 dpi is a very good solution. I will
implement it.
@Daniel Wagenaar
Hi Daniel,
Three files here :
Fiche_01.png : http://
Fiche_02.png : http://
Fiche_03.jpg : http://
My job is to redraw the sketch with Inkscape, in A4 format.
This is the same document (A4), scan from GIMP 2.8 at 200 dpi and exported 3 times with differents options.
In the first PNG, I have selected 'Save resolution" in the export box (see here : http://
In the second document, I don't select it.
And the third is a JPG export, from GIMP too.
The following screenshot show this 3 pictures imported in Inkscape r11577 :
http://
Only the first is good (for me).
The "Default import resolution" is 90 (by default)
Note : when I put 200 in "Default import resolution", all files are correctly imported, in A4 format.
Is there any chance to have the JPG resolution imported on Inkscape ?
Thank you !
I am away on a conference, and will get to this as soon as I can.
attached is a proposed patch to deal with the round-off in the imported png resolution. This will round off the incoming dpi to the nearest 0.1 dpi.
patch from comment 30 committed to rev 11613
Thanks for the patch. Works fine with PNG.
Can this solution be applied with JPEG files ? My file in post 28 (jpeg) is wrong scaled when imported.
In my linux build of the current trunk (revno 11633) the jpeg file "Fiche_03.jpg" from comment #28 loads at 200x200 dpi which matches the GIMP and reports from ImageMagick. The png file "Fiche_01.png" also loads at 200x200 dpi, again matching GIMP and ImageMagick. The png file "Fiche_02.png" loads at the default import resolution set in Preferences. To me this seems like exactly the behavior I expect. Is it not what you expect? Or does something different happen on different OS?
From.
"Fiche_03.jpg" seems to load with default import resolution (in this case at 90 dpi).
Screenshot : http://
I'm not very familiar with the dpi and image resolution, but normally this should behave as "Fiche_01.png" ?
- sorry to display my ignorance, but could someone explain how to download anything from the website dl.free.fr ?
- I have wasted about 10 minutes clicking every single button on this website and none of them appear to trigger a download of anything, much less a jpg file.
- alternatively, could someone attach the relevant jpg files directly to this bug report so that the rest of us could participate in this discussion?
okay, sorry for the rant, I think I got it. It appears that the problem was that the website response time was very slow.
just writing to confirm comment 34 by Hans-Karl. On Windows XP, Inkscape rev 11604, the file Fiche_03.jpg is loading at the default resolution specified in Edit->Preferenc
@Daniel Wagenaar - would you be willing to implement a global opt-out preference for this feature (-> allow to always import 1:1 as it used to be before the merge)? The default would be to import based on image resolution if present (current state), and in the preferences pane one could choose to opt out (no popup question on import, just a global setting).
[ The reason I am asking: The bonus of this feature might depend somewhat on drawing tasks (and might make most sense when importing high-res digital images). For me personally (or for my use cases) I have noticed that it just has added a couple of extra steps (to undo the scaling) I have to do for (on average) 1 out of 3 imported bitmap images (and which can't be done on multiple imported images at once). If others agree that this could be a useful option, I would file a separate RFE for it. A possible alternative - if adding yet another preference setting is considered evil - could be for example a new command (verb) to reset the scale of selected images to 1:1 (those users who need it could then map it to a custom keyboard shortcut). ]
> (…) implement a global opt-out preference (…)
Follow-up report filed:
Bug #1052796 “RFE: make scaling of imported bitmap images based on image resolution optional”
<https:/
I have implemented the opt-out preference (see comment #39) in my new branch at https:/
Opt-out preference committed revision 11681.
Windows 7, Inkscape rev. 11701 : the Fiche_03.jpg file it is not loading at the 200 dpi indicated.
It's JPEG file, not PNG. My request isn't (perhaps) in the right category. I move my question in this bug-report :
https:/
I join my files to this message.
a minor change has been made in rev 12583, to deal with the default behaviour in case no input resolution has been specified. There are three cases that can arise:
1. The option "Override file resolution" is chosen. This option works as expected. Note that the default import resolution in the Preferences is 90 dpi for a clean installation.
2. "Override file resolution" is not chosen, but the file header contains its own resolution. This works as expected.
3. "Override file resolution" is not chosen, and the file header does not contain information on resolution. This leads to mixed results. For a gif file it led to the conclusion that the import resolution was 72 dpi. For a png file with no header info, it led to the conclusion that the import resolution was 72 dots per cm. Neither of these results was expected. The code has been modified so that the new default resolution in this case is 90 dpi. This leads to the result that the size of the image will not change on import, which is consistent with the behaviour of Inkscape 0.48.4. The behaviour of the first two cases above is unaffected.
Inkscape rev. 12650 (Windows build) :
It seems that my png file (see bellow) it is not loading at 300 dpi / 17 cm width (informations confirmed by XnView).
It's too large on my A4 page.
Second file is the import result with Inkscape r12650.
Third file is the informations from XnView.
Fourth file is the import result with Scribus (for comparison).
Import result with Inkscape r12650...
Informations from XnView...
Import result with Scribus (for comparison)...
- go to Edit->Preferences
- then click on Bitmaps and confirm that the setting "Override File Resolution" is _not_ checked.
- could you report back here to indicate if this was the problem?
I can confirm : "Override File Resolution" is not checked.
I have an other png file, for testing : sound-blaster-
For comparison between Inkscape result and Scribus result, see picture below.
Some information may be interesting here to solve this problem (but I lack knowledge about it) :
Bug #1080474 - JPEG resolution not imported in Windows : https:/
Comparison between Inkscape result and Scribus result...
using the file Fig02-Legend, I cannot reproduce the problem. The file is 2008 by 945 pixels. At 300 dpi this is 17 cm by 8 cm. In Inkscape pixels, at 90 dpi, this should be 602.4 by 283.5 pixels. Attached is the result I get on File Open. It has the expected size. The same size is obtained on File Import.
Reproduced on Windows XP, Inkscape r12688, but not with r12511. Apparently, something changed in the ImageMagick fallback (src/extension/
Investigations in progress.
Looks like it's due to r12583 (http://
image.density() doesn't use the same unit depending on the file type (px/cm for PNG and px/in for other formats). Alvin, do you remember why you removed the test on the file type?
The attached patch should fix the issue.
Patch from comment #53 tested successfully on Crunchbang Waldorf (Debian stable) by forcing the Imagemagick fallback.
Committed in the trunk, revision 12711.
Tested successfully with Inkscape rev. 12737 (Windows build). Works as expected.
Thanks for your reactivity!
yes, the change in rev 12583 was made to deal with comment 43 above. In the case where there was no resolution specified, the default resolution was wrong, or I should say inconsistent, depending on whether it was a png or not. So the change was made to implement 90 dpi in this case.?
in the Preferences section, just below the setting for "Default Import Resolution", try putting a check mark by "Override file resolution". This will give you full control of the size of the imported image.
[As you can tell from my long delay in writing, I am not currently
particularly active in Inkscape, having just started in a new academic job.]
For me, importing jpgs works as expected in the Linux version. I do know
that there are some interplatform differences with regards to reading
exif information. (If the file you are loading has resolution
information embedded, that may override the default import resolution
unless you select "override file resolution" in the preferences.)
I do not think that resampling should happen if you just scale things
with the corner handles or the tool bar.
On 02/03/2014 05:13 PM, Hoeflerb wrote:
>?
>
Can someone verify this behavior?