Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.image.processing > #4508
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Newsgroups | rec.photo.digital, sci.engr.color, sci.image.processing |
| Subject | Re: tag for edited file |
| Date | 2020-07-21 18:45 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <210720201845593004%nospam@nospam.invalid> (permalink) |
| References | (1 earlier) <s8m9ug-lu3.ln1@Telcontar.valinor> <180720201137364907%nospam@nospam.invalid> <bl5jug-11o.ln1@Telcontar.valinor> <210720201013177237%nospam@nospam.invalid> <khsjug-d9t.ln1@Telcontar.valinor> |
Cross-posted to 3 groups.
In article <khsjug-d9t.ln1@Telcontar.valinor>, Carlos E.R. <robin_listas@es.invalid> wrote: > >>>>> Taking it further, what about including each edited image in the file? > >>>> > >>>> making the file huge. > >>> > >>> only if done incorrectly. > >> > >> No way. Say the original is 10 Mb. Each modification saved is another 10 > >> Mb. > > > > that's doing it incorrectly. > > > > the correct way to do it is by saving an edit list and replay it, not > > saving a version of the entire image each time. > > That's not what the OP said, he initially wanted a way to confirm that a photo had not been altered, and the only way to do that is by signing it. he mentioned including a snapshot at every step. that's a bad idea for all sorts of reasons. > and needs having the same application for > replaying the steps. not an issue, and other compatible apps can work. > >>>> However, that's an history file. The Gimp saves images that way, undo > >>>> works. > >>> > >>> saving the undo history in the image is silly. is that gimp's lame > >>> attempt at non-destructive editing because they refuse to do it > >>> correctly? if so, that's laughable. > >> > >> Ha ha. They are doing it correctly. You are biased. > > > > nope. they aren't doing it at all and have no immediate plans to do so. > > > > they now claim that it might be added in version 3.2 (a change from > > their previous claim which was a flat 'no'), except they haven't > > figured out how to do it, according to their own road map. > > > > the gimp is a toy, lacking features photoshop had 30 years ago and > > *significantly* slower on the same hardware. > > Ha ha. read their roadmap and do some comparisons.
Back to sci.image.processing | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
tag for edited file dale <dale@dalekelly.org> - 2020-07-17 17:21 -0400
Re: tag for edited file "Carlos E.R." <robin_listas@es.invalid> - 2020-07-18 00:45 +0200
Re: tag for edited file nospam <nospam@nospam.invalid> - 2020-07-18 11:37 -0400
Re: tag for edited file "Carlos E.R." <robin_listas@es.invalid> - 2020-07-21 15:03 +0200
Re: tag for edited file nospam <nospam@nospam.invalid> - 2020-07-21 10:13 -0400
Re: tag for edited file "Carlos E.R." <robin_listas@es.invalid> - 2020-07-21 21:33 +0200
Re: tag for edited file nospam <nospam@nospam.invalid> - 2020-07-21 18:45 -0400
Re: tag for edited file Martin Brown <'''newspam'''@nezumi.demon.co.uk> - 2020-07-18 16:34 +0100
Re: tag for edited file dale <dale@dalekelly.org> - 2020-07-23 15:54 -0400
Re: tag for edited file nospam <nospam@nospam.invalid> - 2020-07-23 16:04 -0400
csiph-web