On Thu, Jan 2, 2014 at 11:36 PM, Robert Vorsteg wrote:

Yes. And a more important point that Norbert goes on to make is that developers should listen to users and take theminto account.

I've listened to you. I still disagree with you.

Are there any GIMP developers who read this list?

Push harder, be more demanding, be less respectful, and there will be none.

Alexandre

On Thu, 2014-01-02 at 14:36 -0500, Robert Vorsteg wrote:

- opening a jpg file
- editing
- saving
should result in a saved version of the original file,

If you happen to be using a JPEG editor that's probably true, although watch that since JPEG compression is lossy this is not always a good workflow.

Similarly if you open a binary executable and change the contents of a string, keeping the length constant, and save, you get a new binary executable, but that does not make the binary editor be a compiler.

The degree of emotional attachment people have to "save as" rather than "expert as" is a little bewildering.

Are there any GIMP developers who read this list?

Some. Fewer over time. There aren't that many GIMP developers to start with, and every message (including mine!) takes time away from coding.

They removed
a feature ( save as) that many users want,

The ability to write a JPEG file to disk has not been removed. The way you access that feature changed slightly.

Constructive suggestions about how to make a more coherent workflow in GIMP are welcomed. Whining about change is not so welcome.

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
The barefoot typographer.

Robert, tell me -

If you open would "open" a 2D drawing with a CAD software, do a lot of editing with
3D operations, what would you expect it to do when you press "save"?

One thing is certain, we should insist that when you open any non-XCF file, it should be listed as an "import" operation - it converts a flat image file into a GIMP image. An image open in GIMP is a complex project with layers, masks and from gimp-2.9 on, different bit depths per component, information on text layers and so on.

All other file formats but .XCF and .ORA can but take a snapshot of this work. And even ORA won't map 1:1 with GIMP capabilities.

It does not even begin to make sense to tell the work can be "saved" to a flat format - and the current situation fixed it.

The workflow for people wanting just to "fix a lot of broken images" can be improved, and that is made under _reasonable_ and constructive suggestions. Demanding regression to a broken behavior is neither.

The save-as-XCF nly behavior actually makes the program easier to use for most people. One now just don't have to have "personal flaws" for saving as XCF and checking the exported files in order not to loose information: the normal program workflow allows one naturally to preserve both his ongoing work _and_ the original photographic work, by not overwriting it automatically.

And the "price" to pay for that is to have to stop to think for a fraction of a second at the time one is done and should export the final resulting snapshot of the work done, having to select file->export instead of file->save.

Moreover, as of GIMP 2.8.10, the "export" dialog can be opened by a single click when one tries to export to a non-native format from the save dialog. Not shure if you are aware of that, since that can't be such a burden as to generate so much complaint anymore.

js
-> wrote:

On Thu, Jan 2, 2014 at 11:36 PM, Robert Vorsteg wrote:

Yes. And a more important point that Norbert goes on to make is that developers should listen to users and take theminto account.

I've listened to you. I still disagree with you.

Are there any GIMP developers who read this list?

Push harder, be more demanding, be less respectful, and there will be none.

Alexandre _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Hmmm Robert.....

I'm only a User of GIMP not a developer of any other Software.

I can't understand the Problem! IMO is the new Save-Command to Save in XCF the only right way.

According to my understanding is the JPG not the right Format to save my Work in the Work Process.

JPG is the Format for the final Picture and I'm lucky, that GIMP now save the Work in XCF.

Greetings

I've watched these threads come an go and I must be missing something. When this new behavior first arrived, like everyone else I was used to the old way and having to learn a new work-flow is never fun. Regardless I just figured this was the way it was going to be so I adopted it immediately. At this point I can't even remember exactly how things used to work as the new way is now ingrained in my work-flow. What is so hard about Ctrl+o to overwrite, or Shift-Ctrl+e to export?

If we could funnel all the wasted energy spent trying to buck this new feature, we could be up to gimp 3.0 by now. I've been a dog with a bone on many issues, but the reasoning behind this decision was a sound one and would rather put my energies into something more productive. This just isn't that big of a deal. The sooner you accept it, the sooner you will forget what it was you were so worried about.

akovia

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service

On 01/02/2014 06:17 PM, akovia wrote:

I've watched these threads come an go and I must be missing something. When this new behavior first arrived, like everyone else I was used to the old way and having to learn a new work-flow is never fun. Regardless I just figured this was the way it was going to be so I adopted it immediately. At this point I can't even remember exactly how things used to work as the new way is now ingrained in my work-flow. What is so hard about Ctrl+o to overwrite, or Shift-Ctrl+e to export?

B-B-B-But, control-e just isn't the same! They say it's the same but it isn't.

If I do control-e to save my image as a JPEG, then try to close the file...

I have to, to, to.... discard the state of the image in the editor!

They make me alt-d to close the image!

THEY MAKE ME PRESS ALT-D TO CLOSE THE IMAGE!

WAAAAAAAAAAAAAAAAAAAAAAAHHHH!!!

WHY, WHY, WHY in the name of God have they done this to me?

WHY did they have to RUIN my LIFE?!

/rant

:o)

Steve

On 2 January 2014 19:52, Daniel Hauck wrote:

I think you're missing the point. MOST users, just as with almost all other software, do not use the advanced features of advanced software. I see it all the time. I see people load up MS Word to check the spelling of something else (copy and paste) of programs which do not support that feature. And this amazing gold standard professional software like Adobe Photoshop and MS Word and lots more allow people to save in formats which are lossy.

ok. Stop there.
open a "txt" file with "ms word".Not a ".doc", "docx", "odt". click file->save.
Read what it tells you. I rest the case.

There is nothing "advanced" in preserving the editing information of one's project.

(Now, I actually had not used "ms word" since, like, 1997. But I suppose it won't overwrite your "txt" file without telling you a thing or two about the file format you are using. Libreoffice won't. )

BTW, did you intend this rather unconstructive message just for me, or for the whole list?
The GIMP lists are configured in a way the default reply goes only to the sender.

js
->

I'm agree with jankardel, :)

I prefer to keep the xcf, when I wanna save (i.e. by pressing ctrl+s) my gimp project.

Then when I wanna export it to any other filetype (png, jpeg, gif, pdf etc) I prefer push the ctrl+E for exporting it..

But, maybe the gimp developer should add a feature to reassign the shortcut for commands, so if some buddy has their own preferably shortcut, they can assign it by them self.. :)

Best Regard, Alvin Hikmawan

---nonstop learn, share and grow

WA: 0819 4969 3787 On Jan 3, 2014 7:45 AM, "Steve Kinney" wrote:

On 01/02/2014 06:17 PM, akovia wrote:

I've watched these threads come an go and I must be missing something. When this new behavior first arrived, like everyone else I was used to the old way and having to learn a new work-flow is never fun. Regardless I just figured this was the way it was going to be so I adopted it immediately. At this point I can't even remember exactly how things used to work as the new way is now ingrained in my work-flow. What is so hard about Ctrl+o to overwrite, or Shift-Ctrl+e to export?

B-B-B-But, control-e just isn't the same! They say it's the same but it isn't.

If I do control-e to save my image as a JPEG, then try to close the file...

I have to, to, to.... discard the state of the image in the editor!

They make me alt-d to close the image!

THEY MAKE ME PRESS ALT-D TO CLOSE THE IMAGE!

WAAAAAAAAAAAAAAAAAAAAAAAHHHH!!!

WHY, WHY, WHY in the name of God have they done this to me?

WHY did they have to RUIN my LIFE?!

/rant

:o)

Steve

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Actually there is a crucial point of workflows that you are missing. In order to make workflows work well for everyone, everything should be done in approximately the same way. Each function in a GUI should use similar hotkeys, similar menu functions and all that. This was a well established reality of what we call "intuitive" meaning "we already know what to expect." "Save" in every program should behave like "Save" in most other programs. "Save As..." enhances save to enable someone to make changes in the name, location or format... just like in all other programs. This is the idea behind a unified GUI design and has been key to the success and adoption and usability of almost every program out there.

To make a car analogy, there is a reason why they are laid out the way they are. For example, every car has a steering wheel and not a yoke and not a lever. There was a time when that wasn't the case. Care to guess why that changed? There's a reason the manual (standard?) transmission was set up the way it was as well. There were any number of ways it could have been done and different car makers actually did lay their pedals out in different layouts. Many of them argued that one layout was better than another. But at the end of the day, "standard layout, design and behavior" won out for the very same reasons GUI layout, design and behavior does.

What's more? You probably use a standard keyboard layout even though there are more efficient ways to lay your keys out. Why is that? And why shouldn't your keyboard be changed out for each program you use while we're at it?

And here's the real issue why it's still a real issue. When one program does something so very differently from all the others in your workflows, that one program represents a requirement to stop and think which is, in fact, an interruption... of workflows.

Now it's not an interruption if you ONLY use GiMP. But since you're running an email program or a browser right now, chances are pretty good you do more than GiMP. So you probably already know what I'm talking about. So instead of letting you choose how to respond, let's just cut to the core purpose of this splinter in the fingers of so many users:

What is it that GiMP is attempting to accomplish with this departure from standard behavior? What was broken before that is fixed with this change? It's my understanding that it's so a lot of work on a project isn't lost through an accidental save... an accident which happens because of standard, default behaviors such as Ctrl+S saving in the format of the original file, overwriting the original file. Frankly, this is what I would consider to be an "Amateur mistake" to make...something professionals learn not to do -- usually the hard way.

To Joao:

As for being warned that data may be lost? That part of normal behavior for quite a few programs and this is completely acceptable behavior. If GiMP did that, it would also be acceptable but only if there were advanced features of the editing that might need to be saved such as multiple layers or a mask or alpha channel. And you skipped right past my point so I will ask it as direct and simple questions:

Do you believe most uses of GiMP is a full blown project? You know, with hours of work going into them?

Do you think most users of GiMP are more casual users who just want to crop, resize or otherwise make simple changes to their images? (It would be pointless to say 'then they should use something else because GiMP is far more powerful, blah blah blah' because even Photoshop users use it casually despite its bloated size and enormous capability.)

So it really comes back to what's broken about the normal way of doing things?

On 01/02/2014 07:45 PM, Steve Kinney wrote:

On 01/02/2014 06:17 PM, akovia wrote:

I've watched these threads come an go and I must be missing something. When this new behavior first arrived, like everyone else I was used to the old way and having to learn a new work-flow is never fun. Regardless I just figured this was the way it was going to be so I adopted it immediately. At this point I can't even remember exactly how things used to work as the new way is now ingrained in my work-flow. What is so hard about Ctrl+o to overwrite, or Shift-Ctrl+e to export?

B-B-B-But, control-e just isn't the same! They say it's the same but it isn't.

If I do control-e to save my image as a JPEG, then try to close the file...

I have to, to, to.... discard the state of the image in the editor!

They make me alt-d to close the image!

THEY MAKE ME PRESS ALT-D TO CLOSE THE IMAGE!

WAAAAAAAAAAAAAAAAAAAAAAAHHHH!!!

WHY, WHY, WHY in the name of God have they done this to me?

WHY did they have to RUIN my LIFE?!

/rant

:o)

Steve

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

If I intended it only for you, why would you be so rude as to publish something I wrote only to you in a public list?

On 01/02/2014 08:04 PM, Joao S. O. Bueno wrote:

On 2 January 2014 19:52, Daniel Hauck wrote:

I think you're missing the point. MOST users, just as with almost all other software, do not use the advanced features of advanced software. I see it all the time. I see people load up MS Word to check the spelling of something else (copy and paste) of programs which do not support that feature. And this amazing gold standard professional software like Adobe Photoshop and MS Word and lots more allow people to save in formats which are lossy.

ok. Stop there.
open a "txt" file with "ms word".Not a ".doc", "docx", "odt". click file->save.
Read what it tells you. I rest the case.

There is nothing "advanced" in preserving the editing information of one's project.

(Now, I actually had not used "ms word" since, like, 1997. But I suppose it won't overwrite your "txt" file without telling you a thing or two about the file format you are using. Libreoffice won't. )

BTW, did you intend this rather unconstructive message just for me, or for the whole list?
The GIMP lists are configured in a way the default reply goes only to the sender.

js
->

On 2 January 2014 19:52, Daniel Hauck wrote: I think you're missing the point. MOST users, just as with almost all other software, do not use the advanced features of advanced software.

Frankly, this is the first time I hear about a culture where it's socially acceptable nay desirable to lower the bar.

Alexandre

Come on. I just cited numerous examples. For example, while there is no reason it can't be done otherwise, "up" on a map is always north and "down" is south. If your in the southern hemisphere, there's no reason they should feel like their maps shouldn't depict their location to be at the top. But we don't usually do that because of expectations. Expectations, like units of measure and orientations and layouts and functions of controls work best because they fall within expectations which results is less confusion. (NASA knows all about that where they have had issues mixing the Imperial and metric systems before.)

People who have gone through great trouble to create improved keyboards and keyboard layouts can't seem to get beyond the human reality that keyboards are laid out inefficiently for legacy reasons but the cost of change is too high and too demanding. Even if something is "better" in some way, change is worse especially in cases like these.

"Better" is a tricky thing. In the world of machines, better is usually pretty obvious. But in the world of people, it's another matter. All this feedback should be evidence enough of that.

On 01/02/2014 08:22 PM, Alexandre Prokoudine wrote:

On 2 January 2014 19:52, Daniel Hauck wrote: I think you're missing the point. MOST users, just as with almost all other software, do not use the advanced features of advanced software.

Frankly, this is the first time I hear about a culture where it's socially acceptable nay desirable to lower the bar.

Alexandre _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Are we still talking about GIMP?

Alexandre

03 . 2014 . 5:36 "Daniel Hauck" :

Come on. I just cited numerous examples. For example, while there is no

reason it can't be done otherwise, "up" on a map is always north and "down" is south...

Yes and I'm pretty sure most people are getting what I'm driving at -- standards of function, design and behavior.

On 01/02/2014 08:44 PM, Alexandre Prokoudine wrote:

Are we still talking about GIMP?

Alexandre

03 ���. 2014 �. 5:36 ������������ "Daniel Hauck" �������:

Come on. I just cited numerous examples. For example, while there is no

reason it can't be done otherwise, "up" on a map is always north and "down" is south...
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Daniel,

We've been through this argument about standards many times. Do you really think this time you are going to finally win?

(The answer is "no", by the way.)

Alexandre 03 янв. 2014 г. 5:50 пользователь "Daniel Hauck" написал:

Yes and I'm pretty sure most people are getting what I'm driving at -- standards of function, design and behavior.

On 01/02/2014 08:44 PM, Alexandre Prokoudine wrote:

Are we still talking about GIMP?

Alexandre

03 ���. 2014 �. 5:36 ������������ "Daniel Hauck" �������:

Come on. I just cited numerous examples. For example, while there is no

reason it can't be done otherwise, "up" on a map is always north and "down"
is south...
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

No, I don't think so because this isn't a democratic situation. What you think rules out over what many others independently think and agree upon.

But let me ask you this and I'll shut up. Do you use a Dvorak keyboard or a Querty? And why?

It's a loaded question, of course. If you answer Dvorak, you win. But if you answer Querty, you lose because the world knows querty was inefficient by design and yet we continue to use it for the very reasons I have stated and that you implicitly and in practice agree.

On 01/02/2014 08:58 PM, Alexandre Prokoudine wrote:

Daniel,

We've been through this argument about standards many times. Do you really think this time you are going to finally win?

(The answer is "no", by the way.)

Alexandre 03 янв. 2014 г. 5:50 пользователь "Daniel Hauck" написал:

Yes and I'm pretty sure most people are getting what I'm driving at -- standards of function, design and behavior.

On 01/02/2014 08:44 PM, Alexandre Prokoudine wrote:

Are we still talking about GIMP?

Alexandre

03 ���. 2014 �. 5:36 ������������ "Daniel Hauck" �������:

Come on. I just cited numerous examples. For example, while there is no

reason it can't be done otherwise, "up" on a map is always north and "down"
is south...
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Daniel Hauck (daniel@yacg.com) wrote:

But if you answer Querty, you lose because the world knows querty was inefficient by design

May I quote Wikipedia?

"Contrary to popular belief, the QWERTY layout was not designed to slow the typist down, but rather to speed up typing by preventing jams. (There is also evidence that, aside from the issue of jamming, keys being further apart increases typing speed on its own, because it encourages alternation between the hands."

The whole discussion suffers from "well known facts" being pulled out of thin air, and this is not a single bit different.

Bye, Simon

simon@budig.de              http://simon.budig.de/

Nice spin. Yes, it was for mechanical reasons and to prevent the arms which had letters slamming against the ribbon and paper at a single point from hitting each other. Original layouts were based on convenience based on logical notions such as alphabetic order and frequency of use. The unfortunate reality was that it conflicted with the mechanics of typing. There can be no doubt that it was designed to work with character frequency by spreading it out and making it less likely for collisions to occur.

Other keyboard layouts contradict your notion that spreading keys out speeds things up in any way. The Dvorak layout has enjoyed a level of success and fandom precisely because it is faster among the proficient users than querty among proficient users. Querty was designed to pace keyboard entry. It can't be "paced" without being slowed.

Quoting wikipedia is almost always problematic as wikipedia is prone to edit wars and strong opinions and positions. It would be better to cite the references cited by wikipedia and in the absence of references, requisite grains of salt are recommended.

In any case, if Wikipedia is a great source of fact, then you probably also noticed mention of keyboard entry methods which are most certainly more efficient and speedy including stenotype and plover.

On 01/02/2014 10:35 PM, Simon Budig wrote:

Daniel Hauck (daniel@yacg.com) wrote:

But if you answer Querty, you lose because the world knows querty was inefficient by design

May I quote Wikipedia?

"Contrary to popular belief, the QWERTY layout was not designed to slow the typist down, but rather to speed up typing by preventing jams. (There is also evidence that, aside from the issue of jamming, keys being further apart increases typing speed on its own, because it encourages alternation between the hands."

The whole discussion suffers from "well known facts" being pulled out of thin air, and this is not a single bit different.

Bye, Simon

On Thu, 2014-01-02 at 20:19 -0500, Daniel Hauck wrote: [...]

And here's the real issue why it's still a real issue. When one program does something so very differently from all the others in your workflows, that one program represents a requirement to stop and think which is, in fact, an interruption... of workflows.

It's lucky that GIMP now works like so many other programs - inkscape, open office, blender, spreadsheet programs, ...

Do you believe most uses of GiMP is a full blown project? You know, with hours of work going into them?

It's certainly the intent. Days or weeks in some cases.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Fri, Jan 3, 2014 at 6:04 AM, Daniel Hauck wrote:

No, I don't think so because this isn't a democratic situation. What you think rules out over what many others independently think and agree upon.

But let me ask you this and I'll shut up. Do you use a Dvorak keyboard or a Querty? And why?

It's a loaded question, of course. If you answer Dvorak, you win. But if you answer Querty, you lose because the world knows querty was inefficient by design and yet we continue to use it for the very reasons I have stated and that you implicitly and in practice agree.

Did I even suggest I would like playing any games with you?

(Once again, the answer is "no".)

I do appreciate your insistence, but sadly it's misplaced. I'm quite certain that you could find a better use for your time than trying to win a war that you can't win, and that, as a matter of fact, was never a war in the first place. Although some people clearly treat it as such.

Alexandre

On 01/03/2014 05:21 AM, Liam R E Quin wrote:

It's lucky that GIMP now works like so many other programs - inkscape, open office, blender, spreadsheet programs, ...

You're wrong: gimp editor works differently. All editors, free or not free, save work in a normal way, except gimp. This misinformation is getting boring.
Q

On 2 January 2014 23:20, Daniel Hauck wrote:

If I intended it only for you, why would you be so rude as to publish something I wrote only to you in a public list?

Sorry. It was a SNAFU due to the nature of the GUI of this webmail client. on which I have no control over, and overall, I can't write to their developers complaining
that the UI hides the recipients unless the "to" field is focused. And does not support
"short ut reassignment". And can't be forked with my own tweaks. Still, I did err, and am not blaming the developers of gmail for that - as I can see this behavior do make the UI more productive for most cases.

Now, since you are still at that, I wonder, why hadn't you replied to my question:
What does MS word tells you when you open a Plain Text file, change it, and try to save back over the original file?

On 01/02/2014 08:04 PM, Joao S. O. Bueno wrote:

On 2 January 2014 19:52, Daniel Hauck wrote:

I think you're missing the point. MOST users, just as with almost all other
software, do not use the advanced features of advanced software. I see it
all the time. I see people load up MS Word to check the spelling of something else (copy and paste) of programs which do not support that feature. And this amazing gold standard professional software like Adobe Photoshop and MS Word and lots more allow people to save in formats which are lossy.

ok. Stop there.
open a "txt" file with "ms word".Not a ".doc", "docx", "odt". click file->save.
Read what it tells you. I rest the case.

There is nothing "advanced" in preserving the editing information of one's project.

(Now, I actually had not used "ms word" since, like, 1997. But I suppose it won't overwrite your "txt" file without telling you a thing or two about
the file format you are using. Libreoffice won't. )

BTW, did you intend this rather unconstructive message just for me, or for the whole list?
The GIMP lists are configured in a way the default reply goes only to the sender.

js
->

On Fri, Jan 3, 2014 at 4:17 PM, qelvin5500 wrote:

On 01/03/2014 05:21 AM, Liam R E Quin wrote:

It's lucky that GIMP now works like so many other programs - inkscape, open office, blender, spreadsheet programs, ...

You're wrong: gimp editor works differently. All editors, free or not free, save work in a normal way, except gimp. This misinformation is getting boring.

We've been through this discussion with you back when you had a different nickname in this mailing list. You've been provided with live examples of editors that do work like GIMP 2.8 in terms of saving/exporting. Which part of that absolutely has to be repeated over and over again?

Alexandre

On Fri, Jan 3, 2014, at 07:28 AM, Alexandre Prokoudine wrote:

On Fri, Jan 3, 2014 at 4:17 PM, qelvin5500 wrote:

On 01/03/2014 05:21 AM, Liam R E Quin wrote:

It's lucky that GIMP now works like so many other programs - inkscape, open office, blender, spreadsheet programs, ...

You're wrong: gimp editor works differently. All editors, free or not free, save work in a normal way, except gimp. This misinformation is getting boring.

I really do admire the passion people have for this cause, but the amount of time spent arguing their case on the mailing list could have been put to developing their own fork to make gimp work the way they like.

If it's as they say, it should be easy to put all the like minded people together to develop it. That way the world won't end, and the devs here can get back to work.

akovia

-- 
http://www.fastmail.fm - Access your email from home and the web

Daniel Hauck (daniel@yacg.com) wrote:

Nice spin.

What spin? You claimed that "querty" (you probbly mean qwerty btw.) was designed to be inefficient, when in fact it was designed for a faster typing speed.

Who is doing the spin here?

Sure, without the cumbersome mechanics there are better and faster methods, but that does not change the intent behind the design of QWERTY. What was your point again?

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Fri, Jan 3, 2014 at 4:58 PM, Simon Budig wrote:

Daniel Hauck wrote:

Nice spin.

What spin? You claimed that "querty" (you probbly mean qwerty btw.) was designed to be inefficient, when in fact it was designed for a faster typing speed.

Who is doing the spin here?

People behind the Wikipedia's QWERTY conspiracy. Isn't that obvious? :)

Alexandre

On 01/03/2014 01:51 PM, akovia wrote:

On 01/03/2014 05:21 AM, Liam R E Quin wrote:

It's lucky that GIMP now works like so many other programs - inkscape,

You're wrong: gimp editor works differently. All editors, free or not free, save work in a normal way, except gimp. This misinformation is getting boring.

I really do admire the passion people have for this cause,

Yes, me too. It means these people love Gimp and want improve it

but the

amount of time spent arguing their case on the mailing list could have been put to developing their own fork to make gimp work the way they like.

*Creating pictures* is a job, developing a software to create these picture is a different job.
That's why users feedback is very important.

Q

On 1/2/2014 4:17 PM, akovia wrote:

I've watched these threads come an go and I must be missing something. When this new behavior first arrived, like everyone else I was used to the old way and having to learn a new work-flow is never fun. Regardless I just figured this was the way it was going to be so I adopted it immediately. At this point I can't even remember exactly how things used to work as the new way is now ingrained in my work-flow. What is so hard about Ctrl+o to overwrite, or Shift-Ctrl+e to export?

If we could funnel all the wasted energy spent trying to buck this new feature, we could be up to gimp 3.0 by now. I've been a dog with a bone on many issues, but the reasoning behind this decision was a sound one and would rather put my energies into something more productive. This just isn't that big of a deal. The sooner you accept it, the sooner you will forget what it was you were so worried about.

Infrequent user of GIMP, but I'll ask: is there no way to map the control keys differently?

Date: Thu, 2 Jan 2014 23:04:50 -0200 From: gwidion@mpc.com.br
To: daniel@yacg.com; gimp-user-list@gnome.org Subject: Re: [Gimp-user] gimp users matter

ok. Stop there. open a "txt" file with "ms word".Not a ".doc", "docx", "odt". click file->save.
Read what it tells you. I rest the case.

There is nothing "advanced" in preserving the editing information of one's project.

Ok. Stop there. Now repeat the same steps substituting RTF for TXT.

Sure, RTF supports many of THE most commonly used text editing features (bold/italic/underline, tabs/indents/spacing, font face/size/color) but it doesn't support many advanced Word features (widow/orphan control, footnotes, column layouts, etc.) and if you are relying on a document that involves those features will Word inform you that your target file format is not sufficient for what you are trying to save? Or will it just silently assume your document doesn't care about those features and save what it can, effectively discarding those features when you close out your session?

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

On 01/02/2014 08:48 PM, Daniel Hauck wrote:

Yes and I'm pretty sure most people are getting what I'm driving at -- standards of function, design and behavior.

I never read more than one or two messages per 100 in "Save Vs. Export Blows Goats (I Have Proof)" threads, but if what you are driving at is standards of function, design and behavior, I'm all for that! As a quality assurance and production design geek, Standards is kind of my thing.

The GIMP has been the default "major" photo editor for the *NIX ecosystem for so long that some of its GUI components are widely used across numerous Linux distributions. The GIMP is a "standard setting" project and product. I think this might explain it better than I can, do give a listen:

http://www.youtube.com/watch?v=BpIQN8Cnea8

:o)

Steve

03 янв. 2014 г. 22:55 пользователь "Steve Kinney" написал:

On 01/02/2014 08:48 PM, Daniel Hauck wrote:

Yes and I'm pretty sure most people are getting what I'm driving at -- standards of function, design and behavior.

I never read more than one or two messages per 100 in "Save Vs. Export Blows Goats (I Have Proof)" threads, but if what you are driving at is standards of function, design and behavior, I'm all for that!

Are you all for that _what_?

Did you study how other software of this kind works? I'm specifically referring to apps that have a concept of layering data and/or mixing different kinds of data (bitmaps, vector shapes, video, sound, etc.).

GIMP falls under that category and foĺlows the convention that only project data should be saved, and delivery data should be exported. There are some exceptions, of course, but it doesn't mean that GIMP should follow those.

We have discussed this way too many times, and if you realy only read 2 mails out of each 100 in these threads, my suggestion would be to actually study the subject closer first, and going "all for that" later when you can really have an informed opinion.

Alexandre

Liam R E Quin writes:

Constructive suggestions about how to make a more coherent workflow in GIMP are welcomed. Whining about change is not so welcome.

Liam:

I will take you up on your offer to make a constructive GUI suggestion.

I fully understand the arguments for the workflow change that was made to GIMP 2.8. What I think was lost in the process was a recognition that there are two different primary workflows for two different groups of users. The new Save/Export distinction makes great sense for professionals working primarily in the xcf format. I do this a great deal myself and can embrace this workflow strategy.

What seems to be unjustifyably dismissed by the development team is that there is a very large segment of the user base that operates by a different workflow altogether. These people use/save in the xcf format rarely or never, but use GIMP to do wholesale editing of png/jpg photos with a completely different purpose in mind from the "pros". I myself also engage in this type of activity from time to time. The arguments about lossey jpg saves or unsaved worksteps in the editing process are typically understood by this group, but of little to no concern. And if switching from Ctrl-S to to Ctrl-E was the only change in behavior required, then I believe that there would be very few serious complaints. The real problem occurs in the exiting from the workflow after an export. The forced "save" query really slows down this particular workflow process. For this group of people, it is a repetitive bludgeoning by something that is absolutely unwanted. When attempting to work in this mode, I can attest that it is very annoying.

There is no right/wrong or better/worse workflow process -- only a preferred one for the type of work currently at hand. Why can't the development team recognize and acknowledge this instead of berating those who do not find the "pro" solution the best one for their needs?

My simple solution is to provide a workflow switch in the preferences that flips back and forth between the two workflow paradigms. Let GIMP default out of the box to the new "pro" mode, but allow users to select the alternate workflow model if they choose. I would include some sort of icon somewhere (status area?) that indicated visually that you were operating using the alternate workflow method. A shortcut key could allow users to quickly toggle back and forth between the two modes. Whether Ctrl-S/Ctrl-E were swapped in the process is a matter for discussion (I wouldn't care if they stayed as they currently are in 2.8) but suppressing the subsequent "save to xcf" check would be the really important improvement. In this alternate mode, the old behavior of recognizing the file extension should be preserved, allowing users to save to xcf format anytime they desired. However, if Save is reserved for xcf and Export is still required to "save" the current png/jpg file, then this extension parsing might not be required. In other words, I believe there is some variability in how this could be implemented that would still go a long way in addressing most users' concerns. Getting input from other users would be helpful here.

If something along these lines were done, the "pros" would never see any change to their use of GIMP, while countless users would recognize that the development team was actually listening and responding to their concerns instead of rejecting them out of hand.

In his blog post on "GIMP 2.8: understanding UI changes," Alexandre Prokoudine addresses the suggestion above:

---------- "Why Couldn't They Just Add A Checkbox?"

"Isn't it possible to just add a checkbox in the configuration dialog somewhere? It is."

OK, good.

"Would it be a good idea? No, it would be horrible. Let's have some reasoning again."

"1. In general, options complicate code and make it less manageable. Every option virtually increases amount of cases where application can fail. A snowball can soon become an avalanche."

Seriously? This is an argument against implementing a feature that is extremely useful to many users? Especially one a trivial as this? One that already has existed for years in the product? I think this snowball is just a snowball.

"2. Certain planned changes such as better native CMYK support presume that color separation is done a special mode for exporting. Maintaining a related behavior switch, when you have such a feature, would be hell."

Hell? Really? I've been developing software for 40 years. Is this a realistic statement or hyperbole? Again, we're talking about saving/exporting standard png/jpg files while bypassing the xcf save. Regardless of what is happening with CMYK, it is either saved/exported to these formats or it's not. How could this workflow introduce a massively complicating factor?

"3. Behavior options make documentation convoluted and lacking consistence."

We're not talking about opening the flood gate of change here. This is one simple workflow change that requires one simple update to the documentation.

"People still take offense at this change, and there is probably no cure for that other than repeating again and again: the team doesn't hate you, they just refocused on a group of users for whom this makes a lot of sense."

So far as I know, no one accused anyone of "hating" so that seems to me like just another straw-man argument. Yes, you are refocusing on a different type of user. But refocusing doesn't mean you have to totally ignore the existing user base. This is a very simple issue with a very simple resolution. There has been a huge amount of blowback over this. Honestly, I am at a loss to understand why there has been such a level of resistance for acquiescing, in some small way, on this point which is clearly so important to so many.

So there you have it, as calmly and as respectfully as I can frame it.

All the best, --
C. Jeffery Small

@ Prokoudine:

Dude, if you didn't act so full of yourself, so self-righteous and so haughty, half of these discussions wouldn't last half as long as they do. *You're
a troll feeding other trolls* and thus you too are stoking the fire of these inane, pointless, never-ending arguments, because we all know the #1 rule about trolls is DON'T FEED THE TROLL.

Signed: the helpful troll

P.D.: In this message, I don't say a single word about export behavior.

On Fri, Jan 3, 2014 at 9:52 PM, Richard wrote:

To: gimp-user-list@gnome.org
From: jernej|s-gmane@eternallybored.org Date: Fri, 3 Jan 2014 21:41:57 +0100 Subject: Re: [Gimp-user] gimp users matter

On Fri, 3 Jan 2014 10:16:07 -0800, Richard wrote:

Sure, RTF supports many of THE most commonly used text editing

features (bold/italic/underline, tabs/indents/spacing, font face/size/color) but it doesn't support many advanced Word features (widow/orphan control, footnotes, column layouts, etc.) and if you are relying on a document that involves those features will Word inform you that your target file format is not sufficient for what you are trying to save? Or will it just silently assume your document doesn't care about those features and save what it can, effectively discarding those features when you close out your session?

You're actually wrong - RTF supports at least everything that Word 2003 supports - including styles, paragraph settings, columns, footnotes etc. You will get a warning if you try to save as OpenDocument though (and at least in Word 2013, the document layout may change to reflect that).

*shrugs*

Okay, it has been awhile since I looked at the RTF official, beyond that I am only aware of what gets exposed through the editor. And I don't use RTF for anything complex so I've almost never actually bumped into its limitations.

-- Stratadrake
strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On Sat, Jan 4, 2014 at 2:14 AM, Jeffery Small wrote:

My simple solution is to provide a workflow switch in the preferences that flips back and forth between the two workflow paradigms.

Which has already been evaluated and denied.

In his blog post on "GIMP 2.8: understanding UI changes," Alexandre Prokoudine addresses the suggestion above:

Not a blog post, but that's just a minor remark.

"1. In general, options complicate code and make it less manageable. Every option virtually increases amount of cases where application can fail. A snowball can soon become an avalanche."

Seriously?

Yes, seriously.

"2. Certain planned changes such as better native CMYK support presume that color separation is done a special mode for exporting. Maintaining a related behavior switch, when you have such a feature, would be hell."

Hell? Really?

Yes, really.

I've been developing software for 40 years.

This is an absolutely meaningless statement. The cook in the kindergarden I went to when I was a kid couldn't cook a meal worth a damn, and she had been at this job for decades. This is really not the kind of argument one would use to prove credibility.

Is this a realistic statement or hyperbole?

It is a realistic statement.

Again, we're talking about
saving/exporting standard png/jpg files while bypassing the xcf save. Regardless of what is happening with CMYK, it is either saved/exported to these formats or it's not. How could this workflow introduce a massively complicating factor?

In the two or more years that we've been having this discussion noone has demonstrated the ability to

1) implement such a switch; 2) maintain a project containing such a switch; 3) ensure that noone is confused by the fact that different tutorials refer to different workflows of the same app.

In fact, people who patched GIMP to revert the change are still incapable of even maintaining their respective forks and keeping them up to date with all the bugfixes we've had since releasing 2.8.0. Case in point: https://github.com/mskala/noxcf-gimp.

To me this clearly indicates that nobody really wants to do introduce this kind of a switch. (Not that the team would accept it in the upstream project, mind you.) The amount of hot air regarding a possibility of such a switch, however, is truly incredible.

"3. Behavior options make documentation convoluted and lacking consistence."

We're not talking about opening the flood gate of change here. This is one simple workflow change that requires one simple update to the documentation.

And that's coming from someone who's been developing software for 40 years? Sorry, but in my eyes you've just lost all your credibility.

To sum it up, every change in UI opens the floodgate. In real life, people can stare at the slightly rephrased UI message and never realize it's what they need, then go to a forum and pester other people about "removed feature". This is the reality that people who actually communicate to users have to deal with.

"People still take offense at this change, and there is probably no cure for that other than repeating again and again: the team doesn't hate you, they just refocused on a group of users for whom this makes a lot of sense."

So far as I know, no one accused anyone of "hating"

Exactly: so far as _you_ know.

But refocusing doesn't mean you have to totally ignore the existing user base.

Nobody's being ignored, let alone totally ignored. For someone who claims to have attempted being respectful that was one hell of a nasty remark.

Alexandre

On 01/03/2014 03:10 PM, Alexandre Prokoudine wrote:

03 янв. 2014 г. 22:55 пользователь "Steve Kinney" написал:

On 01/02/2014 08:48 PM, Daniel Hauck wrote:

Yes and I'm pretty sure most people are getting what I'm driving at -- standards of function, design and behavior.

I never read more than one or two messages per 100 in "Save Vs. Export Blows Goats (I Have Proof)" threads, but if what you are driving at is standards of function, design and behavior, I'm all for that!

Are you all for that _what_?

I'm all for "standards of function, design and behavior."

Like for instance, when the GIMP saves a file, this file preserves the state of the project's work in progress; it is a project file, not an image file.

And for instance, when creating a file formatted for end use by any of numerous applications, that's "exporting the project" as a finished product, e.g. an image file.

A user has to do one [1] extra extra mouse click or keyboard shortcut to "discard" a project that has been exported without being saved. That's a reminder to save the work if it might be of any future use. As such it's a common and expected feature, seen across a range of software from word processors and desktop publishing packages to video editing suites. This feature imposes no hardship on any user and occasionally prevents lost work.

I don't normally feed trolls. But this week I am doing an experiment in counter-trolling, in several contexts. This will probably be my last post in a troll threads on gimp-user this year. Sometimes, one must misbehave.

:o)

Steve

On Sat, Jan 4, 2014 at 3:54 AM, Steve Kinney wrote:

I'm all for "standards of function, design and behavior."

Like for instance, when the GIMP saves a file, this file preserves the state of the project's work in progress; it is a project file, not an image file.

And for instance, when creating a file formatted for end use by any of numerous applications, that's "exporting the project" as a finished product, e.g. an image file.

A user has to do one [1] extra extra mouse click or keyboard shortcut to "discard" a project that has been exported without being saved. That's a reminder to save the work if it might be of any future use. As such it's a common and expected feature, seen across a range of software from word processors and desktop publishing packages to video editing suites. This feature imposes no hardship on any user and occasionally prevents lost work.

OK, so you got it right. Awesome :)

Alexandre

On Fri, 2014-01-03 at 22:14 +0000, Jeffery Small wrote:

Liam R E Quin writes:

[...]

I will take you up on your offer to make a constructive GUI suggestion.

I fully understand the arguments for the workflow change that was made to GIMP 2.8. What I think was lost in the process was a recognition that there are two different primary workflows for two different groups of users.

I think there are probably many different kinds of user in many different environments. The GIMP team chose to focus on one such group.

The file export spec isn't yet fully implemented, especially with respect to directories (folders).

The "unsaved changes" dialogue replaces an earlier dialogue, saving as jpeg can cause data loss" so there are no extra mouse clicks.

Technically, one of the difficulties with implementing an "old behaviour" checkbox may be the way that file saving is done through plugins, and the need to preserve ABI compatibility, but I'm not certain.

It's true, I think, that the GIMP developers have a history of getting more stubborn the more people complain :-) (that's why it's still called GIMP even though that's generally a rude or derogatory term in much of the English-speaking world).

But it's also true that they do this for fun, because they enjoy doing it.

Now, working from "given the distinction between save/export that is part of the GIMP (re)design, how do we make life a little easier for people who are using GIMP to modify a JPEG or PNG image in place" (something I do on a daily basis professionally by the way), I think there's mileage in such a conversation. But it's not about developers ignoring users, and that sort of framing almost guarantees a failed discussion. "I hate you, now give me what I want" works with cats because they are cute :-)

For my own part I *would* like to see GIMP take on the idea of a project, with per-project resources and settings, and the ability to have multiple projects active at the same time, each with its own window or windows. But I'd also like to see gimp 2.10 (or whatever) released, with more than 8-bit depth support.

The GIMP programmer team isn't very large, varying over the last few years between about 1.5 full-time-equivalent at its lowest up to maybe 4 or 5 for brief periods, and those people have varied from students (with or without shoes) to experienced GIMP developers wit not much time but willing to work on fixing a bug or some other thing that interests them or that they happened to need.

So GIMP can't be all things to all people.

Hope this helps a little.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

qelvin5500 (qelvin5500@gmail.com) wrote:

*Creating pictures* is a job, developing a software to create these picture is a different job.

Developing GIMP is a Hobby, not a Job.

Bye, Simon

simon@budig.de              http://simon.budig.de/

I also find GIMP's save-as behaviour very strange, but I have understood that there is no use in longer discussion about that. For the future I have two suggestions:

1) Allow for more user preferences. Why not leave the choice to me whether I would like to be warned when saving in a lossy format? The discussion has at least pointed out that workflows are a very personal matter. I have so far never saved any file in Gimp's native format.

2) Nowadays it is rather easy to organise a questionaire via the Internet. The developers could thus find out about users' expectations and preferences more easily then in former times. Well, I guess this approach also has its shortcomings, but one could try. Didn't the Open Office developers proceed this way lately?

Wolfgang Hugemann

I also find GIMP's save-as behaviour very strange, but I have understood that there is no use in longer discussion about that. For the future I have two suggestions:

1) Allow for more user preferences. Why not leave the choice to me whether I would like to be warned when saving in a lossy format? The discussion has at least pointed out that workflows are a very personal matter. I have so far never saved any file in Gimp's native format.

2) Nowadays it is rather easy to organise a questionaire via the Internet. The developers could thus find out about users' expectations and preferences more easily then in former times. Well, I guess this approach also has its shortcomings, but one could try. Didn't the Open Office developers proceed this way lately?

Wolfgang Hugemann

It does not matter what anyone else thinks. That part should be clear. It doesn't matter what people want. That much should be clear.

What matters is the perception of the perception of the program in question. (Yes, I said perception twice like that) Some people think a thing needs to be more proper (as defined by that person) and/or more professional (as defined by that person). The only thing that matters is the perception of that person. Nothing else and no one else matters.

Also, to change and backtrack now? After all this time of people begging and complaining? It would just be admitting someone is wrong and it would be unseemly now to back down in any way. Not after all this.

I think my favorite argument against user preference options is that "it's too hard and complicated." GiMP is already a masterpiece of complexity and effectiveness. Writing in an additional user preference is somehow too much though.

On 01/04/2014 08:32 AM, Wolfgang Hugemann wrote:

I also find GIMP's save-as behaviour very strange, but I have understood that there is no use in longer discussion about that. For the future I have two suggestions:

1) Allow for more user preferences. Why not leave the choice to me whether I would like to be warned when saving in a lossy format? The discussion has at least pointed out that workflows are a very personal matter. I have so far never saved any file in Gimp's native format.

2) Nowadays it is rather easy to organise a questionaire via the Internet.
The developers could thus find out about users' expectations and preferences more easily then in former times. Well, I guess this approach also has its shortcomings, but one could try. Didn't the Open Office developers proceed this way lately?

Wolfgang Hugemann _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On Fri, Jan 3, 2014, at 11:49 AM, qelvin5500 wrote:

On 01/03/2014 01:51 PM, akovia wrote:

On 01/03/2014 05:21 AM, Liam R E Quin wrote:

It's lucky that GIMP now works like so many other programs - inkscape,

You're wrong: gimp editor works differently. All editors, free or not free, save work in a normal way, except gimp. This misinformation is getting boring.

I really do admire the passion people have for this cause,

Yes, me too. It means these people love Gimp and want improve it

but the

amount of time spent arguing their case on the mailing list could have been put to developing their own fork to make gimp work the way they like.

*Creating pictures* is a job, developing a software to create these picture is a different job.
That's why users feedback is very important. --
Q

I guess I need to spell out the obvious here. I didn't think that anyone arguing the case to bring back this feature was a programmer, but the time spent here could have been spent requiting for the "cause".
ie...putting your energy into something that has a chance of succeeding instead of beating this poor dead horse any longer.

akovia

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free

To: gimp-user-list@gnome.org
From: jeff@cjsa.com
Date: Fri, 3 Jan 2014 22:14:29 +0000 Subject: Re: [Gimp-user] gimp users matter

Liam R E Quin writes:

Whether Ctrl-S/Ctrl-E were swapped in the process is a matter for discussion (I wouldn't care if they stayed as they currently are in 2.8) but suppressing the subsequent "save to xcf" check would be the really important improvement.

I know I've mentioned it before but an option to suppress this warning for images that are (1) unchanged since last export and (2) never saved to an XCF file could be useful for the export/overwrite-based workflows because as it stands you can't make a final export when you close the image - you can only save as XCF or discard everything.

Alternatively, if the closing "Save Changes?" box was changed to have both "Save" and "Export" commands this could also work.

Oh, and with 2.8.10's behavior change on what happens when you hit the Close button in SWM, it's also worth mentioning that you DON'T get an option to save your changes at all - you get a warning that unsaved changes will be lost, but you have no access to the Save command from that dialog. Even if you only have one image open.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

On Sat, 2014-01-04 at 09:26 -0800, Richard wrote:

To: gimp-user-list@gnome.org
From: jeff@cjsa.com
Date: Fri, 3 Jan 2014 22:14:29 +0000 Subject: Re: [Gimp-user] gimp users matter

Liam R E Quin writes:

Whether Ctrl-S/Ctrl-E were swapped in the process is a matter for discussion (I wouldn't care if they stayed as they currently are in 2.8) but suppressing the subsequent "save to xcf" check would be the really important improvement.

I didn't write that, Richard. Please be careful when quoting. It isn't right either - ^S and ^E were not "swapped" and I don't want the "save to xcf" check removed, although I _would_ like it to be smarter. That's partly a matter of writing a patch.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Hi Everyone

does anyone have any experience with corrupted JPG's

i have tried various programs, and none seem to work?

cheers Phil

Usually I just take em out to the bar and ply them with liquor.

Thanks folks, I'm here all week!

On 1/4/2014 12:46 PM, Phil wrote:

Hi Everyone

does anyone have any experience with corrupted JPG's

i have tried various programs, and none seem to work?

cheers Phil
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Cheers John,

not exactly what i was looking for, but thanks for the input,

Phil

On 04/01/2014 19:48, John Meyer wrote:

Usually I just take em out to the bar and ply them with liquor.

Thanks folks, I'm here all week!

On 1/4/2014 12:46 PM, Phil wrote:

Hi Everyone

does anyone have any experience with corrupted JPG's

i have tried various programs, and none seem to work?

cheers Phil
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On 01/04/2014 04:17 AM, Simon Budig wrote:

qelvin5500 (qelvin5500@gmail.com) wrote:

*Creating pictures* is a job, developing a software to create these picture is a different job.

Developing GIMP is a Hobby, not a Job.

Bye, Simon

Whether a job or a hobby, prioritizing effectively is probably *MOST* important.

In this regard, voluminous postings that are distracting and *UNNECESSARY* is *ALWAYS* counterproductive.

Any posting that starts "I understand that the developers are ---" is counterproductive.

The notion that the marvelously effective GIMP developers were unaware of the discomfort this UI change would produce was gainsaid in earlier postings in this and related threads; I would encourage all those who are fans of GIMP and would like to have the ever-changing developer group get on with their priorities: please back off and let them be. I *WANT* CMYK; I *WANT* high-bit-depth; I *WANT* more robust undo history; I *WANT* more intuitive UI; I *WANT* a smoother work flow; I *WANT* - - -

I will not mention what my priorities are, but I can understand that the large community of users is likely to have a large number of subgroups each of which would agree on a profoundly different set of priorities than many of the other subgroups.

I am reminded of a comedian's remark some decades ago: "I wish those people who can't communicate would SHUT UP ABOUT IT."

-- Burnie

PS - I apologize for distracting any members of the worldwide GIMP community who dislike being bothered by threads like these - please forgive.

You know, when you put it that way, I have to concede your point. There are some things in future-GiMP which are more important than a UI change. (Though I dare say few as trivial as the UI change under discussion.)

But we, the users, aren't asking for something new. We're asking for something that was there but is no longer.

On 01/04/2014 02:54 PM, Burnie West wrote:

On 01/04/2014 04:17 AM, Simon Budig wrote:

qelvin5500 (qelvin5500@gmail.com) wrote:

*Creating pictures* is a job, developing a software to create these picture is a different job.

Developing GIMP is a Hobby, not a Job.

Bye, Simon

Whether a job or a hobby, prioritizing effectively is probably *MOST* important.

In this regard, voluminous postings that are distracting and *UNNECESSARY* is *ALWAYS* counterproductive.

Any posting that starts "I understand that the developers are ---" is counterproductive.

The notion that the marvelously effective GIMP developers were unaware of the discomfort this UI change would produce was gainsaid in earlier postings in this and related threads; I would encourage all those who are fans of GIMP and would like to have the ever-changing developer group get on with their priorities: please back off and let them be. I *WANT* CMYK; I *WANT* high-bit-depth; I *WANT* more robust undo history; I *WANT* more intuitive UI; I *WANT* a smoother work flow; I *WANT* - - -

I will not mention what my priorities are, but I can understand that the large community of users is likely to have a large number of subgroups each of which would agree on a profoundly different set of priorities than many of the other subgroups.

I am reminded of a comedian's remark some decades ago: "I wish those people who can't communicate would SHUT UP ABOUT IT."

-- Burnie

PS - I apologize for distracting any members of the worldwide GIMP community who dislike being bothered by threads like these - please forgive.
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On 01/04/2014 02:46 PM, Phil wrote:

Hi Everyone

does anyone have any experience with corrupted JPG's

i have tried various programs, and none seem to work?

cheers Phil

Phil, I've encountered jpegs that couldn't be opened until I removed all the metadata. Try making a copy of the jpeg (if the metadata is important to you). The use imagemagick "mogrify -strip name-of-file.jpg" to remove the metadata and see if your image editor can open it.

Sorry i should have been more specific.. (and i know its not Gimp specific, just a fellow photographer looking to help a friend)

I have some pictures taken on an Sony DSC-W510 digital camera, and they are/have become corrupted? the thumbnail shows up, in windows(win7) & osx(10.6), debian 7.2 must be different as it shows the corruption up in thumbnail preview, but when viewing the full picture, it only shows up a corrupted view and this seems to be about 5 to 10 percent of the image coming down.

The Exif data seems to be all present (all 3 os's), and the programs that i have tried, inc gimp/picasa/CS6 photoshop/serif photoplus, all have a corrupted image.

I have tried stella recovery, jpeg doctor, hetman photo, jpegrec, jpeg-repair (im sure there was more)... and was just looking for somone who might have some knownlege.

i have even downloaded an Hex editor, and well, started to look through the information, but it looks like a large amount of information to go through..

Ill try your suggestion Elle, just seen your email come through, i have debian powered up at the moment, so ill give it ago :)

cheers

Phil

On 04/01/2014 19:54, Burnie West wrote:

On 01/04/2014 04:17 AM, Simon Budig wrote:

qelvin5500 (qelvin5500@gmail.com) wrote:

*Creating pictures* is a job, developing a software to create these picture is a different job.

Developing GIMP is a Hobby, not a Job.

Bye, Simon

Whether a job or a hobby, prioritizing effectively is probably *MOST* important.

In this regard, voluminous postings that are distracting and *UNNECESSARY* is *ALWAYS* counterproductive.

Any posting that starts "I understand that the developers are ---" is counterproductive.

The notion that the marvelously effective GIMP developers were unaware of the discomfort this UI change would produce was gainsaid in earlier postings in this and related threads; I would encourage all those who are fans of GIMP and would like to have the ever-changing developer group get on with their priorities: please back off and let them be. I *WANT* CMYK; I *WANT* high-bit-depth; I *WANT* more robust undo history; I *WANT* more intuitive UI; I *WANT* a smoother work flow; I *WANT* - - -

I will not mention what my priorities are, but I can understand that the large community of users is likely to have a large number of subgroups each of which would agree on a profoundly different set of priorities than many of the other subgroups.

I am reminded of a comedian's remark some decades ago: "I wish those people who can't communicate would SHUT UP ABOUT IT."

-- Burnie

PS - I apologize for distracting any members of the worldwide GIMP community who dislike being bothered by threads like these - please forgive.
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On 01/04/2014 03:09 PM, Phil wrote:

I have some pictures taken on an Sony DSC-W510 digital camera, and they are/have become corrupted? the thumbnail shows up, in windows(win7) & osx(10.6), debian 7.2 must be different as it shows the corruption up in thumbnail preview, but when viewing the full picture, it only shows up a corrupted view and this seems to be about 5 to 10 percent of the image coming down.

That's not a good sign! Is it possible that the camera card to which the files were saved has some issues?

Or perhaps the files were corrupted during the save process even though the camera card is good? I've had this happen once or twice, but not to a whole bunch of images.

While you are at the command line, try converting the image to another file format: "convert image.jpg image.png" If that doesn't produce a readable image, probably the image really is corrupted.

Often the embedded thumb(s) is/are quite large and better than nothing. If the whole file can't be retrieved, if you want I can dig up the exiftool command for extracting the thumb.

Elle

Appears you've accidentally hijacked a dispute thread - - -

On 01/04/2014 12:31 PM, Elle Stone wrote:

On 01/04/2014 03:09 PM, Phil wrote:

I have some pictures taken on an Sony DSC-W510 digital camera, and they are/have become corrupted? the thumbnail shows up, in windows(win7) & osx(10.6), debian 7.2 must be different as it shows the corruption up in thumbnail preview, but when viewing the full picture, it only shows up a corrupted view and this seems to be about 5 to 10 percent of the image coming down.

That's not a good sign! Is it possible that the camera card to which the files were saved has some issues?

Or perhaps the files were corrupted during the save process even though the camera card is good? I've had this happen once or twice, but not to a whole bunch of images.

While you are at the command line, try converting the image to another file format: "convert image.jpg image.png" If that doesn't produce a readable image, probably the image really is corrupted.

Often the embedded thumb(s) is/are quite large and better than nothing. If the whole file can't be retrieved, if you want I can dig up the exiftool command for extracting the thumb.

Elle

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Hi All

Apologies to all for not starting a new thread, i have been an avid reader of the emails for a while now, and read most of what people put here, so sorry Michael & Jay who pointed that out to me..

ill try and answer all questions about whats what etc.

I believe the original pictures, that were taken in 2011, were taken directly of the camera via USB cable, these were then stored on my friends computer, and these were corrupted. I didnt notice it much at first, as she asked me to look at something different (spamware), but her screen saver, which must have read the pic folder, showed pictures, that looked to be corrupted, i initially thought that these were to big for the screen saver to handle, and dismissed them.

She still had the memory card, and the thumbnails, still showed fine on camera preview screen, so she thought they were safe. But luckly, she is not an avid photographer, and didnt even wipe the card! After that, i Borrowed the card, and used photorescue (it saved me once so i was more than happy to pay for it after my canon 350d corrupted a card that was not quick enough), and it again found the same pictures corrupted.

So then began my quest for finding information/utilities to undo/correct the files.

The Card reader is my own, that i ran the software recovery on, so with the fact that since she has bought a new memory card, and it worked fine, i assume its a faulty card? so i took a copy of what she had.

DSC0001.jpg seems to be fine, this is the first card picture on the card, i dont know if any were taken before, ie new card or new camera, but i could find out if needed. DSC0002.jpg, that is ooo 75% ok, but after that, all the remaining 221 pictures are damaged, all only showing about 5%.

I ran imagemagick "mogrify -strip name-of-file.jpg", that ella suggested, and it gave me a comment unsupported marker type 0x3a 'dsc0002.jpg' @warning/jpeg.c/jpegerrorhandler/313.

I did try loading into Gimp 2.8.2 on debian 7.2 after the imagemagick command, and it also said this message (i thought i had tried it on linux but obviously not), OSX 10.6 running gimp 2.8.3 didnt give the same error message, and im sure windows 7 running gimp 2.8.6 (from memory) also didnt give the handler error.

From what little research that i have done since, the error is quite a complicated one. Something to do with data strips ending in FF D9 in a hex editor. The 0001 file has 3 of these, the other 2 that i have tried only have 1 reference (from searching the file).

Ella's other suggestion for converting from jpg to png, i entered "convert DSC0002.jpg test.png" and it converted the image, with the corruption, with no error's reported, also tried dsc0001 and it converted fine (but the original image was ok).

Im assuming meta data is not transfered to a PNG, ill be honest, i dont know much about them, as most of my work is saved back out as JPEG's etc, apart from when exporting from inkscape, which prefers PNG's/Tiffs etc.

Cheers All

Phil

On 04/01/2014 20:06, Elle Stone wrote:

On 01/04/2014 02:46 PM, Phil wrote:

Hi Everyone

does anyone have any experience with corrupted JPG's

i have tried various programs, and none seem to work?

cheers Phil

Phil, I've encountered jpegs that couldn't be opened until I removed all the metadata. Try making a copy of the jpeg (if the metadata is important to you). The use imagemagick "mogrify -strip name-of-file.jpg" to remove the metadata and see if your image editor can open it.

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On 01/04/2014 04:27 PM, Phil wrote:

Hi All

Apologies to all for not starting a new thread, i have been an avid reader of the emails for a while now, and read most of what people put here, so sorry Michael & Jay who pointed that out to me..

ill try and answer all questions about whats what etc.

I believe the original pictures, that were taken in 2011, were taken directly of the camera via USB cable, these were then stored on my friends computer, and these were corrupted. I didnt notice it much at first, as she asked me to look at something different (spamware), but her screen saver, which must have read the pic folder, showed pictures, that looked to be corrupted, i initially thought that these were to big for the screen saver to handle, and dismissed them.

She still had the memory card, and the thumbnails, still showed fine on camera preview screen, so she thought they were safe. But luckly, she is not an avid photographer, and didnt even wipe the card! After that, i Borrowed the card, and used photorescue (it saved me once so i was more than happy to pay for it after my canon 350d corrupted a card that was not quick enough), and it again found the same pictures corrupted.

So then began my quest for finding information/utilities to undo/correct the files.

The Card reader is my own, that i ran the software recovery on, so with the fact that since she has bought a new memory card, and it worked fine, i assume its a faulty card? so i took a copy of what she had.

DSC0001.jpg seems to be fine, this is the first card picture on the card, i dont know if any were taken before, ie new card or new camera, but i could find out if needed. DSC0002.jpg, that is ooo 75% ok, but after that, all the remaining 221 pictures are damaged, all only showing about 5%.

I ran imagemagick "mogrify -strip name-of-file.jpg", that ella suggested, and it gave me a comment unsupported marker type 0x3a 'dsc0002.jpg' @warning/jpeg.c/jpegerrorhandler/313.

I did try loading into Gimp 2.8.2 on debian 7.2 after the imagemagick command, and it also said this message (i thought i had tried it on linux but obviously not), OSX 10.6 running gimp 2.8.3 didnt give the same error message, and im sure windows 7 running gimp 2.8.6 (from memory) also didnt give the handler error.

From what little research that i have done since, the error is quite a complicated one. Something to do with data strips ending in FF D9 in a hex editor. The 0001 file has 3 of these, the other 2 that i have tried only have 1 reference (from searching the file).

Ella's other suggestion for converting from jpg to png, i entered "convert DSC0002.jpg test.png" and it converted the image, with the corruption, with no error's reported, also tried dsc0001 and it converted fine (but the original image was ok).

Im assuming meta data is not transfered to a PNG, ill be honest, i dont know much about them, as most of my work is saved back out as JPEG's etc, apart from when exporting from inkscape, which prefers PNG's/Tiffs etc.

Hmm, well, it does sound like file damage rather than just a case of messed up metadata or a version of jpeg that imagemagick can read and other image editors can't. Perhaps someone else can help. I don't know anything at all about recovering damaged image files.

If the thumbs are intact, this page: http://ninedegreesbelow.com/photography/exiftool-commands.html#extract tells how to use exiftool to extract the thumbnail as a separate image file. As always, work on a copy of the original.

Good luck!

Elle

Can you post an example of your corrupted jpeg file?

On Sat, Jan 4, 2014 at 4:53 PM, Elle Stone wrote:

On 01/04/2014 04:27 PM, Phil wrote:

Hi All

Apologies to all for not starting a new thread, i have been an avid reader of the emails for a while now, and read most of what people put here, so sorry Michael & Jay who pointed that out to me..

ill try and answer all questions about whats what etc.

I believe the original pictures, that were taken in 2011, were taken directly of the camera via USB cable, these were then stored on my friends computer, and these were corrupted. I didnt notice it much at first, as she asked me to look at something different (spamware), but her screen saver, which must have read the pic folder, showed pictures, that looked to be corrupted, i initially thought that these were to big for the screen saver to handle, and dismissed them.

She still had the memory card, and the thumbnails, still showed fine on camera preview screen, so she thought they were safe. But luckly, she is not an avid photographer, and didnt even wipe the card! After that, i Borrowed the card, and used photorescue (it saved me once so i was more than happy to pay for it after my canon 350d corrupted a card that was not quick enough), and it again found the same pictures corrupted.

So then began my quest for finding information/utilities to undo/correct the files.

The Card reader is my own, that i ran the software recovery on, so with the fact that since she has bought a new memory card, and it worked fine, i assume its a faulty card? so i took a copy of what she had.

DSC0001.jpg seems to be fine, this is the first card picture on the card, i dont know if any were taken before, ie new card or new camera, but i could find out if needed. DSC0002.jpg, that is ooo 75% ok, but after that, all the remaining 221 pictures are damaged, all only showing about 5%.

I ran imagemagick "mogrify -strip name-of-file.jpg", that ella suggested, and it gave me a comment unsupported marker type 0x3a 'dsc0002.jpg' @warning/jpeg.c/jpegerrorhandler/313.

I did try loading into Gimp 2.8.2 on debian 7.2 after the imagemagick command, and it also said this message (i thought i had tried it on linux but obviously not), OSX 10.6 running gimp 2.8.3 didnt give the same error message, and im sure windows 7 running gimp 2.8.6 (from memory) also didnt give the handler error.

From what little research that i have done since, the error is quite a complicated one. Something to do with data strips ending in FF D9 in a hex editor. The 0001 file has 3 of these, the other 2 that i have tried only have 1 reference (from searching the file).

Ella's other suggestion for converting from jpg to png, i entered "convert DSC0002.jpg test.png" and it converted the image, with the corruption, with no error's reported, also tried dsc0001 and it converted fine (but the original image was ok).

Im assuming meta data is not transfered to a PNG, ill be honest, i dont know much about them, as most of my work is saved back out as JPEG's etc, apart from when exporting from inkscape, which prefers PNG's/Tiffs etc.

Hmm, well, it does sound like file damage rather than just a case of messed up metadata or a version of jpeg that imagemagick can read and other image editors can't. Perhaps someone else can help. I don't know anything at all about recovering damaged image files.

If the thumbs are intact, this page: http://ninedegreesbelow.com/photography/exiftool-commands.html#extract tells how to use exiftool to extract the thumbnail as a separate image file. As always, work on a copy of the original.

Good luck!

Elle _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Hi Partha/all

Ive uploaded/shared 4 pics to dropbox...

0001 is ok 0002 is 75% is ok
0003 is 5% ish ok
0007 is just another 5% ok file

looking though the thumbnails more closely, even some of them seem to have corruption, ie pink lines though them, that look to be old ascii symbols, but cant see that clearly, as they thumbs.

Ill try the Exif extraction tool in a bit, just to try and get something at least out of the pictures.

https://www.dropbox.com/sh/dp0nsvn1jn9sons/E6Erp9vJP-

Cheers Phil

On 05/01/2014 00:09, Partha Bagchi wrote:

Can you post an example of your corrupted jpeg file?

On Sat, Jan 4, 2014 at 4:53 PM, Elle Stone wrote:

On 01/04/2014 04:27 PM, Phil wrote:

Hi All

Apologies to all for not starting a new thread, i have been an avid reader of the emails for a while now, and read most of what people put here, so sorry Michael & Jay who pointed that out to me..

ill try and answer all questions about whats what etc.

I believe the original pictures, that were taken in 2011, were taken directly of the camera via USB cable, these were then stored on my friends computer, and these were corrupted. I didnt notice it much at first, as she asked me to look at something different (spamware), but her screen saver, which must have read the pic folder, showed pictures, that looked to be corrupted, i initially thought that these were to big for the screen saver to handle, and dismissed them.

She still had the memory card, and the thumbnails, still showed fine on camera preview screen, so she thought they were safe. But luckly, she is not an avid photographer, and didnt even wipe the card! After that, i Borrowed the card, and used photorescue (it saved me once so i was more than happy to pay for it after my canon 350d corrupted a card that was not quick enough), and it again found the same pictures corrupted.

So then began my quest for finding information/utilities to undo/correct the files.

The Card reader is my own, that i ran the software recovery on, so with the fact that since she has bought a new memory card, and it worked fine, i assume its a faulty card? so i took a copy of what she had.

DSC0001.jpg seems to be fine, this is the first card picture on the card, i dont know if any were taken before, ie new card or new camera, but i could find out if needed. DSC0002.jpg, that is ooo 75% ok, but after that, all the remaining 221 pictures are damaged, all only showing about 5%.

I ran imagemagick "mogrify -strip name-of-file.jpg", that ella suggested, and it gave me a comment unsupported marker type 0x3a 'dsc0002.jpg' @warning/jpeg.c/jpegerrorhandler/313.

I did try loading into Gimp 2.8.2 on debian 7.2 after the imagemagick command, and it also said this message (i thought i had tried it on linux but obviously not), OSX 10.6 running gimp 2.8.3 didnt give the same error message, and im sure windows 7 running gimp 2.8.6 (from memory) also didnt give the handler error.

From what little research that i have done since, the error is quite a complicated one. Something to do with data strips ending in FF D9 in a hex editor. The 0001 file has 3 of these, the other 2 that i have tried only have 1 reference (from searching the file).

Ella's other suggestion for converting from jpg to png, i entered "convert DSC0002.jpg test.png" and it converted the image, with the corruption, with no error's reported, also tried dsc0001 and it converted fine (but the original image was ok).

Im assuming meta data is not transfered to a PNG, ill be honest, i dont know much about them, as most of my work is saved back out as JPEG's etc, apart from when exporting from inkscape, which prefers PNG's/Tiffs etc.

Hmm, well, it does sound like file damage rather than just a case of messed up metadata or a version of jpeg that imagemagick can read and other image editors can't. Perhaps someone else can help. I don't know anything at all about recovering damaged image files.

If the thumbs are intact, this page: http://ninedegreesbelow.com/photography/exiftool-commands.html#extract tells how to use exiftool to extract the thumbnail as a separate image file. As always, work on a copy of the original.

Good luck!

Elle _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On Fri, 03 Jan 2014 11:07:55 -0700 John Meyer wrote:

Infrequent user of GIMP, but I'll ask: is there no way to map the control keys differently?

Yes you can reassign the control keys. But that doesn't completely solve the inconvenience. Ypu still have to confirm losing info on exiting GIMP. There is also a plugin (from Akasha?) which is slightly better than reassigning, but introduced another problem (I seem to recall).

John

Am 04.01.2014 14:40, schrieb Daniel Hauck:

I think my favorite argument against user preference options is that "it's too hard and complicated." GiMP is already a masterpiece of complexity and effectiveness. Writing in an additional user preference is somehow too much though.

Perhaps it would suffice to turn special warning messages permanently off, something like a checkbox in the warning dialog: "Don't show this message again." This is rather common in modern programs and would make live somewhat easier. I already re-defined CTRL-S to export, but still I have to click the warning message each time when I close an image.

Wolfgang Hugemann

Phil,

I doubt that you can do much with these images other than extract the thumbnail which is obviously quite small.

I used jpeg snoop (http://www.impulseadventure.com/photo/jpeg-snoop.html) to examine file number 4 and there are markers in the file that should not be there. Perhaps you can use a hex editor to fix it, I have no idea.

Sorry, Partha

On Sat, Jan 4, 2014 at 7:23 PM, Phil wrote:

Hi Partha/all

Ive uploaded/shared 4 pics to dropbox...

0001 is ok 0002 is 75% is ok
0003 is 5% ish ok
0007 is just another 5% ok file

looking though the thumbnails more closely, even some of them seem to have corruption, ie pink lines though them, that look to be old ascii symbols, but cant see that clearly, as they thumbs.

Ill try the Exif extraction tool in a bit, just to try and get something at least out of the pictures.

https://www.dropbox.com/sh/dp0nsvn1jn9sons/E6Erp9vJP-

Cheers Phil

On 05/01/2014 00:09, Partha Bagchi wrote:

Can you post an example of your corrupted jpeg file?

On Sat, Jan 4, 2014 at 4:53 PM, Elle Stone wrote:

On 01/04/2014 04:27 PM, Phil wrote:

Hi All

Apologies to all for not starting a new thread, i have been an avid reader of the emails for a while now, and read most of what people put here, so sorry Michael & Jay who pointed that out to me..

ill try and answer all questions about whats what etc.

I believe the original pictures, that were taken in 2011, were taken directly of the camera via USB cable, these were then stored on my friends computer, and these were corrupted. I didnt notice it much at first, as she asked me to look at something different (spamware), but her screen saver, which must have read the pic folder, showed pictures, that looked to be corrupted, i initially thought that these were to big for the screen saver to handle, and dismissed them.

She still had the memory card, and the thumbnails, still showed fine on camera preview screen, so she thought they were safe. But luckly, she is not an avid photographer, and didnt even wipe the card! After that, i Borrowed the card, and used photorescue (it saved me once so i was more than happy to pay for it after my canon 350d corrupted a card that was not quick enough), and it again found the same pictures corrupted.

So then began my quest for finding information/utilities to undo/correct the files.

The Card reader is my own, that i ran the software recovery on, so with the fact that since she has bought a new memory card, and it worked fine, i assume its a faulty card? so i took a copy of what she had.

DSC0001.jpg seems to be fine, this is the first card picture on the card, i dont know if any were taken before, ie new card or new camera, but i could find out if needed. DSC0002.jpg, that is ooo 75% ok, but after that, all the remaining 221 pictures are damaged, all only showing about 5%.

I ran imagemagick "mogrify -strip name-of-file.jpg", that ella suggested, and it gave me a comment unsupported marker type 0x3a 'dsc0002.jpg' @warning/jpeg.c/jpegerrorhandler/313.

I did try loading into Gimp 2.8.2 on debian 7.2 after the imagemagick command, and it also said this message (i thought i had tried it on linux but obviously not), OSX 10.6 running gimp 2.8.3 didnt give the same error message, and im sure windows 7 running gimp 2.8.6 (from memory) also didnt give the handler error.

From what little research that i have done since, the error is quite a complicated one. Something to do with data strips ending in FF D9 in a hex editor. The 0001 file has 3 of these, the other 2 that i have tried only have 1 reference (from searching the file).

Ella's other suggestion for converting from jpg to png, i entered "convert DSC0002.jpg test.png" and it converted the image, with the corruption, with no error's reported, also tried dsc0001 and it converted fine (but the original image was ok).

Im assuming meta data is not transfered to a PNG, ill be honest, i dont know much about them, as most of my work is saved back out as JPEG's etc, apart from when exporting from inkscape, which prefers PNG's/Tiffs etc.

Hmm, well, it does sound like file damage rather than just a case of

messed up metadata or a version of jpeg that imagemagick can read and other
image editors can't. Perhaps someone else can help. I don't know anything at all about recovering damaged image files.

If the thumbs are intact, this page: http://ninedegreesbelow.com/photography/exiftool-commands.html#extract tells how to use exiftool to extract the thumbnail as a separate image file. As always, work on a copy of the original.

Good luck!

Elle _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

_______________________________________________

gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On Mon, 06 Jan 2014 20:13:00 +0100 Wolfgang Hugemann wrote:

Perhaps it would suffice to turn special warning messages permanently off, something like a checkbox in the warning dialog: "Don't show this message again." This is rather common in modern programs and would make live somewhat easier. I already re-defined CTRL-S to export, but still I have to click the warning message each time when I close an image.

Hi Wolfgang,

http://www.shallowsky.com/software/gimp-save/

This plugin provides a new 'file command' for the GIMP, which exports, and also marks the file as clean, so the confirmation does not appear anymore.

It was posted by Akkana on this list a long time ago.

John

On Mon, 2014-01-06 at 17:53 -0500, Partha Bagchi wrote:

I used jpeg snoop (http://www.impulseadventure.com/photo/jpeg-snoop.html) to examine file number 4 and there are markers in the file that should not be there. Perhaps you can use a hex editor to fix it, I have no idea.

Possibly a corrupt memory card, e.g. camera lost power while writing to it, or it's been near strong magnets!

On Linux you could try a file system repair program, or there are third party repair programs for Windows. I would not hold out much hope I'm afraid.

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On 01/07/2014 09:45 AM, John Coppens wrote:

http://www.shallowsky.com/software/gimp-save/

This plugin provides a new 'file command' for the GIMP, which exports, and also marks the file as clean, so the confirmation does not appear anymore.

It was posted by Akkana on this list a long time ago.

John

Ta freakin' daa. I don't even know if gimp-user has a FAQ but if it dones not, it needs one, and this should be item one.

Then folks can say, "Oh, that's not a problem or issue. Go read the FAQ."

;o)

Steve

Aww, then what would we have to argue about? ;-)

On 1/7/2014 3:46 PM, Steve Kinney wrote:

On 01/07/2014 09:45 AM, John Coppens wrote:

http://www.shallowsky.com/software/gimp-save/

This plugin provides a new 'file command' for the GIMP, which exports, and also marks the file as clean, so the confirmation does not appear anymore.

It was posted by Akkana on this list a long time ago.

John

Ta freakin' daa. I don't even know if gimp-user has a FAQ but if it dones not, it needs one, and this should be item one.

Then folks can say, "Oh, that's not a problem or issue. Go read the FAQ."

;o)

Steve

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On 01/07/2014 05:47 PM, John Meyer wrote:

Aww, then what would we have to argue about? ;-)

There will always be users who think the GIMP is "too complicated" or just "too hard." And trolls gonna troll no matter what.

Some few people think those mean old "big shots" who help maintain the GIMP and its associated community are a gang of elitists who don't care what users want, need or think. The fact that trolls are given more or less free rein here on gimp-user tends to prove the opposite: The "big shots" in the GIMP ecosystem would rather let morons rant, than err on the side of censorship and maybe, just possibly, accidentally prevent some "useful" discussion or information from making the rounds.

That's more patience and forbearance than I would have, and I'm a Quaker.

:o)

Steve

Steve Kinney (admin@pilobilus.net) wrote:

The "big shots" in the GIMP ecosystem would rather let morons rant, than err on the side of censorship and maybe, just possibly, accidentally prevent some "useful" discussion or information from making the rounds.

Thanks for viewing us in that way.

However, I think it must be said that we actually *do* silence some people on this list by unsubscribing and/or blocking them. This usually happens based on a save/export discussion where people keep repeating the same false statements, insults and bogus "facts". We indeed try to not be too quick with the trigger, but some people just seem to ask for it. Sometimes apparently even multiple times with different mail addresses...

Bye,
Simon

simon@budig.de              http://simon.budig.de/

On 08.01.2014 00:43, Simon Budig wrote:

We indeed try to not be too quick with the trigger, but some people just seem to ask for it.

Some people have asked us to be a bit^wlot quicker, though. Mostly because they use this mailing list as a useful resource for GIMP usage questions and hints and want it to be kept this way.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

On 01/07/2014 07:49 PM, Michael Schumacher wrote:

On 08.01.2014 00:43, Simon Budig wrote:

We indeed try to not be too quick with the trigger, but some people just seem to ask for it.

Some people have asked us to be a bit^wlot quicker, though. Mostly because they use this mailing list as a useful resource for GIMP usage questions and hints and want it to be kept this way.

Ah-yup. But as long as the nonsense can pass for idiocy, it passes. On the whole I appreciate this - nobody makes me read the threads in question, thank God.

:o)

Hi Alexandre and everybody else

In the two or more years that we've been having this discussion noone has demonstrated the ability to

as you might know, I'm providing GIMP builds for Mac OS X for the last few years on http://gimp.lisanet.de

Just as a proof of concept I've patched all of my current builds (since 2.8.6) and provided such a switch.

1) implement such a switch;

I did.

2) maintain a project containing such a switch;

I maintain it since 2.8.6, up to now and will do it as long as I offer packages for Mac OS X. (just FYI, I'm providing packags since 2008)

3) ensure that noone is confused by the fact that different tutorials refer to different workflows of the same app.

I can't ensure this, but nevertheless until now, I didn't get any complaints. In contrary, I get lots of mails thanking me for such a switch.

In fact, people who patched GIMP to revert the change are still incapable of even maintaining their respective forks and keeping them

No. In fact, I did never complain about it. I patched GIMP an implemented such a switch.

And no, I' not incapable of maintaining. I do it since then.

up to date with all the bugfixes we've had since releasing 2.8.0. Case in point: https://github.com/mskala/noxcf-gimp.

see http://gimp.lisanet.de

And that's coming from someone who's been developing software for 40 years? Sorry, but in my eyes you've just lost all your credibility.

hhhmm, well, IMO he did _not_ loose his credibility because I did implement such a feature and maintain it since then.

Please Alexandre, don't get me wrong. I don't want to offend you, I only want to show, even if my patch might not cover every aspect and every wish of every user, that it's not too complicated to implement such a feature. It can be done quite easily and IMO it's only a matter if one wants to code it or not not code it.

Finally, I hope I don't get banned from the webpage, because of this right-out-of-hell-patch I did, and that I still can contribute code and patches to GIMP.

Simone Karin

09 . 2014 . 19:15 "lisanet" :

Just as a proof of concept I've patched all of my current builds (since

2.8.6)

and provided such a switch.

I was not aware of that, thanks for telling.

And that's coming from someone who's been developing software for 40 years? Sorry, but in my eyes you've just lost all your credibility.

hhhmm, well, IMO he did _not_ loose his credibility because I did

implement such

a feature and maintain it since then.

I'm afraid you are misquoting here. The credibility topic (where you qutoed) wasn't brought up because of the switch.

Finally, I hope I don't get banned from the webpage, because of this right-out-of-hell-patch I did, and that I still can contribute code and

patches

to GIMP.

People don't get banned for patches here :)

Alexandre