Jump to content
You must now use your email address to sign in [click for more info] ×

BC15

Members
  • Posts

    35
  • Joined

  • Last visited

Everything posted by BC15

  1. I don't see any benefit of compressing tif files apart from them taking up less space and storage is so cheap nowadays that this is not an issue, even for a largeish image library like mine. I'm not sure (because I don't know!) that compressing the tif would remove the alpha channel anyway and it's this that is the issue, rather than the size. Storing full size tifs is just a personal choice and I'm happy with this as my philosophy is the least processing on an image the better. The issue here is not actually the size of the tif, it is the fact that there is an extra channel within it which other software (like photoshop) treats as a layer even if it's not! The size was just something I noticed when Canon's DPP 4 (which I have to use to copy the Affinity Photo 8 bits to new 8 bits to recreate the missing EXIF thumnbail) failed to recognise the Affinity tif with the extra channel. If this hadn't happened I probably would not have noticed it. Compatability with other software is crucial. Most of my agents use jpegs and because of the missing EXIF thumbnail I also have to batch process the 8 bit files in DPP 4 to create them and as this doesn't recognise the tifs with embedded alpa channel this wouldn't work either and this is something I do on a regular basis (I don't save jpegs in my library, just generate them from the 8 bit tifs when required).
  2. Fair enough - the important thing is that the fill works and gives me what I need with very little additional effort required...... 'Problem' solved!
  3. The examples I sent were just roughly done - I didn't realise the importance of any transparent pixels at this time. To double check, I took a picture of a bright grey sky and did the crop revealing the transparent pixels at the top. I cropped just a little in from both edges to make sure there were no transparent pixels at the horizontal edges. I then carefully cloned the transparent area with pixels from the rest of the image. I then filled the alpha channel and viewed the almost white image at 100%. No black pixels appeared and they would have easily shown up against the white pixels that the image consisted of.
  4. Going to the channels tab and using Fill as you suggested does work, even though no pixels are actually filled in as they are already 'filled' with cloned material from the rest of the image and no black pixels from the fill are present. Gives me the result I want though................
  5. Sorry I don't understand - If it only exists when I have transparent pixels, how come it is included in the tif when I have replaced all of those transparent pixels by pixels cloned from the rest of the image? I am not trying to pick holes in Affinty Photo. I am trying to work with it as a replacement to Photoshop. I tried asking questions about what to me was an issue on the forum, but I didn't get any responses that explained what was happening. I had initally thought I was probably doing something wrong. When this didn't get me anywhere I decided that my only course of action was to report it as a 'bug'. It is an issue to me and I am simply looking for a solution where the alpha 'layer' or whatever it is can be 'flattened' as it can be in photoshop, to revert the file to a 'normal' tif with a 'normal' size.
  6. Not sure I understand the alpha channel, but from what you are saying this only exists when there are transparent pixels? If that is the case, when I fill in all those pixels should this not disappear? Is the alpha channel exported with the tiff something different to a layer? Photoshop appears to treat this as a layer as it appears as a 'Layer 0' and can be flattened. Canon's DPP 4 software also cannot read this larger tif with embedded alpa channel. I could use photoshop to overcome what to me is a 'problem', but I am trying to replace photoshop with affinity photo..... Is there no way of flattening this alpha channel to make the 8 bit file the 'correct' file size (ie half the 16 bit file size).
  7. I'm attaching a series of screen prints which shows the processing of the 16 bit file in Affinity Photo....... Screen 1.mht
  8. No - the file I've just attached is the 8 bit output file that is correct. The file I sent you before is the one that has the layer called 8 bit problem tif. Both these files are from the same 16 bit input tif (which I also sent you). The problem file is when I've used the crop tool as describes, the most recent one is when I have not done this. The difference in size between these 2 files is 7.8 mb.
  9. Not sure how to do this. I am sending the same file where the file size is correct where I haven't cropped....... I'm sure there must be a hidden layer in the larger file - one that Affinty creates when cropping outside the image boundary, but a layer that doesn't show up in Affinity itself, although it does show up as Layer 0 when the 8 bit image is viewed in Photoshop. My workflow for the problem image I sent you is very straightforward as follows: Open 16 bit image Using the crop tool at the absolute size I move the crop tool up to crop out the bottom part of the image and create empty space at the top of the image. Using the clone tool I then copy some of the image content into the empty space at the top. I then export the image as an 8 bit tiff. 8_Bit_Image_normal.tiff
  10. No - This is always unticked. Just noticed that this problem occurs however small the amount of space outside the image is. I just cropped an image to straighten it and I noticed I left just a tiny space in one corner that was outside the original image. I cloned this space out, but when save the image was 76.2 mb instead of 57 mb. I'm sure you can very easily duplicate this with any 16 bit image. Also - I have tried Document / Flatten, even though no layers are shown in Affinity Photo, but this makes no difference.
  11. To try and get a smaller file I have used an old 16 bit file which is only 47mb in size, which I attach. When I export this in Affinity as an 8 bit file this becomes a 23.4mb, which is correct. When I use the crop tool as described and then export it as an 8 bit file it's size is 31.2 mb which is incorrect. I am attaching both the 16 bit input file and the 8 bit problem file as requested.... 8_Bit_problem.tiff 16_Bit_Image.TIF
  12. When processing a 114 mb 16 bit tif file, in Affinity Photo, after various adjustment layers are made and then flattened, the file is exported as an 8 bit tif file with the size of 57 mb as you would expect. However when the crop tool is used to reposition the image to cut the bottom part of the image and leave a blank area at the top of the image for later filling in using the clone tool, the size of the exported 8 bit tif is 76.2 mb. The dimensions of the image is correct, just the file size is 'wrong'. The crop parameters are exactly the same dimensions as the original. Before exporting I have added other adjustment layers and then flattened the image, but whether I do this or not, the output size is still 76.2 mb. If I open this exported 8 bit file in Photoshop it shows as 'Layer 0' and if I then flatten it in Photoshop it then saves as a 57 mb file. The only conclusion I can draw from this is that Affinity Photo is creating an invisible layer when the crop tool is used in this way and this layer cannot be flattened within Affinity itself. I have used this technique now on a few images, each with different amounts of crop used and the output file is always the same - 76.2 mb.
  13. R C_R - Thanks for the suggestion, but I require uncompressed Tif files and this works fine with all other images. It's looking increasingly like a bug in Affinity, so I'll have to report it.
  14. If I open the 8 bit image in Photoshop it appears as 'Layer 0'. If I go to save it as it is it asks 'Do you want to include layers'. If I flatten the image in Photoshop and then save it it is saved as the correct size (57 mb). It would appear that for some reasom Affinity is saving it with a layer, although the image has been flattened. In Affinity I then tried just moving the crop box to include empty space above the image and roughly filled it. I did not add any adjustment layers, so there were no layers to flatten. When exported it was 76.2 mb. The only conclusion I can draw is that Affinity is creating and 'invisible' layer and saving it regardless, increasing the file size.
  15. I am processing 16 bit tif files in Affinity Photo and after flattening exporting them to another folder as 8 bit files. The 16 bit files are 114mb and the 8 bit files output are of course usually 57mb as you would expect. Except that is when I have used the crop feature to remove part of the image from the bottom of the picture or extend the image in some way, leaving an unfilled area of the image which I then fill in using the clone tool. The crop parameters are set the same as the original image. I then make any layer adjustments such as curves and levels and flatten the image under the Documents menu tab as I do with all the images, before exporting them. The output looks fine and viewing the properties show that it is identical to the original size as defined in pixels (5472 x 3648), except that the actual size is now 76.2 mb, instead of 57 mb. This size is the same for all the 8 bit files that have been adjusted in this way - and of the amount of adjustment in the crop was different each time. The reason I spotted this was that when I used Canons DPP 4 software to batch output the 8 bit images to another folder (to generate the missing EXIF thumbnail - see a different thread on this subject), it will neither display or process these images. Maybe I'm doing something wrong here or maybe there is a problem with Affinity, but any help would be appreciated.
  16. That may well be the case, but although the thumbnail is generated more quickly on the Affinity Jpeg than the Affinity Tif, it still takes more time to do this this when displaying a folder of images. This inevitably slows down the selection and viewing of the Jpegs when deciding which image goes to which agent. As I regularly deal with hundreds if not thousands of images in this way, this delay does have an impact.
  17. Just realised that the lack of EXIF thumbnail creation will also prevent me from using Affinity to convert the 8 bit tifs to jpegs for sending to agents, so will have to use DPP 4 or Photoshop to do this as well........fingers crossed that a fix is coming. Pity there is not an agreed standard that all imaging companies could adopt to ensure that all the software available to us consumers is compatible. This would be good for everyone!
  18. Thanks Dan for your clarification. Looks like the 2 thumbnail theory has been proved to be correct! Is there a good chance that the EXIF thumbnail could be produced in a future release of Affinity? Just to add some information about this in other software, I have found that Canon's own DPP 4 RAW conversion software does create an EXIF thumbnail when it outputs a tif file. I have also used this as a workaround as I can run a batch process within it to read all the Affinity 8 bit images and write them to another folder. As it does this it creates the missing EXIF thumbnail so BreezeBrowser is happy.
  19. Brilliant! Thanks very much for that..........CTRL 1 for 100% and CTRL 2 for Fit to Screen are now set!
  20. Just a minor suggestion about the CTRL 1 and CTRL 0 keys to display the image at 100% or 'fit on screen'. From a logical viewpoint I can see that CTRL 1 makes sense for 100% and I guess that CTRL 0 in this context makes sense for 'fit on screen'. However from a practical point of view toggling between these 2 displays is something that tends to be done quite a lot during the processing phase of the workflow. The ability to simply use one hand to CTRL 1 to show the image at 100% works very well. However when I want to go back to 'fit on screen' I have to either use 2 hands to use CTRL 0 or use my left hand to do this, which is much more difficult (I have tried it and it's very awkward). If the CTRL 0 was replaced with CTRL 2 (for example) this would mean that it would be very easy to toggle between 100% and 'fit on screen' with one hand. This would simplify the processing and make it more efficient.
  21. Hi Ian - I think the problem here is that I'm not sure how it can be confirmed that the EXIF thumbnail has actually been created. Given that Dan, who is a member of staff, has confirmed that the EXIF thumbnail is not created by Affinity, I am loathe to trust 3rd party software that contradicts this. The fact that I take an 8 bit affinity produced tif and simply open and save it to another folder in photoshop with no processing at all and this solves the problem, would seem to indicate that Photoshop creates the EXIF thumbnail when it writes the file and Affinity doesn't. Also, It does make sense that the lack of the EXIF thumbnail causes a delay in displaying the image as a thumbnail as one would have to be created. As suggested by Walt Farrell above, it may well be that there is more than one thumbnail involved, but I can only wait for Affinity to respond to let us know what is actually happening......
  22. Oh yes - I see where you are coming from.... The term EXIF thumbnail I got from BreezeBrowser support as follows: ' It sounds as though Affinity Photo is not saving an EXIF thumbnail image'. Dan - can you throw any light on this?
  23. Hi Walt. Sorry, I'm not sure I follow what your saying. Firstly the problem occurs with BreezeBrowser which is very slow to display the Affinity Photo precessed 8 bit tiffs because (according to BeezeBrowser support) they don't have an embedded thumbnail. Without this thumbnail, one has to be temporariliy generated each time for every image - hence the slow display. I am assuming that there is only one imbedded thumbnail and that this is in the EXIF as no mention of another thumbnail has been mentioned. Doesn't mean this isn't the case however! I am intrigued by your comment ' when you tell Affinity to embed a thumbnail' . How do you tell Affinity to do this? If this is possible, this would answer my original question and potentially resolve the issue....by the way the speed problem is not with XnView, but BreezeBrowser. I've never used XnView before and only downloaded it in an attempt to see whether an EXIF thumbnail was present (as suggested in this forum), but according to Dan C (Staff), Affinity does not imbed a thumbnail. If there is no thumbnail, the only conclusion I can draw is when XnView is set to display only the imbedded thumbnail it does not work as a thumbnail is displayed.
  24. Thanks for that Dan. This is really important as it will make Affinity Photo more compatible with other imaging software. At the moment I have to run an action in photoshop to open each image and then save it to another folder which regenerates the EXIF thumbnail. As I'm looking to completely replace Photoshop with Affinity Photo this is a bit of a drawback! Also this means that XnView does not show the embedded thumbnail as it seems to indicate.
×
×
  • Create New...

Important Information

Terms of Use | 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.