The hard-wired limit is 32768 px in any direction.
Couldn't find a way either, was told that is how it is. Maybe a limit to the cairo renderer -which inkscape developers have no control over.
If that's a cairo issue you'd need a *very* specific compilation with a different render engine.
If I remember right cairo was introduced around 0.48 to 0.49? Previous versions have webkit(?) so they may be able to render raster images of that size (but come also with less features, more bugs).
The image output size should be determined by the professional standards and not arbitrary assumptions.
Printers like Fed Ex Office print banners 36" wide at 600 pixels per inch for unlimited length. That means that 28,800 pixels = 48" long and 21,600 pixels = 36" wide. 3X4 is a standard for technical drawing.
At a 16 to 9 aspect ratio the pixel count would be - 21,600 pixels for the 9 unit leg and 38,400 for the 16 unit leg. Basically, the image from a TV grab would print at 3 feet by 5.3 feet long. The stated 32,000 measure given above is too short for professional printing out of Inkscape.
Sony created an 8K TV. Basically, the largest horizontal pixel count needed for TV display is around 8,000. Most computer monitors are still struggling to step to 4K.
So, while I agree that the pixel output count needs to be higher - the need for a high increase is not that great unless a "professional printmaking house" is used to accomplish the output. I mention this because some photographers etc might want to cover a building with their photo ? In which case, the resolution would probably not change. The output size would not change from 36 inch wide due to paper rolling limitations. Instead, the output would need to be tiled. Sector one tile would need to mate seamlessly with sector two tiling [ etc ] after being printed.
While increasing the exportability of high pixel count images is a very necessary development if Inkscape wants to be a "professional" software - it also needs to integrate a tiling function so that an export image can be broken into user defined chunks which may be printed at their print house.
And don't get me onto the subject of Inkscape's failure to import high pixel count png images that the software created just minutes before the attempt to import.
I'm afraid you misunderstood my request. I was talking about import limits, not export, which has very different implications.
I'm sorry that you took the time to write all this. Perhaps this could be brought to a new topic?
I wish I could edit the title of this topic to clarify that point but if an admin (@brynn) can, could you please name it "Increase maximum imported image size"?
An imported image over 32768 px is rendered black on screen and you probably cannot export to larger images than that -since both rendering uses cairo.
Thank you for remembering my previous posts. My dad died and I needed to do other things for my family.
I agree, it seems little has changed with 1.0+. Actually, it seems there is a consensus that the abilities of the software have regressed a bit.
As for not believing about 600 DPI [ actually PPI ], ask the printers at the local FedEX Office store. I'm quoting the industry standard for output. I don't think it is surprising that people may want to use Inkscape to print a banner.
Thank you for pointing out that both the import and export of images are limited by Cairo. From that reality one has to ask "what would a reasonable starting point for expansion be?" While we don't have realistic limitations on import size need - we are limited with export need to satisfy industry standards. Those are what I stated. I suggest starting with the exportability issue - and expand the abilities of Inkscape as specific artists need the expansion.
In my case, I am creating and selling maps in inkscape that are over 80 MB in size. The kilobyte era is over.
Abilities as in performance topped somewhere in 0.92.
It's a bit unreasonable expecting inkscape to render such large images since now it doesn't support multi-threading and gpu rendering either.
I do know there are printers claiming to be capable of a 4800/9600 dpi resolution, however not printed on the right material 600 dpi can also become a smudgy mess.
Banners usually aren't using high resolution though because while they are large, they are viewed from a distance.
Can understand your point to some extent with maps, however online maps use tiling for fast rendering too.
In my humble opinion printers can print in high resolution, also in large format, but when those meet the end result can be so huge the printer's rip is unable to process the file.
Maybe in a decade, when 4k screen resolution will be obsolete, people switching from 8k to 10k screens, we can have the processing power without any of these issues.
Haven't tested much, but affinity designer while still being actively developed, lacking features, focusing on performance and is based on a cad-like zoom scale.
Don't forget that a PPI count is different than a DPI count. Squares to Dots. The PPI count can be at least half the DPI count for the same quality output. 600 PPI = app 1200 DPI.
The smudgy mess is why I use photographic paper with dyes [ not inks ] on a specific Epson printer.
600 PPI is what the locals are using for banners.
My maps are actually the SVG file itself. My customers will need to install a copy of Inkscape. I started posting again to determine what to recommend. It seems my observation that 93 would be about the most recent is valid.
Customers can open the file on their Digital Table Top to play games like Dungeons and Dragons or Strategy and Tactics. The scalability allows them to scale my map with the zoom function so that a square in the map - which represents 5 feet - will be precisely 1 inch wide when measured with a ruler on their DTT regardless of their TV size. The game is played by turning layers off and on to present discoveries in the dungeon, engage opponents, draw lines to map the interaction of player characters to create a campaign journal at the end of a game, etc. The scalability is important as players want to place their miniatures which are scaled for 1 inch width - directly onto their digital table top. This creates a "pool of radiance" kind of experience where they are able to "look down upon their avatars."
If you remember my posts from 8 years ago - I actually wrote that this kind of functionality was going to be needed. I explicitly outlined developments which could be achieved to prepare for the technology. At that time I referred to the imagery and functionality as "Okudagrams." Today, the reality is called a "Virtual Table Top." Same functions, my idea, but real. Without internet access, I am calling my game assets a product for a Digital Table Top.
Just to say - the company that may host my files wants me to create a how to use manual. In writing it, I have felt the need to advise customers regarding what they should and should not do with Inkscape. I became involved with the forum again to research my opinions. It seems they are still valid. Have the managers gotten over the idea that this is free software or are they awake to the fact that time is money? Every minute I spend dealing with slow software or cracked code is one minute that did not covert to coin? It is saddening to see. I thought we learned with Blender that GPU is better for calculations than CPU. ETC ! Why are they even using something Cairo and not Blender's render engine? Does Inkscape even have a business plan?
This is getting off topic from the original post so probably we'll need a moderator splitting this totwo separate topics.
I'm using dpi as dot per inch for convenience, although if wanted to be pedantic, neither term covers what is happening really.
Dpi is usually used when talking about digital work on screens -where the display resolution is hard-wired, and currently around the 90-96 pdi range.
Printers also have a hardwired resolution, some claiming 1200/2400, others 4800/9600 "samples" per inch (differrent values in horizontal/vertical directions).
Hardwired, as they cannot lower that value, the rip of the printer just interpolates in between.
If that sample is referring to the amount of inkblots they can lay in an inch, the actual resolution is much smaller.
Like it's similar if screen manufacturers would claim double times larger numbers for their screen sizes due to the number of subpixels achieved by using effectively that number of leds in a Bayer-pattern.
Probably the printer's hardwired limit of 600 dpi means they cannot print raster images with a higher resolution, and as most banner design is vector based, it doesn't really matter anyway.
One shouldn't worry about resolution unless working with raster images -which was the whole point of the original topic-.
If I were about to produce such digital tabletops, I'd investigate in the graphhopper world or similar.
Openstreetmaps use the same technology. You can export the map as an svg -so that's their "to go" format for storing the core data, however on screen everything is composed of prerendered raster tiles.
It should render much faster, and considering using svg filtering, rendering the svg is sometimes an impossible mission (gained a bit of experience in that field in those 8 years, by producing some pc-melting custom filters).
Maybe there is a similar solution for your work too.
Inkscape is open, you can even attend the leadership committee to ask questions if they have a business plan.
Certainly they have a vague concept, but as most work done is unpaid volunteer work, it's already a blessed miracle we have a functional software with support for so long.
As far as I could see it they are not concerned focusing on one possible user area, like maxing out performance for digital tabletops.
It's free for unlimited use cases, boiling down mostly for logo creating and character design with a hint of support for the fabricating community.
SVG is the antithesis to the need for output counts because it is scalable. Unless trying to import or export. As I said, 600 PPI is what the common resources people go to to print use. That is probably the best place to start if inkscape wants to make its support for rasters more robust.
My digital table tops need the layering I'm building into the files. Players need to be able to turn off a layer that is hiding a zone - activate an opponent etc. All of that happens within the map.
Without a business plan, it is very hard to get a small business loan at any bank. Professionals seek professionalism. I will remember this status of things when I start getting chided or asked about donations. And - I know this will probably light a fuse - I think a good way to grow the software and attract more coders would be to build it as a foundation - perhaps similar to the blender foundation?
For clarity - I obviously am not implying Inkscape should be just for my work. I know I will have customers who will face issues regarding Inkscape's functionality and their history of "repairs." I will give them my honest opinions based on my research. Right now, it seems I may want to start by saying that it is a kilobyte era program.
Beyond the Basics Increase maximum imported image size
Inkscape.org
Hi,
When I import an image above a certain size (e.g. 40 000 x 4 000 px), it renders black, which means there's a limit defined somewhere.
Is there a way to increase that limit?
I'd contact the devs. This may be related to this issue: https://gitlab.com/inkscape/inkscape/-/issues/1018. A discussion is in progress for a solution, which may resolve your situation.
The hard-wired limit is 32768 px in any direction.
Couldn't find a way either, was told that is how it is. Maybe a limit to the cairo renderer -which inkscape developers have no control over.
If that's a cairo issue you'd need a *very* specific compilation with a different render engine.
If I remember right cairo was introduced around 0.48 to 0.49? Previous versions have webkit(?) so they may be able to render raster images of that size (but come also with less features, more bugs).
Maybe ask around here if they can give you a better reason/answer: https://chat.inkscape.org/channel/team_devel
Let's see where this goes : https://lists.cairographics.org/archives/cairo/2021-July/029287.html
As you can see from the responses, handling bigger images natively is out of question for cairo.
The only hope now is pathfinder, which has apparently been discussed as an alternative to cairo. So let's see what they have to say about image size:
https://github.com/servo/pathfinder/issues/221#issuecomment-888266788
The image output size should be determined by the professional standards and not arbitrary assumptions.
Printers like Fed Ex Office print banners 36" wide at 600 pixels per inch for unlimited length. That means that 28,800 pixels = 48" long and 21,600 pixels = 36" wide. 3X4 is a standard for technical drawing.
At a 16 to 9 aspect ratio the pixel count would be - 21,600 pixels for the 9 unit leg and 38,400 for the 16 unit leg. Basically, the image from a TV grab would print at 3 feet by 5.3 feet long. The stated 32,000 measure given above is too short for professional printing out of Inkscape.
Sony created an 8K TV. Basically, the largest horizontal pixel count needed for TV display is around 8,000. Most computer monitors are still struggling to step to 4K.
So, while I agree that the pixel output count needs to be higher - the need for a high increase is not that great unless a "professional printmaking house" is used to accomplish the output. I mention this because some photographers etc might want to cover a building with their photo ? In which case, the resolution would probably not change. The output size would not change from 36 inch wide due to paper rolling limitations. Instead, the output would need to be tiled. Sector one tile would need to mate seamlessly with sector two tiling [ etc ] after being printed.
While increasing the exportability of high pixel count images is a very necessary development if Inkscape wants to be a "professional" software - it also needs to integrate a tiling function so that an export image can be broken into user defined chunks which may be printed at their print house.
And don't get me onto the subject of Inkscape's failure to import high pixel count png images that the software created just minutes before the attempt to import.
Hi @NELCHAI .
I'm afraid you misunderstood my request. I was talking about import limits, not export, which has very different implications.
I'm sorry that you took the time to write all this. Perhaps this could be brought to a new topic?
I wish I could edit the title of this topic to clarify that point but if an admin (@brynn) can, could you please name it "Increase maximum imported image size"?
Title updated. @NELCHAI 600dpi? Sorry I can´t take this serious.
It's a rendering issue so it stands both ways.
An imported image over 32768 px is rendered black on screen and you probably cannot export to larger images than that -since both rendering uses cairo.
(On the other hand @Nelchai, you brought up some flashback to me from 8 years ago. https://alpha.inkscape.org/vectors/www.inkscapeforum.com/viewtopic677b.html?t=14016
too bad notmuch have changed on the basic principals.)
Thank you for remembering my previous posts. My dad died and I needed to do other things for my family.
I agree, it seems little has changed with 1.0+. Actually, it seems there is a consensus that the abilities of the software have regressed a bit.
As for not believing about 600 DPI [ actually PPI ], ask the printers at the local FedEX Office store. I'm quoting the industry standard for output. I don't think it is surprising that people may want to use Inkscape to print a banner.
Thank you for pointing out that both the import and export of images are limited by Cairo. From that reality one has to ask "what would a reasonable starting point for expansion be?" While we don't have realistic limitations on import size need - we are limited with export need to satisfy industry standards. Those are what I stated. I suggest starting with the exportability issue - and expand the abilities of Inkscape as specific artists need the expansion.
In my case, I am creating and selling maps in inkscape that are over 80 MB in size. The kilobyte era is over.
Abilities as in performance topped somewhere in 0.92.
It's a bit unreasonable expecting inkscape to render such large images since now it doesn't support multi-threading and gpu rendering either.
I do know there are printers claiming to be capable of a 4800/9600 dpi resolution, however not printed on the right material 600 dpi can also become a smudgy mess.
Banners usually aren't using high resolution though because while they are large, they are viewed from a distance.
Can understand your point to some extent with maps, however online maps use tiling for fast rendering too.
In my humble opinion printers can print in high resolution, also in large format, but when those meet the end result can be so huge the printer's rip is unable to process the file.
Maybe in a decade, when 4k screen resolution will be obsolete, people switching from 8k to 10k screens, we can have the processing power without any of these issues.
Haven't tested much, but affinity designer while still being actively developed, lacking features, focusing on performance and is based on a cad-like zoom scale.
Worth keeping an eye on them:
https://www.youtube.com/watch?v=JnfxzknVK_0
Don't forget that a PPI count is different than a DPI count. Squares to Dots. The PPI count can be at least half the DPI count for the same quality output. 600 PPI = app 1200 DPI.
The smudgy mess is why I use photographic paper with dyes [ not inks ] on a specific Epson printer.
600 PPI is what the locals are using for banners.
My maps are actually the SVG file itself. My customers will need to install a copy of Inkscape. I started posting again to determine what to recommend. It seems my observation that 93 would be about the most recent is valid.
Customers can open the file on their Digital Table Top to play games like Dungeons and Dragons or Strategy and Tactics. The scalability allows them to scale my map with the zoom function so that a square in the map - which represents 5 feet - will be precisely 1 inch wide when measured with a ruler on their DTT regardless of their TV size. The game is played by turning layers off and on to present discoveries in the dungeon, engage opponents, draw lines to map the interaction of player characters to create a campaign journal at the end of a game, etc. The scalability is important as players want to place their miniatures which are scaled for 1 inch width - directly onto their digital table top. This creates a "pool of radiance" kind of experience where they are able to "look down upon their avatars."
If you remember my posts from 8 years ago - I actually wrote that this kind of functionality was going to be needed. I explicitly outlined developments which could be achieved to prepare for the technology. At that time I referred to the imagery and functionality as "Okudagrams." Today, the reality is called a "Virtual Table Top." Same functions, my idea, but real. Without internet access, I am calling my game assets a product for a Digital Table Top.
Just to say - the company that may host my files wants me to create a how to use manual. In writing it, I have felt the need to advise customers regarding what they should and should not do with Inkscape. I became involved with the forum again to research my opinions. It seems they are still valid. Have the managers gotten over the idea that this is free software or are they awake to the fact that time is money? Every minute I spend dealing with slow software or cracked code is one minute that did not covert to coin? It is saddening to see. I thought we learned with Blender that GPU is better for calculations than CPU. ETC ! Why are they even using something Cairo and not Blender's render engine? Does Inkscape even have a business plan?
This is getting off topic from the original post so probably we'll need a moderator splitting this totwo separate topics.
I'm using dpi as dot per inch for convenience, although if wanted to be pedantic, neither term covers what is happening really.
Dpi is usually used when talking about digital work on screens -where the display resolution is hard-wired, and currently around the 90-96 pdi range.
Printers also have a hardwired resolution, some claiming 1200/2400, others 4800/9600 "samples" per inch (differrent values in horizontal/vertical directions).
Hardwired, as they cannot lower that value, the rip of the printer just interpolates in between.
If that sample is referring to the amount of inkblots they can lay in an inch, the actual resolution is much smaller.
Like it's similar if screen manufacturers would claim double times larger numbers for their screen sizes due to the number of subpixels achieved by using effectively that number of leds in a Bayer-pattern.
Probably the printer's hardwired limit of 600 dpi means they cannot print raster images with a higher resolution, and as most banner design is vector based, it doesn't really matter anyway.
One shouldn't worry about resolution unless working with raster images -which was the whole point of the original topic-.
If I were about to produce such digital tabletops, I'd investigate in the graphhopper world or similar.
Openstreetmaps use the same technology. You can export the map as an svg -so that's their "to go" format for storing the core data, however on screen everything is composed of prerendered raster tiles.
It should render much faster, and considering using svg filtering, rendering the svg is sometimes an impossible mission (gained a bit of experience in that field in those 8 years, by producing some pc-melting custom filters).
Maybe there is a similar solution for your work too.
Inkscape is open, you can even attend the leadership committee to ask questions if they have a business plan.
Certainly they have a vague concept, but as most work done is unpaid volunteer work, it's already a blessed miracle we have a functional software with support for so long.
As far as I could see it they are not concerned focusing on one possible user area, like maxing out performance for digital tabletops.
It's free for unlimited use cases, boiling down mostly for logo creating and character design with a hint of support for the fabricating community.
I agree with what you wrote.
SVG is the antithesis to the need for output counts because it is scalable. Unless trying to import or export. As I said, 600 PPI is what the common resources people go to to print use. That is probably the best place to start if inkscape wants to make its support for rasters more robust.
My digital table tops need the layering I'm building into the files. Players need to be able to turn off a layer that is hiding a zone - activate an opponent etc. All of that happens within the map.
Without a business plan, it is very hard to get a small business loan at any bank. Professionals seek professionalism. I will remember this status of things when I start getting chided or asked about donations. And - I know this will probably light a fuse - I think a good way to grow the software and attract more coders would be to build it as a foundation - perhaps similar to the blender foundation?
For clarity - I obviously am not implying Inkscape should be just for my work. I know I will have customers who will face issues regarding Inkscape's functionality and their history of "repairs." I will give them my honest opinions based on my research. Right now, it seems I may want to start by saying that it is a kilobyte era program.