Handling stacked photo pairs (paper photo front and back)

[mastodon]

I have scanned a lot of paper photos, that have lot of info on the back. Sometimes more sentences written on them, and I like to join them to the photos. The handwritten sripts preserve some feelings from that time. So, I have scanned them, too.
How can I easily handle the scanned back of a photo? So, that in the viewer I only see the front, but I can easily get the back side. I though about stacking them, and have a flip effect to show the back side with a mouse hover or click. But this "flipping" effect would be a feature effect.
Maybe someone have an attractive way to retrieve the written back side of paper photos.

[mopperle]

maybe a multipage tiff file could be a solution

[Mario]

IMatch only works with the first page of multi-page TIFF files.
MP-TIFFs are so rare, the additional complexity to deal with multiple images per image is not worth it.

[sinus]

In the end, it does not matter whether the two pictures show the front and back of an old photo.
They can be any two stacked photos, can't they?

And then you just want to see the one photo (e.g. the front). And at the click of a button, the second picture should be displayed, somehow nicely. Ideally, if I understand you correctly, with a flip effect, so that the back covers the front.

Well, I don't think there is such an effect in IMatch yet. In itself, the idea is interesting, one could imagine other things, such as showing a picture with the question "What is this" and on one click the picture would turn around and show the solution with the second picture.

I could imagine that something like that could be done with an app, but that would probably take a lot of time as well as very good knowledge.
Maybe there are already programmes that offer something like that, like some memory programmes or something. I don't know.

So I can't think of a solution to your question.

[Jingo]

I took 45 mins or so this morning and tried to create a quick multi-page TIFF display app based on some open source code floating around.. but I'm running into a few errors so need to play around with it further to see if I can make it happen.  The biggest issue (as always) is Chrome's restriction on accessing files directly from the filesystem so need to use IMWS to get around it.  

If I have some time, then I will follow-up on it!  Stay tuned... Andy.

[Tveloso]

I was going to suggest using Versioning, and show the Version Definition I thought I was using for this, but while I do have a Buddy Definition to keep the Front and Back images together:

   

...it turns out that I'm actually using regular stacks to show/hide the back of the scanned Photo:

   

I'm not sure why I decided to go with Stacking instead of Versioning for this, and (like so many other times when I've changed how I do things in IMatch), I'd think like to switch to using versioning for this now.  I have a question around that, but I'll start a new Topic, so as not to muddy this one.

But as Markus says, Stacking/Versioning does not give the described effect.  Perhaps another option would be to include the back of the photo in the FileWindow Tip.  There was a discussion of that recently in this topic:

https://www.photools.com/community/index.php/topic,9153.msg64455.html#msg64455

[mastodon]

Wow, yes the idea to use it as a "What is this" game is another good idea. I have read to topic with the tooltip idee. I find it promising, but it does not have a happy end. I mean a solution.

[Aubrey]

I've always added what is written on the photo into the description metadata.
While one is scanning the next set of photos one has time to do this.
This means that if IMatch and photo get separated this info is contained within the photo.
I've not spent time scanning the reverse side of photo. If there are printing codes, dates printed etc. from the processing I also record this information.

[mastodon]

I do write the text in the backside text of a photo in the description field. This it how it would be searchable. But the "design" of the handwritten text or the old fashion design of a photographers advert makes the backside worth to scan.

[jch2103]

I do write the text in the backside text of a photo in the description field. This it how it would be searchable. But the "design" of the handwritten text or the old fashion design of a photographers advert makes the backside worth to scan.

I've got a number of old scanned images with separate backs and fronts. As @mastondon says, the backside information on these definitely makes it worthwhile to scan. So far I haven't needed to have a 'flip' capability though (I usually use an 'a' or 'b' at the end of the file name to differentiate them). 

By the way, how does one add an image to a post in this version of the forum software? There's an option for 'Add an image' but it doesn't seem to work and in any event requires a URL for the image. That certainly minimizes data stored on the forum, but does have some downsides. And I don't need the 'Add an image' button to do add a link. Here's an example of the back side of a scanned image: https://1drv.ms/i/s!AtlBwiIf8wQzgZU_VpZ-sEKm1-DKgw?e=GzuKPZ

[Mario]

You cannot add attachments when you use the quick reply box.
Use the blue-ish reply button to get the option for "Attachments and other options":

[PandDLong]

I've always added what is written on the photo into the description metadata.
While one is scanning the next set of photos one has time to do this.
This means that if IMatch and photo get separated this info is contained within the photo.
I've not spent time scanning the reverse side of photo. If there are printing codes, dates printed etc. from the processing I also record this information.

I do the same and use that same block of time while the next set of photos is being scanned.

Of course, this captures the information but not the handwriting style and some other items that give it that special "feeling". 

I will keep tabs on this thread - I can foresee occasions when the back would be worth scanning.

Michael

[Mario]

I would do this by versioning (back side version of front side).
This would allow me to see both sides, stack the back under the front etc.
The Viewer can show only the front or both, depending on whether or not I expand the stacks in the FW.

Integrating some sort of "page flip" or similar in the Viewer or elsewhere would be a lot of work for a very small audience (my guess). I would not wait for this. There are very good features in IMatch to deal with that already.

[Tveloso]

I do the same and use that same block of time while the next set of photos is being scanned.

Of course, this [entering the back text in the Description] captures the information but not the handwriting style and some other items that give it that special "feeling".

I agree...even when the text written on the back would not go into the Description (in many cases the writing in my photos simply identifies the person(s) in the photo, and their approximate ages - which really helps in assigning an approximate date), it's still nice to have a scan of the back, because it was "written in Grandma's own hand"...

[jch2103]

Here's an example of the back side of a photo from ~1880. 

[Tveloso]

Here's an example of the back side of a photo from ~1880.

John, that's so cool!...it's a piece of art unto itself...(and beats the heck out of just a Kodak logo or something).  Definitely worth scanning that.

[sinus]

Here's an example of the back side of a photo from ~1880.

John, that's so cool!...it's a piece of art unto itself...(and beats the heck out of just a Kodak logo or something).  Definitely worth scanning that.

I agree, cool design, this back of a photo, indeed. 
But IMatch is able to handle this very well. 

Finally they are simply two photos from the same object. And in the world of art (well, what is art?   ) and in the "normal" world there are a lot of such things, that are worth to take two or more photos from the same object.

First simple machines, like coffee-machines, computers or mixers have several sides worth taking photos. Or, what I have heard, some people take pictures of curious manuals of things. 
Also some paintings has a nice back, or e.g. also the "3D-images", what we see sometimes, when you look at the right, there is a sujet, and if you look from the left, it shows another image.

IMatch can really handle all this, with versions, categories and so on.

But the wish to show such things with a flipping effect on a click, this is another thing, I think.
As I wrote above, I am sure, that e.g. an App could do this. Or other software.

At the moment I have a "number-project" with a friend. It is a wellknown system to use images instead numbers to remember long numbers. For this you replaces each number, in our case from 0 to 100, with an image, then lern this number with the image and you should be able to think at an image-story to remember long numbers.

In order to practise connecting a number with the same picture, I have created such numbers with pictures in Design and Print.
With this we can practise this.
In order not only to practise all the numbers in sequence, I have also created some random sequences.

Then I can send the created pdf to my colleagues and they can practise.
Because at the press of a button, a page with just the number is shown and you try to remember, then on the next page is the solution and so on.

This could also be a photo, for example, and on the next page would be the back of the photo.
And because Design & Print is an IMatch product , you could place some more fields to have a nice "pdf-show".

Something similar is certainly possible with the slideshow, but since I rarely use it, I don't know all the possibilities.

[Jingo]

So, I had some time and finished up my multipage TIFF File app... will be packaging and loading it shortly... no guarantees it will work on your multipage TIFF's... but the few examples I created all seemed to work just fine.  Just another option and fun to flex the scripting muscles once again.. it has been awhile! 

Stay tuned! - Andy.

[mastodon]

Thanks! Unfortunatelly I have all my scans in JPG files, so I am waiting for another solution. But till that, I give a try to versioning (I did not udes that before).

[Jingo]

And.. here is the APP... Enjoy: https://www.photools.com/community/index.php/topic,13161.0.html

@mastodon- I used FastStone Image Viewer to create the multipage TIFF files from JPG's in my database... took only a few seconds to generate..  of course, using JPG's already in your database, as mentioned above, buddy files, stacking and/or versioning is probably the best way to go!

[mopperle]

Thanks Jingo just gave it a try and ir works very well, although it is maybe not as comfortable as the integrated viewer.
When looking at the multipage Tiffs I created for testing, I saw that in the file properties under "image" that there is a value "images/frames count" showing the number of the pages. Is this a value that could be read by IM? I couldnt find it under the metadata tags.

[Mario]

IMatch and ExifTool only import the data from the first IFD (aka page).
Multi-Page TIFF files were always rare and are even rarer today.

A PDF file does a much better job and is far less exotic and much more modern.
IMatch can show you the number of pages in the PDF and you can scroll through all pages in the Quick View Panel...

[ubacher]

I see/have another use for this: Often, when I take a photo of a public artwork, I then take a photo of the
plaque which gives the name and the artist. These two belong together. Or an animal in the zoo with its name.

Would it not be easiest to have an app which, when triggered, would display the next file in the stack/ the version of
the image full screen? (I'm thinking of our App expert Jingo when posing this question.)

[sinus]

I see/have another use for this: Often, when I take a photo of a public artwork, I then take a photo of the
plaque which gives the name and the artist. These two belong together. Or an animal in the zoo with its name.
Would it not be easiest to have an app which, when triggered, would display the next file in the stack/ the version of
the image full screen? (I'm thinking of our App expert Jingo when posing this question.)

Yes, a good input. I think, there are quite a lot of things out there, where we it is useful to take more than one image.

- old photos and the backside
- artwork and a plate
- a detail of an image as a puzzle and the solution (the whole pic)
- general art objects from different angles
- 3D - printed things from different angles
- memory-games
...

To have one main image and another one, what are very closely connected, we can imagine quite a lot of things.
But there are even more than two images, where we could say the same.

If I think at art or design like chairs, sculpures and so on, there are not only two sides, what could be interesting, but 3 or 4 or even more.

My real profession is photographer for hairstyles and fashion, learned many years ago. 
Specialy for the hairstyles we die d alot of image from four sides and created some leaflets with these 4 angles.

I think, we could imagine a lot more.

Then I could, like ubacher proposed, think at an app, what could handles these files nicely.
Maybe, like the mastodon wrote, a kind of flipping or other fancy visual effects.

If it should be only the next image in a stack/version, hmm, I do not know, if this is a good solution. In this case we have to make sure, that the images are always realy in the correct sort-order.

And what, if we want show 3 sides in a fancy way? Like the Mona Lisa, the back of it and a close shot of from mystery in the background of the image (like the bridge).
Or 4 angles to see all four views, hm, and maybe even one from above and below.

Well, maybe only the next image is easier. 

And I think, we users could imagine a lot of things, but creating such an app or whatever is another thing. 

These are just my immature ideas on a morning without even having had my first coffee. So it could all be nothing but nonsense.

[Mario]

Would it not be easiest to have an app which, when triggered, would display the next file in the stack/ the version of
the image full screen? (I'm thinking of our App expert Jingo when posing this question.)

That's what I use the Viewer for.
The version/back-side/associated image is a version and I can either show it with the master or I don't - depending on what I need at the moment.

IMatch gives you stacking and versions. For things like this, a manual version probably works best.
You can tuck the additional images under the master or show them in the File Window / Viewer as needed. And IMatch automatically keeps track of things for you.

[mastodon]

Well, I think, that creating multipage TIFF or pdf for this function is too complicated. We have mostly jpg-s as source, and IMatch or its app should do the rest.
I think Mario has right, this is a versioning issue. I would sketch it like this:
- in the Thumbnail Panels of the File Window I like to have a function like "The Info Icon", that shows a tooltip, so in our case that tooltip window would show the back of a scanned photo. Minor difference, that it would remain for 1-2 sec to have a possibilty to click on it and see the pic. (That would be the "flipping effect".)
- in The Viewer window there would a right click menu item (and a shortcut) for show the back side of the photo, maybe in a splitted view
I do not have an idea, how to manage this, so what tag (inside the versioning "system") should be used for marking the back side of a photo.

[Mario]

(inside the versioning "system") should be used for marking the back side of a photo.

A file relation rule named "Back Side" specific for the purpose to tell IMatch how to find the back side of a photo, if there is one.
From then on, all version-based features are available. You can see the back side in the Version Panel, you can show or hide it as needed, metadata can be synched etc.

[mastodon]

OK, I have choosen versioning for this purpuse. Could you please lend me a hand, how to create Master expression etc. in the File relations panel.
I have a schema like this: front side: image_F_X.jpg, back side: image_B_X. Where the F means front as master, and B for back as version. Both of them could have versions: X. Master is: image_F.jpg
Files can be jpg, dng and tiff

[Mario]

If the name of the back side version and the front side version are identical, except for the F/B, a replacement expression is all you need I guess.

Master Expression: \.jpg$
Replacement: /F/B/
Link Expression: ^{name}

You need separate rules for the other versions of the master / backside.

[mastodon]

I have tried versionning, it works. But, I need something like stacking, to hide the back side. AND actually I do not want to propagate data.
Is it possible to create a link, that let show the second pic in a stuck? That would make possible to show the back side of a photo in the File Window with "The Info Icon" tooltip.

[sinus]

What about "Toggle Version stack" T ?

[mastodon]

Not bad, but the most convenient would be a tooltip window with the back side. I think, stucking will be the solution, auto stacking must be work with the file names. I only need toi figure out the expression. Then create a tooltip like "The Info Icon"

[sinus]

Another way, you could put off the visual proxy and then in the tooltip create a line like this:

<Image Source="{File.Versions}" Height="200" Stretch="Uniform"></Image>

Should work, I think.