The current version of Millipixels in byzantium is 0.22.0-1pureos1
.
Indeed. I should have just run apt list millipixels
, instead of trusting the app entry in the software app. Thanks!
I think the jpg images and compression could be optimized to ensure an image size falls between 550KB and 1MB, the optimization should follow the size of screen and possible zoom:
The L5 has no need for images larger than say 300KB, but accounting for 3x zooming having additional data is nice. Could more modern compressions be adopted even?
Smaller saved images means faster save, faster load, faster zoom and view option, the raw file could still be around if more is needed by a professional photographerâŚ
I think the option of retaining the .DNG is important. Raw files absorb a lot of space, and you want the user to be able to toggle it on or off.
That way, for daily use, record photos etc. it can be left off, but for and important image or for a project, it can be toggled on to allow deeper data from the camera for later processing.
Or have a ui option to send the .dng to the SD card
It would be convenient to have them (or have it toggled/selectable to) in separate folders [like to SD card].
Also something to ponder (which may not have been integrated before, since linux phone cameras havenât been a thing for long): an easy way to add metadata or meta tags/flags/emblems and notes for better grouping and searchability. Something file manager and image apps understand, if they exist for L5 (not sure).
Maybe to toggle: âShould camera open a selection dialog after each picture for meta-tags?â or âWhich tags and text notes should be added automatically to your pics meta data?â [for example: âPersonalâ+âVacationâ+âTaken with L5â+âCC BY-NCâ+âNatureâ+âSummer 2023â+âTaken by Absd Efghijâ]. Or better yet, select tags or use one of user defined meta data profiles. Or something like that.
[Edit: Why, you may ask? Small and simple is nice but after thousands of pics from a decade or two, manageability matters but particularly how that is supported on a device like this, to make use easy]
Itâs easy to overdo the options when thinking of features for an interface. Apple does pretty well with the iPhoneâs camera app; you wouldnât want it much busier than that.
Allowing the user to traverse a menu and set preferences is a must - things like the image size and compression, location for images to be saved (I personally think compressed and raw files belong in the same directory), and universal metadata options like embed location data, copyright and so on.
If you want to edit metadata beyond that, say add tags or remove location data for a batch of images etc., I think it belongs in the file manager or other apps and customisation layers.
Again, personally speaking as a photographer here, Iâm not looking for the L5âs camera to compete with professional cameras, or even compact cameras. To do that you would need to do Appleâs game of applying astronomical amounts of processing and AI power to essentially rebuild the whole photograph, using images from all three cameras. And ultimately I donât like the results, even with my experience on the iPhone 14 Pro.
I think what we all want the L5 to do is take decent photographs, with no flashy gimmicks, and allow the end user to have a moderate amount of control over how that is done. Editing, filters, and so on can be done later if you must.
Purism, (@dcz) hereâs my three tips, from a photographer who has shot manual and raw almost his entire career, and has also spent a solid amount of time using and exploring phone cameras, pushing their limits and extracting and comparing raw files with the phoneâs renders -
- As a rule, the less processing / editing you apply to an image to achieve an acceptable result, the better the photograph.
- Donât overdo your (.jpg or compressed format) post-processing beyond sensor & lens calibration, noise and color corrections etc.
- Keep the interface clean and as responsive as possible, and hide as many options as you can away in a settings dialog or menu.
And a bonus one: @JR-Fi is right; if you want to avoid annoying your users, allow them to set the save location for images. I run a massive micro SD in my L5, and copying files around all the time is not a fluid user experience. But I would add I think compressed and raw files belong in the same directory.
My two cents worth.
You should be able to choose
- what folder(s) to use, and
- whether to have DNG and not JPG, JPG and not DNG, or have both
by customising the post-process script. Granted that that isnât a user-friendly option.
My personal choice would be that all tags that can be filled in automatically are filled in automatically (e.g. date/time, GPS location, camera model i.e. Librem 5 + front/rear, flash status - once working, âŚ).
Again, any metadata that is strictly fixed (e.g. you want everything to be copyright to you or conversely e.g. you want everything to be CC) can be handled in the post-process script.
The truly paranoid may not want metadata at all but you can strip it out in the post-process script if you wish.
I myself handle this on the photo server i.e. after uploading from the photo source (camera / phone) - since for a given âeventâ they are likely to be the same for all photos and if there are exceptions, they can be changed manually on the photo server. However this is highly specific to my setup.
I would guess that the main thing that you want to capture here is: what the hell is this? i.e. a basic caption and/or description.
I sort of feel that that would get in the way of taking photos and I probably wouldnât use this (because it wouldnât fit with my workflow, and it would be quite slow keying in lengthy descriptions on the phone) but donât let me stifle your creativity.
Just throwing it out there but if you want to get keen ⌠a short audio recording associated with the photo (probably not in the JPEG metadata) describing what the photo is might be nice.
I think a key problem of Purismâs communication problems is that of expectation.
Selling a the Librem 5 as a PHONE brings people to think that the Librem 5 is a device for the technically-illiterate. Iâd rather sell it as a Linux pocket computer that can make phone calls.
I am from the generation that had to do lh mouse and lh mscdex to be able to have enough memory to play a game - and had to figure it out in a foreign language before I even had Internet access.
Some problems described in the later posts of this thread I´d solve via symlink to SD card. Of course, we want to make the interface better but Iâd rather focus development effort in the quality of the output, performance and speed rather than more specific UI refinements.
My two cents.
Another big improvement would be to package thumbnailer support so dng and jpg files in Nautilus show immediatelly on beeing saved and added to screenshot, or camera folder. Currently like with Debian, Ubuntu, PureOS you have to add the RAW thumbnailer yourself, that might be ok on a desktop, but on a phone it would be nice to see dng and jpg thumbnails right away.
Also EOG or Loupe dont support DNG so it would be good to patch these to show these on a phone.
The thumbnailing still happens but tends to be delayed and Nautilus has to be opened again after a while to show recent screenshot thumbnails, even with thumbnailer running. So i always name my screenshots so i know what to open since only a generic image thumbnail shows right after taking a camera shot, or screenshot.
Also i am not a fan of current naming convention and running it alltogether makes it really hard to figure out when it was taken, sequence could be simplified as well to count by day 1-24hrs, then start again at 1, use case is you are not going to take more than 1000 images a day:
âIMGyearmonthdaysequenceâ
It obvious it is an image so more importantly maybe:
âyear-month-day_sequence_filetype(png/jpg vs dng)â
or
âscreenshot vs front vs rear camera_year-month-day_sequence_typeâ
or
âyear-month-day_screenshot_raw_sequenceâ
or
âcamera_raw_year-month-day_sequenceâ
e.g. camera_raw_2023-9-24_99, or 2023-9-24_99_cameraâŚ
Also pictures that are saved through screen shots or camera saves are sorted by name, which is hardly ideal.
Should be sorted by:
- screenshot vs camera
- year-month-day
- sequence
- type
or more simply by descending
- recently added in Pictures folder
Good point. Note that the JPEG format allows you to store a thumbnail embedded within the file and, yes, ideally that thumbnail would be available as part of the creation of the file i.e. essentially immediately. However there is no absolute guarantee that any given file browser uses that thumbnail rather than âdoing its own thingâ.
I would prefer YYYYMMDD_HHMMSS i.e. that is enough for me for the name part of the file name.
I would imagine that you can get whatever naming convention you want by ⌠customising the post-process script.
FWIW, on Ubuntu (recent), screenshots simply go in a different folder, problem solved.
How is an exact time and date making it âhard to figure out when it was takenâ?
Because when the eye runs across 14 consecutive digits, it doesnât always parse it correctly into a date and time?
It is explicit and unambiguous, yes, but is it user friendly? No.
As I wrote, I would prefer YYYYMMDD_HHMMSS.xyz
you caught me there heh, i mean its precise but needs the â-â â_â separators for the eye as irvin indicated.
it really should be explicitly:
YYYY-MM-DD_####
or instead of sequence
YYYY-MM-DD_HH:MM:SS (though to me sequence is less verbose and easier to understand, also not sure if MM:SS is necessary in the name, could be part of metadata, or file added in filemanager alreadyâŚ)
Itâs easy to over-do that. One â-â or â_â is a good start. Too many separators a not good either, making filenames too long for view (Iâd take out the âIMGâ at the start) and â:â may cause problems in file names when transferring to certain devices.
(And just to be clear, these are merely very minor usability annoyances in the grand scheme)
how about:
YYYYMMDD_HHMM.dng
And what if you take 5 Pictures in one minute? Seconds are important, too.
When we write numbers, we often make points or commas each 3 numbers to make it easier to read. So I would say every 2nd or 4th number would make it much easier to read. 8 is already too high since you have to concentrate a lot to separate 3 things. We may should give a look into other cameras and how they write filenames.
Also I would prefer short characters to separate. So better - instead of _ etc. And of course it shouldnât break anything on other systems, whatever it will be.
You need the seconds in there as the camera is faster than one pic per minute. Although, I suppose the post processing script could include a time delay to make sure itâs not⌠I mean, too many bad pics exist anyway and L5 could usher in a new era of âslow photographyâ as a style and stress free social media posting
Better
Not sure that an apples to apples comparison:
iphone uses sequence only (everything else is meta data, also iphone doesnt show seconds but i am sure records it in meta data))
IMG_####
not sure what would happen after 9999 images but i imagine it would create a new folder.
In our case IMG_ is not needed since we can see the folder âPicturesâ
I do like the idea of saving screenshots in different default folder called screenshots (under Pictures), and maybe even creating different folders for RAW vs JPG to de-clutter. Maybe even different folder for front and rear cameraâŚ
âMeâ and âEveryone elseâ foldersâŚ?