Mike Chaney's Tech Corner
November 30, 2024, 10:54:15 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Qimage registration expired? New lifetime licenses are only $59.99!
 
   Home   Help Login Register  
Pages: 1 [2]
  Print  
Author Topic: FlashPipe v2010.109 released: discuss here  (Read 39022 times)
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #15 on: September 30, 2009, 08:46:50 AM »

Quote
That doesn't work setting it to other ignores the CRWs and just copies everything else
It does when you set to photos and then to other in the file type. You can either do it in 2 operations or set up 2 operation lines, one for photos and one for other, both with the same destination folder.
I do this regularly when updating a backup hard drive with FP after creating raw qrs files and possibly jpeg's in Qimage.
Brian's idea to separate, in the operations table,  "Photos" into types, eg. "Raw" and "non-raw photos" seems a good suggestion to me.
Terry.
Logged
Fred A
Forum Superhero
*****
Posts: 5644



WWW Email
« Reply #16 on: September 30, 2009, 09:25:25 AM »

Quote
Set the operations row to OTHER and press GO
Thank you Terry.
As you said, you can make two rows and accomplish moving Raw and Other with one click of GO, or make one row set to Photo, click GO, and then chenge that PHOTO to OTHER, and click GO.
Very easy stuff.
Fred
Logged
hedwards
Newbie
*
Posts: 29


« Reply #17 on: October 01, 2009, 02:15:15 AM »

Thank you Terry.
As you said, you can make two rows and accomplish moving Raw and Other with one click of GO, or make one row set to Photo, click GO, and then chenge that PHOTO to OTHER, and click GO.
Very easy stuff.
Fred
Right one can do it, but it's really not the right way of doing it. There are a couple of problems, first off, that's not expected behavior. THM and CRW files belong together, as they each have information that the other needs most software I've used treats them as one file. And second it requires a person to specifically set it up in a way which doesn't necessarily notice if only half the files are being copied.
Logged
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #18 on: October 01, 2009, 08:51:51 AM »

Quote
but it's really not the right way of doing it
That depends on your point of view. FP is flexible enough to suit many situations.  Cool

Quote
that's not expected behaviour. THM and CRW files belong together, as they each have information that the other needs most software I've used treats them as one file
What I expect is what the program says it does. To say that "other" files must go in the same folder is wrong. There are some raw converters that put their "sidecar" files into a separate folder. That is relevant when updating backup drives and the like. FP gives you the option to do either. For a program to "assume" where other file types should reside could lead to all sorts of problems and to base the way it works only on THN and CRW files would make it a rather limited in application.

Quote
it requires a person to specifically set it up in a way which doesn't necessarily notice if only half the files are being copied.
Well, it's all there in front of you in the Source section of the FP window, as soon as you insert a flash card or browse to an input folder: a complete inventory of the files available to copy.
Once you have set up output lines, you leave them there for re-use, switch them on or off as required and maybe edit the sub-folder name.
Terry
Logged
Fred A
Forum Superhero
*****
Posts: 5644



WWW Email
« Reply #19 on: October 01, 2009, 09:19:04 AM »

Quote
THM and CRW files belong together,
Two cents worth more.... THM files are created in the camera as thumbnails mainly for the user to be able to see the images in the rear screen of his camera.
I have a Canon D 60 that makes THM files, and frankly, I don't want them. I delete them, since they are clutter to me.
I am very happy to be able to keep them away from the CRWs.
Qimage as well as all the other apps that I hear people use to moderate their images create their own set of thumbnail files anyway.

Seems like the perfect simple answer.
If you want the THM files from the card, you set a row with OTHER activated and the same destination folder as the CRWs.
If you don't want the THMs in there with the CRWs you don't activate the row with OTHER.

Fred
Logged
hedwards
Newbie
*
Posts: 29


« Reply #20 on: October 02, 2009, 01:57:30 AM »

Eh, I don't agree. The two files both come from the camera and they belong together. The THM is where the writable meta data gets stored, and it's definitely more than just a thumbnail. That's where a lot of the information is stored and while you can regenerate them, you'll be missing potentially important information. It's also the place where applications often times store meta data since they aren't normally supposed to be able to do so with the raw file itself.

Hence, why I said that it isn't the right way to do it, the THMs are not supposed to be separated from the CRWs as that leaves you without the ability to edit any of that information without taking unnecessary risks.

If Mike doesn't want to make it default to doing that sort of thing, this really ought to be at least an option under the settings dialogue, just because of the potential for causing issues with image management.
Logged
Fred A
Forum Superhero
*****
Posts: 5644



WWW Email
« Reply #21 on: October 02, 2009, 09:40:01 AM »

Quote
The THM is where the writable meta data gets stored

I have to disagree with you in general terms, as my other camera 20D, plus all the ones that I have tried recently within the last 4 years do not generate THM files.
Even on the old D 60, the metadata is carried in the RAW file and can be easily read.
I did some reading and found old articles written in 2003 referencing the need for the THM file; essentially pointing out that some browsers do not generate thumbnails, and use the THM for a thumbnail.
The only valid reason I could summon for the D60's need for the THM was the need to alter the metadata.
IPTC data can be written to the embedded JPG from the raw file if need be, but the THM is a tiny JPG file. 160 x 120 pixels. These were designed for viewing in the rear of the camera.

I will have to agree with you though, that a person who needs the facility to alter metadata or has a need to preserve that data in double file settings, should keep the THMs.

On the other hand, since most (can't say all. Didn't research all) cameras no longer generate any THM file, it would be a reasonable assumption that is was deemed unnecessary by the camera manufacturers.

Mike didn't leave you high and dry, though. You can still copy the THM files using the "OTHER" control and place the THMs in the same folder with your CRWs.
Simply make another ROW that is set to OTHER. The destination folder can easily be set to the same as the RAW by right clicking on the RAW destination setting and select make all destinations folders the same.
This does not alter the Drive or the main folder... so it becomes a one click deal.

Fred

Logged
hedwards
Newbie
*
Posts: 29


« Reply #22 on: October 03, 2009, 01:45:22 AM »

I'm fine with it being in some fashion optional but I really do think that it should default to downloading both of them to the same folder since it's a lot easier to delete files that exist than it is to recreate files that don't and the size of the THMs is typically small.

And of course I can do that and am, but I don't think that it's really the right way of doing it. While it's unreasonable to expect a set of defaults that everybody is perfectly happy with,  the defaults should be sane and tailored in some fashion to minimizing the downside. Given the relative small size of THM files, I'm not sure why it shouldn't just default to copying them over as well.

BTW, the article I read on it was from 2007, not that there's really any reason to update the content, as really very little has changed since then. There may be some programs that have reverse engineered the format sufficiently that they can do it. And it's really not a good practice to go monkeying around in RAW files, they're really meant to be read only, which is why QImage is so great for using it's own sidecar files to store the filters. Which is in and of itself one reason why I was so surprised that FlashPipe isn't aware of those files.
Logged
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #23 on: October 05, 2009, 01:46:35 PM »

Just to come back on this one:
Quote
Eh, I don't agree. The two files both come from the camera and they belong together. The THM is where the writeable meta data gets stored, and it's definitely more than just a thumbnail. That's where a lot of the information is stored and while you can regenerate them, you'll be missing potentially important information. It's also the place where applications often times store meta data since they aren't normally supposed to be able to do so with the raw file itself.
I have a couple of CRW samples with their associated THM's so I thought I'd check the CRW's to see what is actually stored in the embedded jpeg raw file, extracted by Qimage. I use this method with my CR2 raw files when I need to copy any data to another file.
As far as I can see, using PhotoMe, Exifer and Irfanview, the data in the THM is identical to that in the embedded jpeg. Not surprising I suppose but it does show that Fred's attitude to THM files (he ignores them) is not the end of the world. As long as the CRW raw image is safe, so is the original meta data.  Cool
Terry.
Logged
Fred A
Forum Superhero
*****
Posts: 5644



WWW Email
« Reply #24 on: October 05, 2009, 01:54:41 PM »

Quote
Fred's attitude to THM files (he ignores them) is not the end of the world. As long as the CRW raw image is safe, so is the original meta data.  Cool

Especially, I might again add, that the old Canons seem to be the end of the THM era, and raw files are currently saved without buddy files.

Fred
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Security updates 2022 by ddisoftware, Inc.