I presume this is only used by people who don't have pro accounts?  I've never considered uploading anything but the original size.

I'd like to confirm that it would me a "must have" feature for me. First because I don't have a pro account, you're right. But also because it takes a lot of time to upload pics that are 2-3Mb big.
Of course I can resize my pics with ImageMagick, and then upload them, but it would be so much simpler if postr do that for me.

Well, patches welcome. :)

this looks like a good gnome-love task, using resize_pixbuf and such.  however how/when we do the resize has a few other implications.  here are the options that i see:

*resize the pixbuf inline as you upload
don't resize the image until it is that photo's turn to be uploaded.  only does work that is needed (ie not spending time resizing photos that aren't uploaded if canceled) and doesn't require much larger of a memory footprint or temp diskspace.  however, the "N mb to upload" dialog can't accurately be computed since the new photo size isn't known yet.  this could be solved by just saying "upload size not computable when resizing photos," however that seems to defeat the purpose of resizing to reduce upload amounts.

*resize the photos preemptively
the photo is resized once you decide to do so.  in an attempt to effectively manage memory usage the resized photo would have to be written to a tmp directory.  the problem would be that extra disk space would be needed.  and it would potentially introduce delays to resize photos before upload, especially if the session is just saved and not uploaded at that time.  it probably won't take that much time, and we could put a progress dialog for the resize.  however it could potentially introduce a disk space leak in the tmp directory.  

*there is also the option to resize the photo once to calculate the new size, discard those contents and then resize again on upload.

Created attachment 152849 [details] [review]
Image resizing hack

This is very much a personal itch scratch hack to add image resizing. 

I haven't (and probably shouldn't since my glade skills are non-existent) added an ui options dialogues etc. As it stands this patch will resize the images within a 1200px maximum dimension. 

The big flaw here is that exif data is stripped. Do any of the existing devs know how to copy the exif data from one image to the next? (and then update the dimensions?). I have posted on the pexif mailing list asking for some help.

Review of attachment 152849 [details] [review]:

looks like this is a good start, but is a little rough around the edges.
big things that would really improve it:
*add an dropdown next to the "upload" button in the status bar, which is something like "original files", and then a few options for max side.
*refactor things to work for both dropped data and existing files
*possibly rebase to the latest version in git.

::: postr-0.12.4_orig/src/postr.py
@@ -614,2 +614,3 @@
         # Rotate the preview if required.  We don't need to manipulate the
         # original data as Flickr will do that for us.
+        # This isn't always the case. You have to enable auto-rotation. My account which is 4+ years old had it turned off!

extraneous comment not related to the bug?

@@ -712,2 +713,3 @@
                             self.add_image_filename (os.path.join(root, f))
                 else:
+                    d = ErrorDialog(self.window)

don't think that this error related to the bug

@@ -821,1 +825,3 @@
         self.update_progress(filename, title, thumb)
+
+        resize_it = True

resize_it is always true?  we're going to need to have a way to add this as an option

@@ -821,1 +825,4 @@
         self.update_progress(filename, title, thumb)
+
+        resize_it = True
+        resize_constraint = 1200, 1200

this should at least be a constant at the top of the file instead of magic numbers hiding inside the code somewhere.  that is until this becomes a selectable/specifiable option.

@@ -822,0 +826,7 @@
+
+        resize_it = True
+        resize_constraint = 1200, 1200
... 4 more ...

use "%s (resizing)" % filename

@@ -822,0 +826,11 @@
+
+        resize_it = True
+        resize_constraint = 1200, 1200
... 8 more ...

resized_filename = "%s_resized.jpg" % os.path.basename(filename)
resized_filename = os.path.join('/tmp', resized_filename)

might want to create a tmp directory to work in?

are we always going to have jpgs?  what about pngs or other file types?

@@ -822,0 +826,15 @@
+
+        resize_it = True
+        resize_constraint = 1200, 1200
... 12 more ...

+ 'foo' ?

@@ -828,2 +847,4 @@
                                    tags=tags, search_hidden=not visible, safety=safety,
                                    is_public=is_public, is_family=is_family, is_friend=is_friend)
+                                   
+        if resize_it:

resize_it is still always true.  hmm

@@ -830,1 +853,1 @@
         elif pixbuf:

so it looks like this only resizes files, not dropped pixbufs.  might want to refactor the existing code so that we can resize both types of images

Hi deignacio (?)

Yeah, you're totally right. As I said in my comment it was a rough hack to suit my use case. There's definitely a lot of work needed to be done to make it release worthy. When I've got a spare moment I'll check out the git repo and implement my changes there.

What are "dropped pixbufs"?

j.

-- 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/postr/-/issues/2.