GNOME Bugzilla – Bug 338138
eog could automatically save images after rotation, if the rotation is lossless
Last modified: 2021-06-09 20:58:48 UTC
Please add lossless rotation for jpgs, like gthumb-viewer has. It's really handy for a lot of users, I guess. Especially since most don't even know you lose information when saving a jpg again. (really like the new version!)
In the meantime you can use exiftran -iapbd *.jpg to automatically convert all jpegs with a correct EXIF rotation tag. (this modifies the file in-place, make sure you make a backup first before playing ;))
Lossless JPEG-rotation should already be included. You can make a little test to be sure. 1. Take a JPEG-image (let's call it "Image.JPG") and open it in EOG 2. Rotate it by 90 degrees and save it as "Image90.JPG". 3. Close EOG (just to make sure it has the correct file) and open Image90.JPG". 4. Rotate it back to it's original orientation and save it as "Image360.JPG". 5. Convert the JPEG-files to BMP-files and check their checksums. The ones from Image.BMP and Image360.BMP should be identical. $ sha1sum *.bmp fd22f31094c87c6d2f7687b5a9dfe5305c8f1137 Image360.BMP 8c2017e5dd77c20abe1664c6fa29a218b663658e Image90.BMP fd22f31094c87c6d2f7687b5a9dfe5305c8f1137 Image.BMP
It does indeed! Didn't know that. Maybe it should be more visible. What I also (personally) like in gthumb-viewer is that it saves the image immediately, without asking. This is possible because it is a non-destructive rotation.
Yuck! EOG should never alter a user's files without the user interacting/confirming the operation. That's what I consider destructive, even if the operation itself is reversible. Maybe a preference checkbox?
*** Bug 349764 has been marked as a duplicate of this bug. ***
So, as EOG already has lossless rotation, the real question is how do we avoid users having to do a file->save everytime they rotate an image. Updating summary.
How could we implement this? I see several options, but don't like too much any of them. 1. Show a dialog warning that the image can be saved immediately after rotating it, ask him whether he wants this to happen or not. Add a checkbox to ask whether to "do this with other rotated files in the future (or during this session)". 2. Set a preference to define if users want automatic saving to be performed. 3. Combine 1 and 2 so that users can decide to autorotate images when firstly asked, but still change their mind and unset it in the preferences page. I like the approach of a per-session behavior, so that users are asked when they rotate the first image in their session. Most of the times, if I am watching pictures in my camera, maybe I don't want to save the rotation (because it's too slow). In a future session, when browsing images in my hard drive, I will want all the images to be automatically saved, so my preference is more session dependant than general. Thoughts? Other suggestions? We need brainstorming here!
> Most of the times, if I am > watching pictures in my camera, maybe I don't want to save the rotation > (because it's too slow). Then let’s make it faster instead? And if you think that the storage medium is slow in your example then anything -even loading- is slow. For me having to rotate an image more than once is a nuisance. I wouldn’t regard immediate rotation as destructive (granted that any meta-data is preserved).
"lossless" jpeg rotation really isn't (there is no reencode but) some information may be trimmed with certian size images, and unfortunately the process cannot be trusted and developers must presume it will be destructive. I'm certainly with the stickler for correctness, dont damage my images, photographer crowd, though I'm torn by the "Keep It Simple Stupid" principle (KISS). Matters with EXIF images complicate matters further and I'm sure the current behaviour was entirely deliberate and developers went to great efforts to make it that way. Perhaps the users could be better informed of what is actually happening (status bar message?) or some other adjustment made to make them happier with the current behaviour and realise what a great job EOG is already doing. I'd hate to see it changed exactly as requested, I really do hope the underlying problems can be tackled some other way that keeps us all happy.
Hi guys, how is the progress on that matter? I think it is annoying enough to rotate pictures at all. so a one click solution is just the best. Please add this feature, even if optional through preferences, to the next release of Gnome. It is also a major thing for people switching over from Windows which makes them say "Linux sucks" (in the matter of picture handling) just because they are used to rotate pictures the easy way. Thx
Well, here is a new proposal of mine: As we now have a customizable toolbar, we could make it possible to add the Save button to it (trivial change). It would then be a matter of two clicks (and a keypress) to rotate a whole collection at once (Select all images (CTRL-A), click rotate, click save). I think that's a practicable amount of "work" considering the problems that could arise. Btw, if you want to see an example of what Alan Horkan is talking about in comment 9 take a look at bug 455883.
May I propose to add two (undocumented/hidden/ancillary) shortcuts that would allow direct lossless rotation during fullscreen viewing? These would just come in addition to the newbie friendly solution resulting from this report.
i definitely think the user should have the choice to set the one-click behaviour in the preferences. 2 clicks is still double the time of a single click. if you don't have a cam with a sensor for rotation this means a lot of time.
Hi guys, Any progress with this feature? I've wanted this functionality in any Linux viewer for a while now ... but found it in none! It really makes life easy when viewing images from the camera the first time. I think it's very reasonable to give the user the choice to set the one-click behavior in the preferences. This choice satisfies everyone. I hope this could be taken care of soon. Thanks
*** Bug 487063 has been marked as a duplicate of this bug. ***
Hi guys, I tried to reproduce comment #2, but actually got different behavior - workflow was : open file, rotate right, save as, close eog - toto90-90, is rotate right, save as, close eog, open rotated image, rotate left $ sha1sum toto*.jpg 679a82f5c6e19d28f98a69678a8bacf667e0aa8d toto.jpg 5be7e560308f18bf96387842dd72878bc9ceb99f toto180.jpg ca894fb2c1d16cf4e07300c71a0ea05d6c106c41 toto270.jpg 24b4ed09663afc64c7b43afade44b6484632ea27 toto360.jpg f7399e90fcf35dad05626b3ef4297dadf86d3af9 toto90.jpg 24b4ed09663afc64c7b43afade44b6484632ea27 toto90-90.jpg What we can see is that toto360.jpg is different from original toto.jpg But toto90-90.jpg is same as toto360.jpg I opened then "man jpegtran" (jpegtran is tool from libjpeg-progs and depend from libjpeg62). A the following command fails: $ jpegtran -rot 90 -perfect toto.jpg > tutu90.jpg jpegtran: transformation is not perfect $ This has to be linked with http://bugzilla.gnome.org/show_bug.cgi?id=455883 And the "man jpegtran" page deals with this (extract below): -perfect : Fails with an error if the transformation is not perfect. For example you may want to do (jpegtran -rot 90 -perfect foo.jpg || djpeg foo.jpg| pnmflip -r90 | cjpeg) to do a perfect rotation if available or an approximated one if not. That's why GQview has implemented the lossless rotation with the command line below. It saves rotated file only if rotation was successfull: %wif jpegtran -rotate 90 -perfect -copy all -outfile %p_tmp %p; then mv %p_tmp %p;else rm %p_tmp;fi Anyway, my main point is that it is not documented (I did not found) that rotation is lossless if libjpeg is installed (at least supposed to be lossless). I had to go to irc (thanks claudio), and go back to bug tracking. This is a very important feature (at least for me) for a software to be documented. Summary: - comment #2 of bug 338138 is wrong - bug 455883 is confirmed - no documentation about 'supposed to be' lossless rotation Thierry
(In reply to comment #16) > Anyway, my main point is that it is not documented (I did not found) that > rotation is lossless if libjpeg is installed (at least supposed to be > lossless). I had to go to irc (thanks claudio), and go back to bug tracking. > This is a very important feature (at least for me) for a software to be > documented. > > Summary: > - comment #2 of bug 338138 is wrong > - bug 455883 is confirmed > - no documentation about 'supposed to be' lossless rotation The bug regarding libjpeg and lossless rotation in the documentation is bug #382234. I'd suggest to reopen and put a dependency on bug #455883.
I'm also affected by this bug. Are there plans to enable auto save. It could be optional, set in the preferences?
*** Bug 558592 has been marked as a duplicate of this bug. ***
I agree with Jojo Man from bug 558592 that this should be solved as a plugin (possibly switchable by a menu entry). It's too risky to include this functionality by default IMHO. A plugin makes it easily includable for the people requiring/wanting it. We could include the plugin into eog-plugins if desired.
(In reply to comment #20) > I agree with Jojo Man from bug 558592 that this should be solved as a plugin > (possibly switchable by a menu entry). It's too risky to include this > functionality by default IMHO. A plugin makes it easily includable for the > people requiring/wanting it. > > We could include the plugin into eog-plugins if desired. > Yes, please add this option as a plugin.
Excuse me..but why make it a plugin?? Shouldn't it be a built-in function (controlled by a proper preference in the Preferences menu)?? To me, it has ALWAYS seemed stupid not to auto-save a rotated picture. I mean, I find just 2 reasons to rotate an image: 1) it's the wrong way round (probably because of how it was taken with the camera) 2) i took it too seriously when they told me "try to look at world from another angle" =P Let's suppose I'm not too crazy and I'm really just trying to watch at my picture as a normal human being. I really can't imagine other reasons not to save it in the right way than the two mentioned above (it's not lossless, or it's saved on a slow media as a usb attached camera..). But to me, that's an EXCEPTION, not the rule!! So, why to provide it as a plugin??!? I know, this is just a problem of HOW it would be implemented, but it seems this is a quite important feature to a normal user and it's not given the necessary importance. Shouldn't a plugin be just an unnecessary feature, provided for (those probably few) interested people? And I really don't see the point in "not saving something without telling the user". Isn't it quite the same as not saving an edited file without telling anything (that is the actual behaviour of eog). I hope I wasn't too "hard" in saying my opinion, I'm just a bit disappointed of seeing such a (IMHO) basic function in an image viewer treated as unnecessary, unimportant..and for reasons a normal user really doesn't care. IMHO, of course =)
(In reply to comment #22) > Excuse me..but why make it a plugin?? Shouldn't it be a built-in function > (controlled by a proper preference in the Preferences menu)?? > > To me, it has ALWAYS seemed stupid not to auto-save a rotated picture. I mean, > I find just 2 reasons to rotate an image: > 1) it's the wrong way round (probably because of how it was taken with the > camera) > 2) i took it too seriously when they told me "try to look at world from another > angle" =P > Let's suppose I'm not too crazy and I'm really just trying to watch at my > picture as a normal human being. I really can't imagine other reasons not to > save it in the right way than the two mentioned above (it's not lossless, or > it's saved on a slow media as a usb attached camera..). But to me, that's an > EXCEPTION, not the rule!! So, why to provide it as a plugin??!? > I know, this is just a problem of HOW it would be implemented, but it seems > this is a quite important feature to a normal user and it's not given the > necessary importance. Shouldn't a plugin be just an unnecessary feature, > provided for (those probably few) interested people? > > And I really don't see the point in "not saving something without telling the > user". Isn't it quite the same as not saving an edited file without telling > anything (that is the actual behaviour of eog). > > I hope I wasn't too "hard" in saying my opinion, I'm just a bit disappointed of > seeing such a (IMHO) basic function in an image viewer treated as unnecessary, > unimportant..and for reasons a normal user really doesn't care. > > IMHO, of course =) > I completely agree with you. When I want to rotate an image it's always because I am fixing its orientation and the fact that it's not automatically saved is completely contra-intuitive for me.
(In reply to comment #22) > To me, it has ALWAYS seemed stupid not to auto-save a rotated picture. I mean, > I find just 2 reasons to rotate an image: [-...] > IMHO, of course =) Yes, it is really humble to call a design decision something stupid (even if it's wrong). This is GNOME Bugzilla. Behave and leave the rants for other places in the Internet.
(In reply to comment #24) > Yes, it is really humble to call a design decision something stupid (even if > it's wrong). > > This is GNOME Bugzilla. Behave and leave the rants for other places in the > Internet. > That was intended to be a very subjective point of view of mine (to ME, it SEEMS..). Moreover, let me quote my self: "I hope I wasn't too "hard" in saying my opinion [..]" That's my way of being humble: leave my thoughts/opinion clear and precise as I made them, but in the belief that they aren't more than an opinion, subject to others' criticism and to mistakes - even big ones. I'm sorry if that was ill-mannered of me, it wasn't my intention to offend anyone or anyone's work, or to start a flame or whatever it's called in slang. I only hoped to find some explanations or just a contact, a "talk", with developers, but it seems interest in my post was all grabbed by one word. I would be PLEASED to continue this discussion in a more suitable place, if possible and if any exists. I thought this was it - where else to discuss a bug/feature request? It seems I was wrong and therefore I apologize, wondering for the right (?) place where to discuss such things.
(In reply to comment #22) > > I hope I wasn't too "hard" in saying my opinion, I'm just a bit disappointed of > seeing such a (IMHO) basic function in an image viewer treated as unnecessary, > unimportant..and for reasons a normal user really doesn't care. > > IMHO, of course =) > Let me clarify this. I am in no way seeing this as unimportant or unnecessary. But I think the normal user would actually care if his picture is broken (bug 455883, see comment 9 by Alan Horkan for the technical details) or unreadable by the camera (bug 588286) afterwards. While the latter is not that critical (as you could rotate back and the camera would probably read it again) the former is as it destroys data. And I still couldn't find out if this situation is detectable up-front. Also having it as a plugin is not really different from the built-in functionality for the user once the plugin is installed and activated (which you only need to do once), but it relives us from having to provide support for it if it eats your pictures because it is more a "Use-on-you-own-risk"-operation then.
s/relives/relieves
One thing to remember is that EOG is presented as an IMAGE VIEWER not an image editor. KISS also means not sneakily editing a file whilst pretending to be a viewer. If anyone intends to rotate an image and maintain it in its new state they must realise it is a change that needs saving. Cntl-s does not seem like too much hard work. One big draw back with saving a rotation that has been overlooked so far is that it will probable make most cameras' internal software barf. Cameras necessarily have trimmed down software that expect the file in their native format. They are not general purpose viewers. I recently hit this in Vista whilst viewing images on an XDcard. I rotated an image to view it and just caught a glimpse of a subliminally short message "saving image" as I moved to view the next image. Now, when I put it back in the camera and browse the images when I hit the rotated image it waits for about 2s then posts "input data error". Vista KISS my arse! This is clearly unacceptable. It should not be necessary to get caught out like this if sound design principles are followed rather than trying to be too clever and second guess what the user "probably wants" and doing it without asking. If a user does a rotate and saves it, fine: be it on his own head if the camera can't read it afterwards. Software should never do this sort of thing without asking.
I see your logic buddy, so just like all the other image viewers i.e "image viewer" on windows or "Preview" of Mac or ACDSee or Picasa (the image viewer program) we shouldn't have this feature cuz they/we are just image viewers. Except for the fact that all those "image viewers" have auto-save with rotate functionality. Hrm... guess they are doing it wrong and we are doing it right? When everyone else seems wrong, it's time to re-evaluate ourselves. (In reply to comment #28) > One thing to remember is that EOG is presented as an IMAGE VIEWER not an image > editor. KISS also means not sneakily editing a file whilst pretending to be a > viewer. > > If anyone intends to rotate an image and maintain it in its new state they must > realise it is a change that needs saving. Cntl-s does not seem like too much > hard work. > > One big draw back with saving a rotation that has been overlooked so far is > that it will probable make most cameras' internal software barf. > > Cameras necessarily have trimmed down software that expect the file in their > native format. They are not general purpose viewers. > > I recently hit this in Vista whilst viewing images on an XDcard. I rotated an > image to view it and just caught a glimpse of a subliminally short message > "saving image" as I moved to view the next image. Now, when I put it back in > the camera and browse the images when I hit the rotated image it waits for > about 2s then posts "input data error". > > Vista KISS my arse! > > This is clearly unacceptable. It should not be necessary to get caught out like > this if sound design principles are followed rather than trying to be too > clever and second guess what the user "probably wants" and doing it without > asking. > > If a user does a rotate and saves it, fine: be it on his own head if the camera > can't read it afterwards. Software should never do this sort of thing without > asking. >
http://picasa.google.com/linux/ Picassa helps you "organise edit create and share". It is not a viewer. http://www.acdsee.com/ ACDSee provides everything you need to make the most of your digital memories. * ACDSee Photo Manager 2009 * ACDSee Photo Editor 2008 * ACDSee Picture Frame Manager * FotoSlate 4 Photo Print Studio It is not a viewer. Windows is broken by design. When we need to bend the truth to prove our point, it's time to re-evaluate ourselves. Besides, I never found "a million lemmings can't be wrong" to be a very good basis for a design philosophy. So apart from citing broken software that makes my photos unusable by the camera that owns my memory card, do you have any more convincing reasons to support file viewers causing data loss? Please take the time to think before replying.
At the risk of reopening a can of worms - eog really needs to support automatic rotation of images. From a user interaction point of view, it makes total sense that if a user rotates an image it should stay rotated. Users expect their changes to be permanent. If they are not, the experience will be jarring. One reason for this is that autosave is very much the GNOME way. Evince does something like this. We also have instant apply in our preferences dialogs. Automatic saving of changes is also a convenience. A user shouldn't have to open a specialist editing program to simply rotate an image.
> Users expect their changes to be permanent. No, I expect them to be *not* permanent. eog is a file *viewer*. I do not ever expect a viewer to permanently change a file. It's totally against any expectations I have. In fact, I would consider that dataloss (esp. if the jpg data itself was changed and not just the EXIF meta data, it would be real, actual dataloss).
(In reply to comment #32) > > Users expect their changes to be permanent. > > No, I expect them to be *not* permanent. eog is a file *viewer*. I do not ever > expect a viewer to permanently change a file. It's totally against any > expectations I have. Ben: just because you do not expect the changes to be permanent does not mean the majority will slee it that way. I would suggest (though correct me if I'm wrong) that your expectations are rather different from most users'. (Indeed, the very idea of a viewer, as opposed to an editor, will be foreign to most users.) Let's not get hung up on conceptual distinctions between viewers and editors. Let's just do what's right for users. I've made several arguments why, in terms of actual user interaction, this move would be beneficial. > In fact, I would consider that dataloss (esp. if the jpg data itself was > changed and not just the EXIF meta data, it would be real, actual dataloss). That's a valid concern, but it's also an implementation detail.
(In reply to comment #33) > (In reply to comment #32) > > > Users expect their changes to be permanent. > > > > No, I expect them to be *not* permanent. eog is a file *viewer*. I do not ever > > expect a viewer to permanently change a file. It's totally against any > > expectations I have. > > Ben: just because you do not expect the changes to be permanent does not mean > the majority will slee it that way. I would suggest (though correct me if I'm > wrong) that your expectations are rather different from most users'. (Indeed, > the very idea of a viewer, as opposed to an editor, will be foreign to most > users.) I agree. People don't think in terms of viewers or editors. In the case of eog, the image view there is the closest thing that you can get to an actual representation of a picture that's on your computer, changing it there would result in changing the real thing, as it's the closest you can get to "the real thing". This is in line with the document oriented and instant apply design patterns of the GNOME desktop. It would also be consists with evince, which you could also see as a "viewer", it instant applies rotations to the pages.
>> People don't think in terms of viewers or editors Well they should , whoever "they" are. From the presentation on http://projects.gnome.org/eog/ >> What is Eye of GNOME? The Eye of GNOME image viewer is the official image viewer for the GNOME Desktop environment. With it, you can view single image files, as well as large image collections. >> viewer ..viewer ..you can view... So it's VIEWER. If you don't know the difference between a car and a combined harvester you'd better learn before trying to drive. Some hand-wavy, hypothetical "most users .. blah, blah" argument is not a valid criterion for design. As I pointed out above , not only is jpeg modification a dataloss situation, but if the device in question is camera's memory card the image will be unreadable when it is put back into the camera. My camera gets stuck for about 5 seconds when it hits this situation, before giving up and giving me back control. So I have to either delete the image or take the card back out and try to "rectify" it by a further dataloss operation with a REAL editor to put it back into a similar format. This could be implemented as a clearly different function in the interface. eg "rotate image view" and "permanently rotation image". It is simple NOT acceptable to start modifying the recorded image without asking. (BTW evince is also a VIEWER. However it does NOT alter the file on disk. It remembers your viewing preference for the file and rotates it in a similar way next time your VIEW it.)
(In reply to comment #35) > >> People don't think in terms of viewers or editors > > Well they should , whoever "they" are. > So it's VIEWER. If you don't know the difference between a car and a combined > harvester you'd better learn before trying to drive. Some hand-wavy, > hypothetical "most users .. blah, blah" argument is not a valid criterion for > design. While I can totally see where this comes from, reality is quite different. No matter how hard you try you will never find a car that only goes forward/backward/left/right and doesn't do anything extra to help you. I absolutely agree that EOG is not an image editor, and adding features to it needs to be well scrutinized, but important use cases and the design consistency of the GNOME desktop as a whole certainly justify this behavioural change. > > As I pointed out above , not only is jpeg modification a dataloss situation, > but if the device in question is camera's memory card the image will be > unreadable when it is put back into the camera. [...] Yes, this will have to be properly fixed. > > This could be implemented as a clearly different function in the interface. eg > "rotate image view" and "permanently rotation image". You would have to add "permanently flip" as well. Having Save and Non-Save options of actions is not a good solution. > > (BTW evince is also a VIEWER. However it does NOT alter the file on disk. It > remembers your viewing preference for the file and rotates it in a similar way > next time your VIEW it.) That would be a reasonable solution for EOG if all else fails. Though I would be confused when I take my photos somewhere else and orientation changes.
> [eog is] the closest you can get to "the real thing". I don't know what you mean with "real thing", but using eog is for me like taking a stack of physical pictures and looking at them. If I turn a physical picture to look at it from another angle, it's not permanently changing the picture either. I need a way to just *look* at pictures, in whatever way I like (turn, zoom, whatever), without having that stored. (It'd be strange that turning persists but zooming doesn't - both are just allowing me to look at the picture in a different way.) > > if the jpg data itself was changed and not just the EXIF meta data, > > it would be real, actual dataloss). > That's a valid concern, but it's also an implementation detail. Maybe, but a critical one. If you save it by changing the actual JPG data and not just the EXIF metadata, the image gets actually *worse* in quality, because JPG is lossy, it's like re-encoding an MP3. > This could be implemented as a clearly different function in the interface. eg > "rotate image view" and "permanently rotation image". That'd be good, yes. I've seen that in another viewer (can't remember which one), too. The default toolbar button would do the view-only action, and there'd be another, optional toolbar button available in toolbar customization, which does the permanent rotation, and it would have a small save icon in the corner in addition to the turn arrows. > he image will be unreadable when it is put back into the camera. > My camera gets stuck for about 5 seconds5 seconds Just for information, is that only when the JPG data is modified or also when just the EXIF metadata (orientation property) is changed?
(In reply to comment #37) > > [eog is] the closest you can get to "the real thing". > > I don't know what you mean with "real thing", but using eog is for me like > taking a stack of physical pictures and looking at them. If I turn a physical > picture to look at it from another angle, it's not permanently changing the > picture either. I need a way to just *look* at pictures, in whatever way I like (turn, zoom, whatever), without having that stored. But if you rotate a picture in the stack it will still be rotated compared to the others. in the stack. > > (It'd be strange that turning persists but zooming doesn't - both are just > allowing me to look at the picture in a different way.) Coming back to the stack example you put it, you can't physically zoom in the real world, you can only move your head closer/further. It doesn't change anything in the stack of images. > > > > if the jpg data itself was changed and not just the EXIF meta data, > > > it would be real, actual dataloss). > > > That's a valid concern, but it's also an implementation detail. > > Maybe, but a critical one. If you save it by changing the actual JPG data and > not just the EXIF metadata, the image gets actually *worse* in quality, because > JPG is lossy, it's like re-encoding an MP3. Like said many times above, this should only be done if it can be done lossless. And it seems there are several options to go with. > > The default toolbar button would do the view-only action, and there'd be > another, optional toolbar button available in toolbar customization, which does > the permanent rotation, and it would have a small save icon in the corner in > addition to the turn arrows. You cannot do this in an icon.
>> You would have to add "permanently flip" as well. I don't even see why a VIEWER needs flip. This is definately an editor functionality. We commonly turn a camera to shoot in the desired frame so rotate is a common situation. I don't recall seeing many people use the camera upside down or in a mirror. This sounds like a case of "mission creep".Next we'll be looking at doing smaller rotations for horizon correction or lens correction or red-eye removal. There are other tools for this. A viewer should remain a viewer. I see a strong argument for removing flip. >> Having Save and Non-Save options of actions is not a good solution. These are not options. They are fundamentally different actions. That is what the interface has to communicate to the user. Then there will be no "confusion" later. If gnome wants to aim at consistency , a good start would be to make sure viewers do not modify the the files they are viewing. If a friend wants to show me their photos I don't want a viewer that may screw up their work. In that case I would be using Vista :D >> Yes, this will have to be properly fixed. 100%
>> Just for information, is that only when the JPG data is modified or also when just the EXIF metadata (orientation property) is changed? >> Don't know but it could be either or both in different devices so it has to be assumed that any change could produce breakage.
(In reply to comment #39) > >> You would have to add "permanently flip" as well. > I don't even see why a VIEWER needs flip. This is definately an editor > functionality. We commonly turn a camera to shoot in the desired frame so > rotate is a common situation. I think at least one thing we can agree on is that an image viewer certainly doesn't need "Save". > I don't recall seeing many people use the camera upside down or in a mirror. > This sounds like a case of "mission creep".Next we'll be looking at doing > smaller rotations for horizon correction or lens correction or red-eye removal. > There are other tools for this. A viewer should remain a viewer. > > I see a strong argument for removing flip. If you want to do that please file a seperate bug and keep this discussion on the save behaviour.. > > >> Having Save and Non-Save options of actions is not a good solution. > > These are not options. They are fundamentally different actions. That is what > the interface has to communicate to the user. Then there will be no "confusion" > later. > If gnome wants to aim at consistency , a good start would be to make sure > viewers do not modify the the files they are viewing. It would be better to actually be helpful and not get stuck in programming philosophies. "Do one thing and do it right" may have work for command lines tools, it doesn't work for the task focused activities people use computers for today. I think i'm probably one of the worst "interface nazis" in the GNOME project but i still think these things are good to have, even in a viewer. :) > If a friend wants to show me their photos I don't want a viewer that may screw > up their work. In that case I would be using Vista :D Yes, everyone agree we shouldn't destroy photos, don't worry :)
I don't think separate permanantly flip/rotate actions are necessary - that would add complexity and could cause confusion (what's 'non-permanent rotation'?!). Let's just keep it simple - if someone rotates or flips, the image stays rotated or flipped (so longing that this can be done in a non-destructive way). We could possibly add an option which would enable autosave to be disabled, but autosave should be the default - I'm pretty sure that it will suit the majority. As for external media, that's a special case. Saving changes should be disabled in those situations.
(In reply to comment #42) > I don't think separate permanantly flip/rotate actions are necessary - that > would add complexity and could cause confusion (what's 'non-permanent > rotation'?!). Let's just keep it simple - if someone rotates or flips, the > image stays rotated or flipped (so longing that this can be done in a > non-destructive way). > > We could possibly add an option which would enable autosave to be disabled, but > autosave should be the default - I'm pretty sure that it will suit the > majority. Yea, an option to toggle this is definitely justified, and let the default be consistent with the document oriented ways of doing things and get rid of the "Save" menu entry (Save A Copy would still be needed). > > As for external media, that's a special case. Saving changes should be disabled > in those situations. Yep, I can live with that.
Another idea is Gwenview's behaviour: a small bar coming down when a picture is modified. Available buttons for saving the single picture or a series of modified (rotated) pictures and for undoing. See http://img140.imageshack.us/img140/8171/gweng.png for an example
(In reply to comment #44) > Another idea is Gwenview's behaviour: a small bar coming down when a picture is > modified. Available buttons for saving the single picture or a series of > modified (rotated) pictures and for undoing. > See http://img140.imageshack.us/img140/8171/gweng.png for an example I don't see the benefit of the popup infobar ove having those icons in the toolbar. Having the save icon in the toolbar implicitly says "hey, you need to save the changes"
>> We could possibly add an option which would enable autosave to be disabled, but >> autosave should be the default - I'm pretty sure that it will suit the >> majority. So breakage and lost data is the default behaviour now?! MS Windows "suits the majority". That is not a design criterion either. In fact this whole crap way of doing things seems to originate in vista. Like now everyone in linux/oss world seems to think that means we have to throw sound software design out of the window and copy it. An argument from the "a million lemmings can't be wrong" school of thought. > >Yea, an option to toggle this is definitely justified, >and let the default be consistent with the document oriented ways of doing >things and get rid of the "Save" menu entry (Save A Copy would still be >needed). If there is something to save , why get rid of the save menu entry? Having the entry change from grayed out to active would be a useful visual feedback. >> >> As for external media, that's a special case. Saving changes should be disabled >> in those situations. >Yep, I can live with that. How are you going to define "external media" that do or don't need this special treatment? Again , this is bad design. Special cases, modes and other obscure reasons for fundamentally different behaviour in what appears to be the same situation leads to confusion and will result in people doing the opposite of what they intent or simply not realising there are different behaviours. Buzz words like "document oriented" should not be used to justify corruption of the said document like it is a good idea.
(In reply to comment #46) > >> We could possibly add an option which would enable autosave to be disabled, but > >> autosave should be the default - I'm pretty sure that it will suit the > >> majority. > > So breakage and lost data is the default behaviour now?! > > MS Windows "suits the majority". That is not a design criterion either. In fact > this whole crap way of doing things seems to originate in vista. Like now > everyone in linux/oss world seems to think that means we have to throw sound > software design out of the window and copy it. > > An argument from the "a million lemmings can't be wrong" school of thought. Please, we know you're angry about your destroyed data. Non destructive saving should be fixed first before this new way of doing things can be implemented. > > > > > >Yea, an option to toggle this is definitely justified, > >and let the default be consistent with the document oriented ways of doing > >things and get rid of the "Save" menu entry (Save A Copy would still be > >needed). > > If there is something to save , why get rid of the save menu entry? Having the > entry change from grayed out to active would be a useful visual feedback. > First you argue it should be only a viewer (in caps), now you are arguing for editing? I don't get it. > >> > >> As for external media, that's a special case. Saving changes should be disabled > >> in those situations. > > >Yep, I can live with that. > > How are you going to define "external media" that do or don't need this special > treatment? gvfs? anything that's not on the users harddrives. > > Again , this is bad design. Special cases, modes and other obscure reasons for > fundamentally different behaviour in what appears to be the same situation > leads to confusion and will result in people doing the opposite of what they > intent or simply not realising there are different behaviours. Wrong, there's just one mode at a time and you have to explicitly change it in the preferences dialog to change to a different behaviour. There cannot be any confusion about the behaviour because it cannot be switched by accident. The only confusion there is is now, because evince and eog, the most important viewers of GNOME behave differently. > > > Buzz words like "document oriented" should not be used to justify corruption of > the said document like it is a good idea. For the last time. It will not corrupt your data.
Guys, you are going in roundabouts and I'm starting to get annoyed by this. This discussion is growing as if this was a user forum when it's actually a bug tracker. Please stop now.
I'm not "angry" about data loss , I got one unimportant image a bit degraded. What I do object to is the sloppy thinking and general degradation of the linux experience as more and more of this MS cruft gets adopted. It's not me that says oeg "should" be a viewer, it claims to be one. I thought we agreed on that. The evince approach is the only way I can see to do this correctly. There are plenty of simple editing tools (without going for something complicated like gimp) that are made for this sort of trivial editing and tidy up tasks. If you want to edit your images use an editor , if you want view them use a viewer, and have the right to expect having viewed them they will not have been changed on the storage medium. >> For the last time. It will not corrupt your data. so why can't I view such a non corrupted file on the device that created it? Do you have another word for that? >> Wrong, there's just one mode at a time and you have to explicitly change it in >> the preferences dialog to change to a different behaviour. Of course there's one mode at a time, that's what mode means. Things look the same but aren't. If you read up on the basics of interface design it is one of the fundamental things to avoid if at all possible. Equally, having different behaviour for "internal and external" devices will be a similar error. Is a usb harddrive in or out? It could be the boot drive or a flash device. Or maybe I boot from flash. Flash devices have a wear limit. Another reason for not doing spurious writes on potentially large files. This will only get worse if you try to double guess the user and presume you can know what his hardware set up really is. Ease of use is simple, consistent behaviour, not the computer that tries to think for me.
Claudio Saavedra you're right. the points have been made. I thought Hylke Bons was a dev , sorry.
*** Bug 626900 has been marked as a duplicate of this bug. ***
A purely UX-related suggestion for a perfect compromise: 1) after rotating, EOG saves the picture without asking confirmation BUT it will keep a copy of the original (non-rotated) picture in memory 2) after the new picture is saved to disk, EOG will show a toast that allows the user to both UNDERSTAND what just happened (i.e. the toast should inform the user that a change took place) and UNDO the operation (i.e. restoring the original non-rotated picture) I attach an example of what the UI could look like: https://i.imgur.com/sX77UaM.png
*** Bug 793049 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/eog-plugins/-/issues/10.