Jump to content

Recommended Posts

Hm... just another case I had to use my old PS6 again. :$

I am currently working on Czech version of the comic book where the original data contains the artwork in 300ppi CMYK & inks (black&white page) in 1200ppi 1bit tiff images. I am editing all B&W pages in Affinity Photo and export them back as TIFF files. Unfortunately I had to re-saved them in PS in Bitmap mode / 50% threshold as AP doesn't support it... yet. Please add (at least) the export TIF in Bitmap mode. It would be very appreciated ;)

Btw, the colour TIFF pages required little bit of editing / retouching as well but here I had to use PS only as I had a lot of issues with shifted colours, missing layers and deadline was so close. Once it's finished I will ask for support and "reverse engineering" here (well, not in this topic of course) as I want to know the limitations of Photo and/or Designer to edit comic books... and Publisher as well even I don't prepare the final PDF for print, this part is done by another guy in InD.

Anyway I still believe in Affinity!

Link to post
Share on other sites
  • 3 weeks later...
  • Replies 97
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I'll be honest here - we will never implement 1bit document support.. However, we would be happy to implement support for *exporting* 1bit TIFF etc. - would that be enough? Thanks, A

Hello, I can not find a Bitmap mode in 1-bit Photo Affinity off I need to process files that keeps strictly their mode and their resolution. This is copydot files and it is important that it be treat

Well, I'll unfortunately have to be honest here too: this drops the Affinity suite out of the professional league, at least for now. I wish this information had been public earlier, I would have looke

On 5/30/2019 at 2:40 PM, longstreth said:

I'm a cartoonist looking for an alternative to Photoshop and was bummed to find out (after purchase) that Affinity Photo does not have a bitmap mode, which is essential to my practice. As stated above, the printing process for comics uses black and white bitmap 1200dpi TIF files for the lineart, which is overprinted above the CMY plates. Until this feature is incorporated I'll have to search elsewhere for a workaround (Clip Studio Paint, etc.)

Me too!!!!!

Link to post
Share on other sites

It really would be helpful to get the 1-Bit mode implemented. It's been on the feature request list for nearly 4 years now .... Aside the above mentioned areas you need it for supplying coating layers for print. 

CRM.png.a048d588572393102ac3cc403bfa8af7.png

iCore i7-3770, 3.50GHz, 32GB RAM, SSD, NVIDIA GeForce GTX 1660 Ti, Wacom Intuos 4 Tablet, Windows 10 Pro - AP, AD and APublisher latest final & beta
https://www.timobierbaum.com

Link to post
Share on other sites

1 Bit export would do the job ... Still would be nice to have a preview with adjustable threshold ... even if I would have to export a picture to publisher ... (hard to understand the devs decision, since there seem to be many reasons to have this mode and it's no rocket science to flatten a grayscale pic to 1 bit. And I guess TIF would be a desirable format as well next to PDF).

Just my 2 cents ...

CRM.png.a048d588572393102ac3cc403bfa8af7.png

iCore i7-3770, 3.50GHz, 32GB RAM, SSD, NVIDIA GeForce GTX 1660 Ti, Wacom Intuos 4 Tablet, Windows 10 Pro - AP, AD and APublisher latest final & beta
https://www.timobierbaum.com

Link to post
Share on other sites
  • 2 weeks later...

I have one crazy suggestion. There is an option to switch to different view modes in Designer (vector, pixel, pixel retina, outline), even to split views. I cannot see this view modes in Photo now, only in Designer but what about to add "1-bit view" to all Affinity apps? The idea is to get realtime preview of the artwork even the apps will still work in X-bit grey / colour mode. Make it sense or is that stupid suggestion? I don't know... 

 

Snímka obrazovky 2019-10-02 o 21.16.26.jpg

Link to post
Share on other sites

Creating 1-bit lookalike is not a problem. Threshold filter makes perfectly good B&W image (and as it is nondestructive you can turn it off/on like preview). You can even export it to 2 colour/B&W PNG. It is then 1-bit truly, but it is not true 1-bit bitmap image, it is 1-bit indexed colour image. It does not behave in InDesign like 1-bit bitmap image. 

This export bitmap export option should be added, preferably to TIF format export.

Link to post
Share on other sites

Hi there,

I completely agree with what Fixx said.
To me preparing my work ready to print is vital for 2 specific main reasons (there are others too but they are mainly related to my workflow).

1. I want my artwork to be print-ready so that i have control or let's say legal certainty and using a bitmap to tone an image with Spotcolors is the usual way how prepress will handle it.
I do comic art and the reasons why this is important here has already been sufficiently explained earlier.

2. I have been working in a prepress department for quite a while and I do want them to have exactly what they want if need be and have them not necessarily do it themselves because the very least it will cause is a delay which of course might provoke other problems.

So yes, bitmap is absolutely necessary and other prepress related features such as a preview of color-separation and overprinting.

:)

 

Link to post
Share on other sites
  • 4 months later...

I work with both the printing industry and laser engraving and both require 1 bit files. The fact that this is not going to be supported is giant. I wanted to like Affinity over Adobe, but this is making it so I have to use yet another program to do something that Photoshop can handle in one. A true 1 bit output would be a start, but won't be a complete fix because every time there is a color conversion (to grayscale then back to 1 bit) there is the possibility of weird and unexpected things going wrong.

Link to post
Share on other sites

I know, I am very disappointed too. I could not believe what I was reading when the Affinity team announced / confirmed that they would never implement a proper 1bit mode.

That said, multi-channel isn't supported either (duo-, tri-tone, etc.). Which means the Affinity range is severely crippled for anything other than a regular CMYK print workflow. Let's hope they will at the very least implement multi-channel support - but without 1bit mode, it will still be considered handicapped for many print jobs.

@lilokai PhotoLine supports true 1bit, and even supports layers while working with 1bit images - unlike Photoshop. And the latest version introduced multi-channel image and PDF Device-N support as well. My solution for this type of work.

Link to post
Share on other sites
Just now, Medical Officer Bones said:

I know, I am very disappointed too. I could not believe what I was reading when the Affinity team announced / confirmed that they would never implement a proper 1bit mode.

That said, multi-channel isn't supported either (duo-, tri-tone, etc.). Which means the Affinity range is severely crippled for anything other than a regular CMYK print workflow. Let's hope they will at the very least implement multi-channel support - but without 1bit mode, it will still be considered handicapped for many print jobs.

@lilokai PhotoLine supports true 1bit, and even supports layers while working with 1bit images - unlike Photoshop. And the latest version introduced multi-channel image and PDF Device-N support as well. My solution for this type of work.

And unless pdf export supported different ppi/dpi exporting to handle 1200 dpi (for instance) for 1-bit versus 300 dpi (for instance) for cmyk in the same export, I'm not certain adding 1-bit import/export really matters.

Link to post
Share on other sites
1 minute ago, MikeW said:

And unless pdf export supported different ppi/dpi exporting to handle 1200 dpi (for instance) for 1-bit versus 300 dpi (for instance) for cmyk in the same export, I'm not certain adding 1-bit import/export really matters.

True, true. InDesign, Quark, (even the old Freehand, I recall) and PhotoLine all support this.

As I said, Affinity remains crippled for a wide range of print work if the developers maintain their stance. Bit of a shame, really.

Link to post
Share on other sites
  • 3 months later...
  • 1 month later...

I would also like to add my name to the petition for bitmap and duotone capability. I can't see any reason not to have it and the sheer volume of print that uses both, makes Affinity effectively unusable in many situations in the print world.

Adding the capability would open Affinity up for a huge number of designers and illustrators who currently have little other option than to carry on with PS. Including me.

Link to post
Share on other sites
  • 6 months later...
19 hours ago, bürolang said:

Yes I would like to have the 1-bit export option too.

You can sure export to 1-bit file, see More-button in PGN export dialog.

You just cannot work in 1-bit mode in Affinity. Threshold adjustment layer may help to see image in 1-bit lookalike, but there are some strange glitches there, for some reason for example brushed areas do not go black&white but stay feathered.

Link to post
Share on other sites
On 2/20/2021 at 4:50 AM, Fixx said:

Threshold adjustment layer may help to see image in 1-bit lookalike, but there are some strange glitches there, for some reason for example brushed areas do not go black&white but stay feathered.

This is most likely because the feathered areas are not 100% opaque in the alpha channel.

Try filling the pixel layer before you start painting so that the alpha channel is 100% opaque to begin with.

Link to post
Share on other sites

All these workarounds are okay for the odd instance that someone must work with 1bit imagery, but not very workable if one has to deal with many 1bit files and edits on a regular basis. For that a native 1bit image mode will have to be implemented, which is never going to happen. Which is fine, because other alternatives exist to handle that situation.

The 1bit export is a step in the right direction, although in its current state hardly usable in an efficient 1bit workflow. But I appreciate that the Affinity devs put this on their action list, and this will certainly work much better once they implement a proper preview in export mode.

Besides, the point is moot: as long as Designer and Publisher do not support proper placing & processing of 1bit high resolution images while exporting to PDF, there is no easy workaround, except to use an alternative that does provide that option.

I expect the devs will have implemented this rather essential option by version 2.

Link to post
Share on other sites

I mean: I just tested the latest version of Publisher with a simple 600ppi 1bit drawing. Publisher still misinterprets the correct dimensions it should be placed at, and relies on the document ppi - while it should be interpreting that 600ppi according to the file's native ppi. Which means the 600 ppi drawing is placed at twice the original scale at the document's 300ppi. Twice too large, in effect.

Scaling the drawing down by x2, and then exporting to PDF still converts the drawing to a RGB bitmap. Unusable.

If they resolve these two things, Publisher and Designer will at least be capable to deal with existing 1bit imagery and properly outputting those PDFs. These are the 'bear' necessities for prepress work, even if Photo will never allow for true 1bit editing. At least it will allow for 1bit image export, as a semi-acceptable workaround solution. Other users (like myself) who need to edit such files regularly will continue to use alternative image editors for this particular task, but they will at least be able to rely on Publisher and Designer to keep the files as-is.

The need for placing 1bit high resolution bitmap in Designer and Publisher and output to PDF is non-negotiable, however. Unless Serif is fine with limiting Publisher to an 24bit RGB/CMYK workflow and leave out a pretty big chunk of the publishing market.

Link to post
Share on other sites
10 hours ago, fde101 said:

This is most likely because the feathered areas are not 100% opaque in the alpha channel.

Try filling the pixel layer before you start painting so that the alpha channel is 100% opaque to begin with.

Yes, that helps. But when there is no transparent background it should still behave the same; after all painted pixels are flat in the bg colour and there should be no alphas in play. I consider this bug.

9 hours ago, Medical Officer Bones said:

Publisher still misinterprets the correct dimensions it should be placed at, and relies on the document ppi - while it should be interpreting that 600ppi according to the file's native ppi.

This is also weird design choice; why use ppi? Layout application should always use physical dimensions.

Link to post
Share on other sites
2 hours ago, Fixx said:

Yes, that helps. But when there is no transparent background it should still behave the same; after all painted pixels are flat in the bg colour and there should be no alphas in play. I consider this bug.

It kind of depends on your interpretation.

The pixel layer starts off as transparent and the document being opaque adds an opaque (white) background behind it, which is not part of the layer.

I believe what is happening is that the filter is being applied to all of the layers below it but as the background is not part of the layer stack it is not considered.  As a result the threshold is most likely making the feathered areas 100% black, but since those areas are not fully opaque the results of the filter are then blending with the background underneath it, which in the case of the opaque white area underneath the layer stack, is white, leading to parts that are gray.

In other words, that opaque background is being treated an artifact of how the image is being rendered rather than part of the image itself - it is not being considered when rendering the layers with their opacity levels.

In a way this is more flexible than if it were being taken into account.  You can always add your own fill layer to the bottom of the layer stack (or fill the background pixel layer), so this gives you two different behaviors to choose from.

 

2 hours ago, Fixx said:

This is also weird design choice; why use ppi? Layout application should always use physical dimensions.

ppi = pixels per inch; an inch is a physical dimension so they are doing that already; entering 600 pixels per inch is much easier than entering 1/600th of an inch per pixel (0.001666666666667 inch or 0.042333333333333 mm for those keeping score).

Link to post
Share on other sites
20 hours ago, fde101 said:

In a way this is more flexible than if it were being taken into account.  You can always add your own fill layer to the bottom of the layer stack (or fill the background pixel layer), so this gives you two different behaviors to choose from.

OK, it may be more flexible but it is not expected behaviour.

20 hours ago, fde101 said:

ppi = pixels per inch; an inch is a physical dimension so they are doing that already; entering 600 pixels per inch is much easier than entering 1/600th of an inch per pixel (0.001666666666667 inch or 0.042333333333333 mm for those keeping score).

Hmmm... what?

I meant that it is weird to use ppi as base for document size when obviously physical size is the more meaningful one. This opens up all kind of problems as I cannot be sure if pasted vector element is of right size or if its size has been re-interpreted based on its assumed ppi. 

It is not even consistent – I created a A5 document @150 dpi in Photo and in Publisher and placed those to Publisher page. One created in Photo was 50% size of the Publisher created one...

Link to post
Share on other sites
2 hours ago, Fixx said:

I meant that it is weird to use ppi as base for document size when obviously physical size is the more meaningful one.

I see what you are getting at, but the two concepts are functionally equivalent: 3 inches at 600 ppi should give the same number of pixels as 6 inches at 300 ppi but should be scaled accordingly.  Raster image formats for example (such as TIFF) don't store physical dimensions at all, other than the ppi/dpi and the size in pixels; the other physical dimensions are calculated from that.  If the image is 300 ppi and has a resolution of 3000 x 600 then the width is 3000 / 300 = 10 inches and the height 600 / 300 = 2 inches.

For a TIFF file (or other raster format) there is little choice but to use this as the basis for determining the physical size.

It is not clear how Serif is storing the sizes internally within the Affinity documents (whether the physical width/height is calculated in like manner to a TIFF file or is stored directly) but either way this information can be determined.

 

2 hours ago, Fixx said:

re-interpreted based on its assumed ppi

There should be no need to "assume" ppi unless it is not known for the placed file.  It will be known for an Affinity document, but may not be specified for some image formats, in which case there would be no basis upon which to determine physical dimensions for those and the software would need to guess either way when placing them.

 

2 hours ago, Fixx said:

I created a A5 document @150 dpi in Photo and in Publisher and placed those to Publisher page. One created in Photo was 50% size of the Publisher created one...

I agree that this should not be happening.  I can see the behavior of Photo being to place images such that they match pixel-for-pixel rather than looking at the physical dimensions, but Publisher should be using the physical dimensions if they are available when pacing the images.  Designer I could see arguments for going either way...  but in any case, it should be consistent within the application as to the policy for how images are sized when placed.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.