Alexia Death wrote: > Even the act of loading a file into memory as pixel data and then > recompressing on save is lossy for lossy formats and grayscale formats > outright destroy information if the original is color. It is not This type of argument simply doesn't hold water. A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends. They have chosen a certain image quality vs. file size tradeoff, and not maintaining this choice is discarding the users preferences. To load a compressed image, and then simply invent 90% of the bits out of thin air, add the invented bits back into the image and then carefully preserve every one of them is just nonsense. Honouring the idea of loss prevention when dealing with lossily compressed sources simply means (by default) maintaining the same level of quality/size traedoff. [ Of course the user should have the option of changing this tradeoff if they so desire. ] > realistic to keep track for each format feature by feature, if the > image is now restorably exported or not, it would make maintaining > gimp code and adding features a horror... Each change anywhere would > recquire going over all export plugins making sure their supported > feature lists are up to date... This separation makes it clear cut. That's an implementation limitation, not a fundamental logical constraint. The internal storage just has to keep track of what image feature is being used (trivial to automatic), and for the various file format code to check whether they can save all the features used. There is nothing fundamentally hard about creating or maintaining such an approach, although I can well believe and accept that development history may prevent such an approach in Gimp with any ease. But if that is the case, the honest thing is to accept this and work towards overcoming it, rather than pointing to talk of "loss prevention". > The project file, the one that keeps ervery feature of gimp intact is > the xcf and you save to it. Any rendering you export to. And this > distinction will get even more important when we get to gegl backend > in full. So what ? You certainly don't want to create a superset storage file unless it contains more than the original file contains. To do so is simply wasteful and a burden on the user. > In short, options were considered, arguments have been had. We didn't > do this to anoy anybody, we did this based on alot of consideration > and a future of GIMP as a nondestructive image editor. Not thought through with enough imagination or consideration of the users perspective, in my opinion. Graeme Gill. _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
