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

Dalibor Puljiz

Members
  • Posts

    32
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. True. I never denied that. The thing is - once I apply a destructive action (change color space, raster&trim, flatten, especially to delete the initial snapshot etc.) and then do the [Save] I don't expect that my file should contain any history garbage leftovers before that destructive action. And yet it does. There are millions of ways to save the increments, out of which Affinity is offering wonderful options to save the History and Snapshots. However, if I choose not to proceed with these options, I expect the program to obey it. That's why I consider it an undesired behavior and hence the bug. I hope this explanation makes sense.
  2. We're running in circles. I have attached the file above, so you may check for yourself. The number of us have already confirmed that it's not the way it's supposed to be, and that there is indeed a problem. So - I still think there is a bug in the software that should be addressed. As for myself, I can live with the workarounds, but denying the issue won't help anyone. I'm now resting my case.
  3. I would have agreed with you if deleting the snapshot and then saving the file would have made the things work. As the conducted tests are proving, this is not the case. (I don't want to go into solicitation of the initial snapshot, let's leave it as this is the way the app is designed).
  4. Yes, I've seen his post. He has confirmed what's already been said - a workaround to the said problem. This is a bug to be dealt with.
  5. @Callum I appreciate your comment, however, as you could see above: If I used [Save As] it only dropped from 55.8 to 48.1 MB (still too large) If I copy-pasted over to a new templated it dropped from 55.8 to 2.5 MB (perfect) In addition to that, any extra addition to a file and then [Save], would add new 2-3 MB to a file. So, with like 50 saves the file would have been over 100 MBs. So, you may or may not agree if this be a bug, but if it would be me, I would consider it as a matter to look into, at least.
  6. I got bunch of large CMYK JPGs i needed to adjust. My workflow in 90% of the cases went like this: Crop down to 1250x687 Convert color profile down to RGB/8 Adjust colors if necessary using adjustments layers Export back to jpg [Save As] the adopted file Couldn't be easier, but it adds like 18-45 MB, unjustified, per file. I hope the most of us can agree that copy/paste method could be a workaround, but not a real solution to this issue. Affinity Photo should take care of the garbage prior to saving the file. Imagine having 100 of files like that wasting 2-4 GB of disk space, cloud space etc.
  7. I'm sorry if I wasn't clear enough. Do this: Open the attached file (55.8 MB) - single layer with nothing else - no adjustments, no filters, no masks, no history (supposedly) - as simple as possible Try [Save As] - it cuts down size to 48.1 MB Paste that layer to a brand new 1250x687 template, save it - the size is now correct 2.53 MB If I were a developer, this course of action would tell me there was something with the saving procedure. I understand the photo editing tool's files need to be bigger in size due to speed or composition or history or whatever, but this case has nothing to do with that. FileThatKeepsGrowing.afphoto
  8. I'd gladly post the file to the developers, no problem there. I'm just not sure if they are reading this thread?
  9. Interesting. I just tried to copy/paste the layer onto a fresh empty document, as opposed to [Save As] which didn't do anything. The file size has dropped to expected 2.53MB. I still don't see this as solution, though.
  10. So, the initial files were JPG CMYK which I converted immediately to RGB8 since I need it for the web purposes. Normally, I'd like to keep all the original sizes, and the adjustment layers, but since the file keeps getting bigger by 2-3MB on each save, I've trimmed and rasterized everything just to keep track of the sizes. Just tried "deleting snapshot". And it is not helping at all. There are basically no further snapshot except the first one. Then, deleting this one, and saving it, the file still keeps getting bigger. Anyhow, to underline the simple procedure I used: (1) take the file, (2) crop to 1250x687, (3) rasterize, trim, remove CMYK, (4) maybe simple adjustment layer, (5) save it. I'm pretty sure something is not right there on saving. The size and procedure simply does not add up to a file size. Luckily I don't really need those .afphoto files due to simple steps taken, but still - imagine having several hundred of such files.
  11. Save As is what I've been doing all the time and that's how I noticed in the first place. 1250x687x RGB/8 with flatten out, rasterized and trimmed single layer should not comprise more than 2.5MB, especially not on a new save. I'm now getting anything from 18 to 53+ MB. It is ridiculous. I don't think "speed" can justify it out. I'm also pretty sure 1.8 didn't produce such big files.
  12. Just reported as a bug in the respected forum. The link here. Let's see what the guys will say.
  13. As part of a workflow I worked on 1200x1200 and 1250x687 images, all RGB/8 images, single layer. My experiments have proved that on each saving the Affinity Photo is adding like 2-3 new MB to the file size, whatever I do. For example, my last 1250x687 RGB/8, only one background layer - file is now 43.9M which is more than ridiculous, Rasterize & Trim action makes no difference. The history saving is turned off. I'm pretty sure this is a bug and the file is full of garbage data. Even more info in the post thread here.
  14. Just made an experiment to a 43MB (1250x0687 RGB/8 single layer) file: Turned on the History Saving Saved the file, it got increased to 46MB Reopened, turned off history, saved back to "only" 30MB It's still ridiculous. Such file should not be bigger than 2.5MB, fully uncompressed. (1250x687x3 bytes)
×
×
  • 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.