I started out with 9.5in tall pages, at 100 ppi. I later upgraded the entire archive to 12in tall pages, still 100 ppi.
...since then, my wonderful idiot babycat peed in my computer, effectively murdering it. I received a wonderful birthday gift of a new Dell Alienware supercomputer, along with a 4K widescreen. Caley's comic don't look so big now that it's being displayed on more or less the screen of the starship Enterprise.
So, now that we're living in the glorious upgraded horror of tomorrow today: is 12in tall x 8in wide x 100ppi still a good size for posting comic pages? Or do I need to go bigger -- and, if so, HOW big? Or, in a world of desktop attrition at the tiny hands of big smartphones, is bigness as passe as accented words we've stolen from the French?
Well, if you want to get real fancy, possibly fancier than ComicFury can handle, there's the option for multiple resolutions. Using the <picture> and <source> tags and a bunch of media queries, you can feed the browser multiple resolutions and have it display the one that best fits the screen's resolution.
The accepted best practice is to double resolutions. So if your baseline is a 800px wide image, you would also make a 1600px version and a 3200px version (and maybe even a 6400px version, but that would be more for print than for web). Basically, you want to display the biggest one that's less wide than the user's screen. There's some complications in making it actually work because sometimes a browser pretends the screen is smaller than it is because it's high-DPI, but that's the general gist.
Also note that, while phones and tablets are physically small, they have a shitload of pixels. Seriously, a 4K display actually isn't uncommon. My phone, tablet, laptop, and two of my desktops all have the same resolution, 1920x1080, despite being 5.5", 10", 17", and 24" in size. So you'd actually want a high-res copy of your comic for these devices, so they can get the extra sharpness and detail.
What you definitely want to do is work at the highest resolution you can scan at. If your scanner can do 2400dpi, do it. Do all your editing at this resolution, and save a work copy at this full res (disk space is cheap). Only when you're done do you want to scale it down to output resolution. This will save you a ton of time if you ever want to print your comic, let you do this newfangled multi-resolution thing, and will even hide a lot of imperfections during editing.
I'd rather be forced to scroll horizontally on mobile than to cope with a small image on PC. I prefer big pictures. Your suggestion of 8in wide at 100dpi is still too small for me. 800 pixels is a Webtoons width and I HATE browsing comics there as they seem fixated on mobile view and apparently tolerate only the vertical format of images. I checked your book and as you definitely go for the traditional print format rather than the vertical one, I'd suggest going for a 1000+ width. Not self-promoting, but you may wanna check my comic to see if a 1024px width is okay to you.
Disclaimer: Seeing the current trends, I seem to be in the minority. People want to read comic books on their phones using a single thumb and they don't give a flying one about panel composition on a page.
I've been using 900 x 1500 px, but I think it's more about preference, both for you and readers. It's hard to find the perfect comic-page size, and probably impossible to find one that everyone agrees on.
Still unsure about my comic-page sizes though. I believe the height should be shortened a bit.
I was going to say, "As big as they need to be to be legible."
It seems like people are trending toward ~900px wide though, which happens to be what I post my comic at. It feels slightly on the small side for me though. Probably because my layouts are usually horizontally oriented rather than vertically.
I've wondered that before, but it's sort of personal preference I guess.
When I started my comic in 2010, the pages were 600 pixels wide. At some point I switched to 800 pixel wide pages (and resaved the old pictures). I don't know if I should go up again, but all of the pages are drawn at 2000x3200 pixels (which seemed large in 2010, but seems kind of small now) so I've got a lot of room to grow in the future.
You can alter the css of your site here so that people on smaller screens wouldn't have to scroll to the right. You'd just make it so that the image would resize down automatically in the web browser. It's not ideal though, because they'd still be downloading the entire big image though.
Human batteries use their own electrical powers to fuel armored flying super-suits. PG-13ish.
I used to do 800, at some point I made the switch to 900. I can't imagine going any larger, and ver vertically orientated comics I actually think much narrower than that is optimal.
I'm always aware that the way I make my comics is very pinned down to the conventions of print comics and that ideally I should be more creative with the open canvas of the web, but I cling onto my dreams of getting my comics printed someday without the hassle of rearranging them!
That's interesting. I originally posted my comic (beyond) at 800px, but I didn't like how it looked, so I went down to 700px and liked that a lot more. Personally, page size just doesn't bother me unless I have to scroll horizontally. I immediately click off any comic that makes me have to do that. But I think maybe I do have a tendancy to prefer slightly smaller pages.
Your comic seems a pretty good size to me, I don't think I'd change anything unless you really consider it a problem.
Avatar by Ratt
"How Big Should Pages Be Posted, Now That It's Already the Future and All?", 14th Sep 2018, 4:30 PM#14
For just 100 pixels per inch, your work looks fantastic, Caley! My stuff is 300 ppi, and is saved at 900 pixels wide. Being just black and white, that resolution comes off sharp enough for me, and I was also trying to make it viewable/readable on mobile devices.
I’m always checking out my comix on different computers and devices.
Ed' most recent comics (before his hiatus caused by various misfortunes) are mostly in three-panel tower format at 1185 x 2028 px @ 300 dpi. Looks fine on my widescreen monitor, and makes the older 960 x 354 strips look tichy by comparison.
Nightshade the Merry Widow (NSFW, nudity/sex)Comic Fury
Created by Ed Kline and Kishma Danielle, co-writer Lee M, assistance Bob Partridge Storm Over Whoomera (NSFW, nudity)Comic Fury | Renderosity (first page)
Created by Ed Kline, co-writer Lee M
For some comics I wish the pages were bigger (= have a higher resolution). So far I never had the problem that the pages were too big, would that ever happen, I know an easy fix: <Ctrl>-Mousewheel to zoom in or out. Alas, while zooming out for an overview is always feasible (if an image is wider than the screen, I usually zoom out until it fits the width of the screen and then I scroll up and down), zooming in to make details better visible, well that's limited by the actual information that is contained in the image, i.o.w. as soon as you can see the actual pixels, zooming in further will gain nothing and will usually make it worse - e.g. text in an image that is on the limit of being readable in native resolution will become less readable if I zoom in on it, at least for me. It's an observation I made, I don't know why this happens, you can try for yourself.
So for posting my answer is clear: As big as technically possible (the working resolution being the upper limit), or as big as you dare from your viewpoint as an artist (if you want to downsize the original to hide imperfections).
For displaying the pages, it depends how much space you want to be visible left & right from the actual comic-page image, if at all.
@Kyo? Would some auto-resizing JS be a bad idea for some (technical) reason?
(Of course, bigger images cost more HD space and more download and upload time but I can't think of another reason right now.)
And not to forget: The biggest one you can provide is the original size you're working with. Or if you work on paper and scan the end result, the biggest one is the one scanned with the native resolution of your scanner. Upsizing a smaller original usually introduced all sorts of problems, downsizing may hide some problems.
GMan003:Well, if you want to get real fancy, possibly fancier than ComicFury can handle, there's the option for multiple resolutions. Using the <picture> and <source> tags and a bunch of media queries, you can feed the browser multiple resolutions and have it display the one that best fits the screen's resolution.
That's fancy, indeed! I guess at high resolutions it would be profitable to send a best-fitting image instead of just sending the biggest one and let the user's browser downsize it. But what are common resolutions right now? I'd say, 1920x1080 with 4K coming up but not yet being really widespread and 16K (GASP!) being the (not immediate) future.
(Related video: "GAMING at 16K RESOLUTION?? – HOLY $H!T" - beware, lots of shouting! :D)
...(RockB):That's fancy, indeed! I guess at high resolutions it would be profitable to send a best-fitting image instead of just sending the biggest one and let the user's browser downsize it. But what are common resolutions right now? I'd say, 1920x1080 with 4K coming up but not yet being really widespread and 16K (GASP!) being the (not immediate) future.
Yeah, it's designed to save bandwidth, and also allow different images if useful. In a comics context, that could be different panel layouts to fit varying widths. Like, if you normally use a 2x2 panel grid, you could have it move to 4x1 horizontal on sufficiently wide screens, or 1x4 vertical on stuff like phones. But anything you can think of could probably work.
There's literally hundreds of resolutions - you don't want to make different ones for each. Again, best practice is doubling in size from a baseline, and using the largest that fits horizontally without scrolling. So maybe a 940px version, 1880px version, and 3760px version, which would fit well in 1280x1024 and 1366x768, 1920x1080, and 3840x2160, respectively (always include a little padding for stuff like scrollbars).
As for why you don't just want to automatically scale to screen resolution, scaling by non-integer amounts adds blur, and it's worse the more complex the ratio is (3:2 is way better than 11:9). If you scale a 1000px image to 1023px, any hard lines will get softened and any text will get smeared, especially if there was subpixel rendering on the text. While there are ways to scale images without blurring, there's no method yet for telling a browser to use them. There's a draft standard for specifying how to scale but even that doesn't include one that's suitable for comics, it's just the normal bilinear or nearest-neighbor (which handles pixel art well but would ruin comics in different ways).
PS: You can safely ignore any resolutions about 3840x2160 for now. Even that is pretty rare (~1.3% per SHS), and anything above it is obscenely expensive.
GMan003:As for why you don't just want to automatically scale to screen resolution, scaling by non-integer amounts adds blur, and it's worse the more complex the ratio is (3:2 is way better than 11:9). If you scale a 1000px image to 1023px, any hard lines will get softened and any text will get smeared, especially if there was subpixel rendering on the text.
Right... I didn't think of this.
GMan003:While there are ways to scale images without blurring, there's no method yet for telling a browser to use them.
GMan003:There's a draft standard for specifying how to scale but even that doesn't include one that's suitable for comics, it's just the normal bilinear or nearest-neighbor (which handles pixel art well but would ruin comics in different ways).
OK. I wasn't aware of that. The only thing I noticed once in a while was that 3D-rendered images suffer from resizing if it's not done carefully.
Thank you very much - you can explain, indeed! :)
So if you want to have different resolutions pre-made, I'd rather have one intermediate step between 100% and 50%, otherwise you may loose 49.99% to the background (nearly half the image width on both sides) if your screen is a little bit too small for the next bigger size. Loosing at most 24.999% (1/4 of the image width on both sides) would IMHO look much better.
GMan003:As for why you don't just want to automatically scale to screen resolution, scaling by non-integer amounts adds blur, and it's worse the more complex the ratio is (3:2 is way better than 11:9). If you scale a 1000px image to 1023px, any hard lines will get softened and any text will get smeared, especially if there was subpixel rendering on the text. While there are ways to scale images without blurring, there's no method yet for telling a browser to use them. There's a draft standard for specifying how to scale but even that doesn't include one that's suitable for comics, it's just the normal bilinear or nearest-neighbor (which handles pixel art well but would ruin comics in different ways).
Regarding the integer bit... would you say it "visually" matters if an image is downscaled by an integer value? I draw at 6600x10200 (11x17 inches at 600dpi) and then obviously decrease it before uploading. I used to go by the number the website told me, or take a number out of my ass, if the website does not enforce it (such as Deviant Art). So for instance... I downloaded a .cbr comic from Comixology, unpacked the image files and saw that the pros sell us comics at around 1987 pixels wide. Where did this number come from I don't know, but I figured I would blindly follow and set a number like that as a somewhat of a default size for my downscaling and then allow the website to do the additional downscaling if needed (for instance Deviant Art allows you upload any size, but then suggests a 1024 view).
My question is... how significant it is to downscale your size into a new one that is a factor of the original one? With my 11x17, both of those numbers are prime, so I'm looking at factors of 600 (my dpi). I could decrease it 6 times and obtain a 1100x1700, which is pretty close to the DA suggested view (I THINK they allow you to set a custom view size, which would be much better than additional decrease from 1100 to their 1024). Overall would you say that downscaling an image 6 times gives a noticable difference compared to dowscaling 6.445... (you get the idea) times? I figured in the latter case an algorithm would take six pixels and crunch them into one, but every now and then seven pixels would do the trick... which does not sound THAT bad compared to constantly converting six pixels to one (or 36 to 1 if you look at the area). I have no idea how those algorithms work so this is pure speculation on my part.
Paulie Blade:Regarding the integer bit... would you say it "visually" matters if an image is downscaled by an integer value?
There's a lot of factors - how complex the ratio is, what image rescaling algorithm was used, and what kind of content was in the image in the first place. Image rescaling is a very complicated field of study. I'm giving you the cliff's notes here, going into further detail would require visual aids that I don't feel like making right now.
If you're using a common algorithm - nearest-neighbor, bilinear or bicubic - doing an integer or simple fraction scaling works best to preserve straight hard edges. Let's suppose you've got a 2000x2000 page, with 8 pixel wide solid-black panel borders, and you're scaling down with a bilinear lerp. If you do a perfect 2:1 integer scale, to 1000x1000, you will get either a perfect four-pixel black border, or a three-pixel black border surrounded by one pixel of 50% gray if the border wasn't on an even pixel. If you scale by 4:3 to 1500x1500, now you can get three levels of gray (25%, 50% and 75%) and only solid blocks aligned to a 4px grid will scale perfectly. At 8:7 (1750x1750 in this example), you'd see seven values of gray and need to align to 8-pixel blocks to avoid them. Bicubic kind of helps at least look like the lines are still sharp, but it still overall blurs things. Nearest-neighbor will never give you shades that don't appear in the source, but instead you'd get inconsistent line widths - even with a 2:1 downscale, you'd get either 4-pixel or 3-pixel wide lines, depending on whether they were odd or even, and will give you nasty banding on any gradients.
Effects like that aren't really a problem with stuff like photographs. You don't have solid, pixel-perfect lines to begin with, so it's no serious loss. And as a programmer, those three above are insanely fast - a variant of bilinear is the norm for real-time 3D rendering, so you can do literally billions of pixels worth of image rescaling in a second. That's why it's also the norm for general-purpose image scaling, as in web browsers. Most stuff looks fine, it's fast and efficient, and the cases where it works badly are problems for content authors to deal with.
Good tools often apply a sharpen or contrast enhance after downscaling (opposite problems can occur with upscaling, requiring a blur, but that's out of scope right now). Photoshop, for instance, generally uses Bicubic plus a blur or sharpen depending on which way you scaled, allowing you to adjust the blur/sharpen amount to fit. Other editors usually do the same. So if you're rescaling in-editor, things usually go much better than trying to rescale in the browser. This is especially true if you have vector content, as the editor can simply rasterize it again after rescaling.
Overall... you're going to have to experiment. Simple ratios will always be better but where the acceptable tradeoff between quality and getting the right image size is, is up to you.