Better handle of title in the upload
patricksan opened this issue · comments
Today, when user doesn't provide a title, we use file's name as title of the photo.
What I implemented on iOS and it seems much better is create a title when it is not provided by user. These are the points:
- title must not be entered by user
- generate a title based of date
- the date should contain day, month, year and time (hh ou HH:mm)
- the date and time must be based on internationalization
See example on iOS:
I think that in some cases file name can better describe photo than its date: Not always images named like IMG_0001. Example
@httpdispatch, in this case you used a image download form the web. But if you take photos form the mobile or your camera it will always be like IMGxxxx.jpg
Jaisen and I did some tests and we liked it. Also it is the similar approach used by dropbox.
BTW, to generate the date you should follow this procedure:
- Check if there is metadata (exif and tiff) in the image
- in the exif we must look these values in the order:
{Exif} = DateTimeOriginal{Exif} = DateTimeDigitized{TIFF} = DateTime
- normally format will be like that: 2013:05:12 17:17:24
- ATTENTION: Field
{Exif}and{TIFF}may be present in the photo, but without date information. In this case, go to the next procedure.
- in the exif we must look these values in the order:
- If there isn't the information before, check if you can find the file date or file date modification
- if none of them, return the current date/time
do we have metadata in generated images?
What do you mean with generated images?
i mean resized images
you mean from our API? Normally not.
For example form an image that I download from my website:
Wheeljack ~/Downloads $ exiftool 870x870.jpg
ExifTool Version Number : 9.29
File Name : 870x870.jpg
Directory : .
File Size : 306 kB
File Modification Date/Time : 2013:05:20 11:45:20+02:00
File Access Date/Time : 2013:05:20 11:45:20+02:00
File Inode Change Date/Time : 2013:05:20 11:45:20+02:00
File Permissions : rw-r--r--
File Type : JPEG
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Big-endian (Motorola, MM)
Orientation : Horizontal (normal)
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Y Cb Cr Positioning : Centered
Exif Version : 0221
Components Configuration : Y, Cb, Cr, -
Flashpix Version : 0100
Color Space : sRGB
Exif Image Width : 2448
Exif Image Height : 3264
Scene Capture Type : Standard
GPS Latitude Ref : North
GPS Longitude Ref : East
Compression : JPEG (old-style)
Thumbnail Offset : 430
Thumbnail Length : 14765
Image Width : 652
Image Height : 870
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
GPS Latitude : 50 deg 59' 37.20" N
GPS Longitude : 4 deg 15' 37.80" E
GPS Position : 50 deg 59' 37.20" N, 4 deg 15' 37.80" E
Image Size : 652x870
Thumbnail Image : (Binary data 14765 bytes, use -b option to extract)
Some tools will remove it, like:
- Aviary
- Path
- Facebook.
That is why I put the algorithm, so we can have another date when it is not present the Exif
ExifInterface in android has method called getDateTime. It uses DateTime EXIF to determine the date. Are you sure about first 2 attributes?
if none of them, return the current date/time
Maybe would be good to show file name in this case? Current date time is not informative for users
Aviary preserve exif information
but not sure whether it preserve date information
just checked, when we edit image in aviary we preserve all exif, but use new orientation and datetime information
check if you can find the file date or file date modification
date of modification of downloaded image will not be informative
@httpdispatch, I'm sure. I see the original metadata information. Maybe Android encapsulates it.
We don't wanna file name in any case. It is not user friendly.
Aviary removes mostly information from the Exif, like date and gps.
In other thread you told me that was possible to get the file modification time. You even added a screenshot.
it is possible but it is not informative. Modification date will be the date when we download file to cache. In most cases it will be current date such as we have 2 levels caching
also we need to adjust our DiskLruCache to preserve exif in some case
@httpdispatch, I don't see the relation with our cache and this issue.
The exif is a metadata in the header or the jpeg, so action is need to do. Also, we don't need to worry about images downloaded to the device from our service because they are a already there. Of course, user can play with the Aviary but the general case we will upload images generated by others Apps (Instagram/Path/.... ) and the ones that the user snapshot via the phone.
Let's just do as simple as possible, when a user selects a photo to upload and don't fill a title, you have a validation in the exif information. If date not there, try to the the date of the file. In the last case, use new Date().
The relation is present such as we operate with bitmaps in the code, not with the file names. Or wait and maybe i understood you wrong.
Should we generate the titles at runtime in the home screen or it is related to upload screen?
also what about dateCreated field in the api response? I've almost done with the cache rework but seems that this field may contain the data we want to load from exif
@httpdispatch, this is just for the upload screen. If user entered title, you do nothing, if doesn't, you will generate a title and put in the api to upload.
You don't need to worry about what comes from Trovebox, cache, bitmaps or anything like that.
It is really simple:
- On iOS I have the check if title is null:
// check title of photo
if (title == nil){
title = [AssetsLibraryUtilities getPhotoTitleForImage:image url:url];
}- And then invoke the method to generate the string title:
+ (NSString *) getPhotoTitleForImage:(NSData*)data
url:(NSURL*) url
{
CGImageSourceRef source = CGImageSourceCreateWithData((__bridge CFDataRef)data, NULL);
NSDictionary *exif = (__bridge NSDictionary *) CGImageSourceCopyPropertiesAtIndex(source,0,NULL);
// check if there is date, if not returns current date
// in the exif we must look these values in the order:
// {Exif} = DateTimeOriginal, DateTimeDigitized
// {TIFF} = DateTime
// date format = 2013:05:12 17:17:24
// first we look for {Exif}
NSDictionary *exifDetails = [exif objectForKey:@"{Exif}"];
// get first DateTimeOriginal
NSDate *date = [DateUtilities getDateFrom:[exifDetails objectForKey:@"DateTimeOriginal"] withFormat:kExifDateFormat];
if (date == nil){
// if it does not exist, let's try DateTimeDigitized
date = [DateUtilities getDateFrom:[exifDetails objectForKey:@"DateTimeDigitized"] withFormat:kExifDateFormat];
if (date == nil){
// if it does not exist, get the {TIFF}
NSDictionary *tiffDetails = [exif objectForKey:@"{TIFF}"];
date = [DateUtilities getDateFrom:[tiffDetails objectForKey:@"DateTime"] withFormat:kExifDateFormat];
if (date == nil){
// if nothing works, get the default date
date = [self getDefaultFileDate:url];
}
}
}
return [DateUtilities formatDate:date];
}But why do we need to set generated title if we can generate it on the fly for any user locale? We have dateCreated field in the api response.
Because then we have to duplicate the logic in the server side to display this title and we don't want to have this logic in the Trovebox Community (the version people can download)
But why do we need to set generated title if we can generate it on the fly for any user locale? We have dateCreated field in the api response.
Because then we have to duplicate the logic in the server side to display this title and we don't want to have this logic in the Trovebox Community (the version people can download)
Correct, the same needs to be shown to the user on web, android and ios.
Seems that i've understood.
Do we need to generate titles also in the sync?
What should we do with the photos without title which are already uploaded? Should we show file names for them?
@patricksan do you have any photos with that tiff metadata for tests?
Do we need to generate titles also in the sync?
For all photos that come to the photo upload screen
What should we do with the photos without title which are already uploaded? Should we show file names for them?
We do for all photos, but they will fail because will not pass in the hash
test of duplicated. So we generate just to has less conditional situations
but it will not come to the site.
do you have any photos with that tiff metadata for tests?
Yes, I will send in the next hours.
What should we do with the photos without title which are already
uploaded?
@patricksan i mean home screen. Should we show file name there for photos without title which are already uploaded?
Do we need to generate titles also in the sync?
For all photos that come to the photo upload screen
Just to be sure, we should not generate title for sync, shouldn't we?
Just to be sure, we should not generate title for sync, shouldn't we?
I see a little bit of a problem. Let me discuss with @patricksan tonight before we make any decisions.
i can generate tile for synced photos directly in the service so each photo from batch will have unique title based on its metadata
@httpdispatch, here some photos to test {TIFF}: https://dl.dropboxusercontent.com/u/138224/Github/PhotosToTest.zip
You do need to generate for Sync also. So everyplace in the code where you get the title from the screen you have to check if user set it. If not then you generate the title.
IMPORTANT:
- It is not necessary to have a unique title. Title for the server is just an open text.
- you don't need to rename the file to contain, just set title in the parameter.
@patricksan i mean home screen. Should we show file name there for photos without title which are
already uploaded?
No. We never change the title value that receive from server.
I will discuss with @jmathai now about the possible problem he sees.
No. We never change the title value that receive from server.
So if photo has no title i should leave it blank. Is it correct?
No. We never change the title value that receive from server.
So if photo has no title i should leave it blank. Is it correct?
Yes