Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > sci.image.processing > #4501 > unrolled thread

tag for edited file

Started bydale <dale@dalekelly.org>
First post2020-07-17 17:21 -0400
Last post2020-07-23 16:04 -0400
Articles 10 — 4 participants

Back to article view | Back to sci.image.processing


Contents

  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

#4501 — tag for edited file

Fromdale <dale@dalekelly.org>
Date2020-07-17 17:21 -0400
Subjecttag for edited file
Message-ID<dapqa1.90u.19.1@news.alt.net>
What about a tag in an image file indicating it is not the original?

Taking it further, what about including each edited image in the file?


-- 
Minister Dale Kelly, Ph.D.
https://www.dalekelly.org/
Board Certified Holistic Health Practitioner
Board Certified Alternative Medical Practitioner

[toc] | [next] | [standalone]


#4502

From"Carlos E.R." <robin_listas@es.invalid>
Date2020-07-18 00:45 +0200
Message-ID<s8m9ug-lu3.ln1@Telcontar.valinor>
In reply to#4501
On 17/07/2020 23.21, dale wrote:
> What about a tag in an image file indicating it is not the original?

And how would you mandate it being obeyed?

> 
> Taking it further, what about including each edited image in the file?

making the file huge.

However, that's an history file. The Gimp saves images that way, undo works.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#4504

Fromnospam <nospam@nospam.invalid>
Date2020-07-18 11:37 -0400
Message-ID<180720201137364907%nospam@nospam.invalid>
In reply to#4502
In article <s8m9ug-lu3.ln1@Telcontar.valinor>, Carlos E.R.
<robin_listas@es.invalid> wrote:

> On 17/07/2020 23.21, dale wrote:
> > What about a tag in an image file indicating it is not the original?
> 
> And how would you mandate it being obeyed?

the bigger problem is preventing its removal.

the correct way to indicate an image original and never modified is to
cryptographically sign it, which is what some cameras do.

> > Taking it further, what about including each edited image in the file?
> 
> making the file huge.

only if done incorrectly.

> 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.

[toc] | [prev] | [next] | [standalone]


#4505

From"Carlos E.R." <robin_listas@es.invalid>
Date2020-07-21 15:03 +0200
Message-ID<bl5jug-11o.ln1@Telcontar.valinor>
In reply to#4504
On 18/07/2020 17.37, nospam wrote:
> In article <s8m9ug-lu3.ln1@Telcontar.valinor>, Carlos E.R.
> <robin_listas@es.invalid> wrote:
> 
>> On 17/07/2020 23.21, dale wrote:
>>> What about a tag in an image file indicating it is not the original?
>>
>> And how would you mandate it being obeyed?
> 
> the bigger problem is preventing its removal.
> 
> the correct way to indicate an image original and never modified is to
> cryptographically sign it, which is what some cameras do.

Interesting.

> 
>>> 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.


> 
>> 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.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#4506

Fromnospam <nospam@nospam.invalid>
Date2020-07-21 10:13 -0400
Message-ID<210720201013177237%nospam@nospam.invalid>
In reply to#4505
In article <bl5jug-11o.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. 

each step is *tiny*, measured in bytes and replaying is *fast*,
especially when rendered on a gpu.

> >> 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.

[toc] | [prev] | [next] | [standalone]


#4507

From"Carlos E.R." <robin_listas@es.invalid>
Date2020-07-21 21:33 +0200
Message-ID<khsjug-d9t.ln1@Telcontar.valinor>
In reply to#4506
On 21/07/2020 16.13, nospam wrote:
> In article <bl5jug-11o.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, and needs having the same application for 
replaying the steps.

> 
> each step is *tiny*, measured in bytes and replaying is *fast*,
> especially when rendered on a gpu.
> 
>>>> 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.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#4508

Fromnospam <nospam@nospam.invalid>
Date2020-07-21 18:45 -0400
Message-ID<210720201845593004%nospam@nospam.invalid>
In reply to#4507
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.

[toc] | [prev] | [next] | [standalone]


#4503

FromMartin Brown <'''newspam'''@nezumi.demon.co.uk>
Date2020-07-18 16:34 +0100
Message-ID<rev4q3$evn$1@gioia.aioe.org>
In reply to#4501
On 17/07/2020 22:21, dale wrote:
> What about a tag in an image file indicating it is not the original?

Utterly pointless. Anyone that understands the file formats can tell if 
something has been through one of the common image editing programs and 
many cameras include enough meta information and use custom quantisation 
tables in their JPEGs to effectively have signed the original image.

You cannot stop someone producing a convincing edited fake that looks 
entirely authentic using already existing tools.
> 
> Taking it further, what about including each edited image in the file?

If you want the file size to grow exponentially then why not?

Strangely NASA have a bug in their workflow that means sometimes they 
publish images which contain two or three identical thumbnails with a 
brace of original images concatenated. Unclear how or why they do it.

Mickeysoft Word does that sometimes to corporate documents where users 
drag and drop images into report templates originally written in a 
legacy version. The document grows exponentially in size each time it is 
edited with different versions of Word as more and more orphaned image 
data accumulates in the file with each iteration.

-- 
Regards,
Martin Brown

[toc] | [prev] | [next] | [standalone]


#4510

Fromdale <dale@dalekelly.org>
Date2020-07-23 15:54 -0400
Message-ID<db9fdj.rln.19.1@news.alt.net>
In reply to#4501
On 7/17/2020 5:21 PM, dale wrote:
> What about a tag in an image file indicating it is not the original?
> 
> Taking it further, what about including each edited image in the file?
> 
> 

some kind of signed image might also be a way to protect copyright

-- 
Minister Dale Kelly, Ph.D.
https://www.dalekelly.org/
Board Certified Holistic Health Practitioner
Board Certified Alternative Medical Practitioner

[toc] | [prev] | [next] | [standalone]


#4511

Fromnospam <nospam@nospam.invalid>
Date2020-07-23 16:04 -0400
Message-ID<230720201604099964%nospam@nospam.invalid>
In reply to#4510
In article <db9fdj.rln.19.1@news.alt.net>, dale <dale@dalekelly.org>
wrote:

> some kind of signed image might also be a way to protect copyright

it is.

[toc] | [prev] | [standalone]


Back to top | Article view | sci.image.processing


csiph-web